The Explorer

W jednym z ostatnich wpisów na internalsach, Loon var Reinier zgłosił propozycje RFC pt. ‘__autodefine’. Postuluje ona generalizację mechanizmu autoloadera i rozszerzenie go również m.in o funkcje, stałe i przestrzenie nazw. Polegałby on na zdefiniowaniu funkcji __autodefine o parametrach ($nazwa, $typ), gdzie $nazwa to nazwa brakującego elementu, natomiast $typ to jedna ze stałych w rodzaju T_FUNCTION, T_CONST etc. Jako uzupełnienie funkcji __autodefine proponowane jest dodanie również funkcji spl_autodefine_register o działaniu analogicznym do spl_autoload_register.

Osobiście uważam, że pomysł jest dobry i przydatny. Jestem tylko zdania, że zarówno mechanizm autoload jak i autodefine powinien być używany tylko per przestrzeń nazw, aby uniknąć konfliktów.

A wy co o tym sądzicie :> ?

I stało się, wyśniona przez niektórych funkcjonalność – wywoływanie metody w jednej linii z konstrukcją obiektu zostało zgłoszone jako RFC. Co to oznacza ? O ile zostanie zaakceptowane, będziemy mogli pisać tak:

$kot = new Foo()->ala()->ma()->kota();

zamiast:

$foo = new Foo();
$kot = $foo->ala()->ma()->kota();

Jak to mówią, mała rzecz a cieszy. Prawdopodobnie przejdzie, sądząc po wypowiedziach deweloperów na liście. Cieszycie się ?

Felipe Pena, jeden z najaktywniejszych deweloperów PHP wraz z całym szeregiem innych prominentnych uczestników projektu ogłosił RFC – propozycje zmian w cyklu wydawniczym interpretera. Jak dotąd, wszelkie nowe wydania powstawały spontanicznie. Po prostu po zakumulowaniu się jakiejś masy krytycznej nowych rzeczy w repozytorium, ktoś wyskakiwał jak to „Filip z konopi indyjskich” i mówił, że robimy nowego releasa. Skutkowało to tym, że nikt nigdy nie wiedział, kiedy wyjdzie nowa wersja interpretera. Przez to też między innymi tak wolno nowe wersje dostają się na hostingi, czy do stabilnych wydań Debiana. Nie ma też żadnej ścieżki, dzięki której, można by informować o zmianach we wstecznej kompatybilności, przez co bardzo wiele czasu zajmuje usunięcie jakiś śmieci z poprzednich wersji (magic_quotes etc). read more »

Ekipa „internalsów” puściła chyba wodzy fantazji – Kenan Sulayman rozpoczął wątek o wprowadzeniu akceleracji GPU do PHP. Rzecz może wydawać się trochę zaskakująca, bo jak w generowaniu stron www może pomóc karta graficzna ? Otóż jest kilka zastosowań.

Oprócz oczywistych rzeczy takich jak funkcje przetwarzające obrazki, jest jeszcze druga grupa funkcji – funkcje operujące na tablicach. Weźmy sobie tak popularną funkcję jak in_array(), nie jestem pewien jak ona jest do końca zaimplementowana, ale sądzę, że po prostu jest iterowana cała tablica i każdy jej element jest porównywany z szukaną wartością. Wyobraźmy teraz sobie, że po zastosowaniu akceleracji GPU, zamiast iterować po całej tablicy, równolegle wykonane jest porównanie szukanej wartości z każdym z elementów tablicy. Teoretyczne przyspieszenie dla tablicy, która ma 512 elementów, na GPU, który ma 512 procesorów wyniosło by 512x.

Powiedzmy sobie szczerze, takie przyśpieszenie powoduje małe WOW wśród zgromadzonej publiki . Pojawia się pytanie, czy jest to możliwe w praktyce do osiągnięcia? Z pewnością w dużej mierze zależy to od sposobu implementacji.

Stan Vass podszedł do sprawy bardziej pragmatycznie. Stwierdził, że pierwszą rzeczą jaką należało by zrobić w kwestii przyspieszenia PHP to dołączenie APC do standartowej dystrybucji. Następnie zintegrowanie go bezpośrednio z Zend Engine’em a na koniec dołożenie kompilacji JIT (Just In Time), co podobno już było próbowane przy pomocy LVVM-a. Dopiero po tych wszystkich przyśpieszeniach ma sens jakakolwiek akceleracja przy pomocy GPU.

Widać więc, że przynajmniej niektórzy deweloperzy PHP mają jasną wizję na temat tego co trzeba zrobić by uczynić PHP szybszym. Pytanie czy uda im się przeforsować swoje koncepcje oraz zaimplementować je z powodzeniem.

Jak zwykle czekam na Wasze komentarze dotyczące tych jakże interesujących nowinek.

Oj gorąco ostatnio jest na liście php.internals. Co chwilę coś się ciekawego dzieje, ostatnio na tapecie mamy binarną notację dla liczb całkowitych. Jonah H. Harris zaproponował, by oprócz możliwości wpisywania liczb w systemie 8-owym, 10-ym czy 16-owym można było wpisywać liczby całkowite w systemie binarnym. Powstało oczywiście odpowiednie RFC. Chyba wszystkim na liście dyskusyjnej ten pomysł się spodobał i wygląda na to, że łatka wprowadzająca tą funkcjonalność już niedługo wyląduje w „trunku”.

Jak by to miało wyglądać ? Dla porównania zapis liczby 2010 w trzech dotychczas obsługiwanych systemach zapisu i nowym binarnym:

• 8: 03732
• 10: 2010
• 16: 0x7da
• 2: 0b11111011010 lub jako flagi – 0b00001, 0b00010, 0b00100, 0b01000, 0b10000

Jak dla mnie ten nowy „ficzer” jest całkowicie zbędny, jednak domyślam się, że dla niektórych okaże się przydatny. Szkoda, że chłopaki nie pomyśleli o jakimś bardziej generycznym zaprojektowaniu tego. Mam na myśli coś w stylu rNxLICZBA. Gdzie N to podstawa systemu liczbowego a LICZBA to liczba zapisana w tym systemie. Wtedy dla binarnego zapisu było by coś w rodzaju r2x01010101 a dla 16-tkowego r16x7da.