Nowości z php.internals – akceleracja GPU

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.

  1. KKH says:

    Dane do tego GPU należy wprowadzić. To daje jakiś narzut. Zwykły serwer ma raczej naddatek tradycyjnych procesorów, a GPU raczej słabe albo brak. Żadna tam NVIDIA Tesla. Do tego GPU zaraz by się zaczął dobijać cały tabun chętnych. Dodać do tego prawo Amdahla i mamy znikomy wzrost wydajności, nie wart włożonego wysiłku. Za to Stass Vass dobrze gada. Polać mu! :).

  2. Co fakt to fakt. Natomiast nie wiadomo jak będzie w przyszłości. Kiedyś czytałem artykuł o tym, że to języki kształtują ewolucję CPU i było w nim sporo prawdy. Być może gdyby do PHP i innych języków wprowadzić wsparcie dla GPU to może upowszechniły by się na serwerach ? Co więcej z tego co wiem, zarówno AMD jak i Intel pracują albo i już wypuścili procesory CPU zintegrowane z GPU. Gdyby mieć tabun takich procesorów na serwerze, to myślę, że skrypty mogłyby doznać sporego przyśpieszenia.

  3. Biorąc pod uwagę różnice w wydajności programów odpalanych na CPU i GPU, jestem jak najbardziej za. Szczególnie, jeśli można by takie skrypty “zainstalować” w pamięci karty graficznej i odpalać bezpośrednio z niej.

  4. Ja sądzę, że wrzucenie całego skryptu nie ma większego sensu. Nie wszystkie rodzaje operacji nadają się do odpalenia na karcie graficznej. Aby odpalenie jakiegoś kodu na GPU miało sens musi on spełniać kilka warunków. Po pierwsze musi on operować na danych tablicowych, a po drugie nie powinien być zbyt rozgałęziony – mniej if-ów to lepiej. Poza tym najlepiej by wykonywał operacje matematyczne, bo do takich GPU jest stworzone.

  5. Nie mówię o instalowaniu frameworków na karcie graficznej, co to to nie. ;] Miałem na myśli właśnie takie skrypty a których wspomniałeś w tym komentarzu i we wpisie. Spowodowałoby to kolejną zmianę w podejściu do tworzenia skryptów – wydzielalibyśmy określone elementy do odpalenia na różnych sprzętach. ;]

  6. KKH says:

    @Tomasz Kowalczyk

    No dobrze, ale takich problemów w webdevelopingu praktycnie nie ma[1]. tzn:

    Uporządkowany, przewidywalny ciąg instrukcji arytemtycznych, raczej łatwy do zrównoleglenia. Towarem mocno deficytowym są układy operujące na liczbach zmiennoprzecinkowych.

    Jest za to:

    Mało uporządkowany i mało przewidywalny ciąg instrukcji logiki biznesowej. Z reguły dający się z łatwością mocno zrównoleglić w jednej części (np. proste żadania http) i słabo w innej (dane trwalsze niż jedno żadanie). towar deficytowy: We/Wy.

    Chcesz wielu CPU? Zwykly CPU właśnie osiągnął tranzystorowe optimum i od teraz w scalaku masz coraz więcje rdzeni. GPU mają “ambicje” być coraz bardziej ogólne. Oba trędy mają szansę się zejść. tzn. część GPU zostanie wektorowa, a część będzie slużyć jako małe procki uniwersalne. Np. w jednym kompie: 50 X Core, 1000 X 486, 1000 X GPU – dla garcza. Na serwer www: 10 X Core i 3000 X 486. Czemu? W www nie chodzi to o 1 użytkownika z wektorem do policzenia, ale 1000 użytkowników – każdy z jakąś pierdółką. Pakowanie do www mocnych jednostek FPU to marnotrawstwo.

    Niech PHP działa przyzwoicie jako aplikacja w systemie, a system już sam zadba o rozdział zasobów.

    ___
    * mam na myśli czysty webdeveloping, bo od biedy pod interfejs www można podpiąc np. modelowanie klimatu i z tego nie wynika, że webdeveloping to wszytsko.

  7. Zyx says:

    Akceleracja w GPU to nieporozumienie. Karty graficzne są zoptymalizowane do obliczeń numerycznych, języki do ich programowania – także. Operacje symboliczne nie są tam praktycznie w ogóle wspierane, więc ciekawe, jak byś tam np. dane tekstowe chciał porównywać, kiedy tam nawet prawdziwych pętli nie ma?

  8. @zyx:

    W operacjach na GPU nie potrzeba pętli ze względu na naturę obliczeń – każda operacja jest aplikowana od razu na cały zestaw danych. Jak porównać dane tekstowe ?
    Bardzo prosto, załóżmy, że mamy dwa stringi $a = ‘ABCD’ i $b = ‘AECD’. Żeby je porównać, wystarczy odpalić funkcję na GPU, która wyliczy różnice w wartości ASCII znaków na tych samych pozycjach i doda do jakiejś zmiennej wynikowej. Jeżeli zmienna wynikowa będzie == 0 to wtedy stringi są równe a jeżeli nie, to różne. To jest w zasadzie klasyczne podejście typu map/reduce.

  9. Adam Brodziak says:

    GPU nadaje się do operacji typu MapReduce, ale nie widziałem żeby takowe były implementowane w PHP.

  10. @adam – to tylko kwestia podejścia do problemu, ludzie są przyzwyczajenia do robienia wszystkiego za pomocą pętli. Natomiast praktycznie wszystkie operacje na tablicach można przeprowadzać za pomocą efektywniejszych metod. Jak wspomniane wcześniej map/reduce czy przy użyciu funkcji tablicowych typu array_filter, array_diff, sort etc. Takie funkcje można by zoptymalizować przy użyciu GPU w sposób transparentny.

  11. KKH says:

    Tylko, że w wielu takich funkcjach podaje się callbacka. Co ma go wykonać? CPU czy GPU? GPU – toż to przenoszenie całego enginu PHP na GPU, a nie tylko implementacji funkcji. Raczej nierealne. CPU – to przy każdej iteracji mamy komunikację między CPU i GPU. tzn. równanie do wolniejszego + narzut komunikacyjny.

    Lepszym pomysłem byłoby zaimplementowanie w GPU elementów PHP niezależnych od języka PHP, np. liczenie haszów, serializacja i deserializacja dużych (w sensie wiele złożnych obiektow) danych, zmiana kodowania itp. A i tak nie wiem czy to by dało zauważalny wzrost. I to zakładając, że sam PHP przyspieszył, powiedzmy, 5 razy.

  12. KKH says:

    …bo żyłować kilka wybranych funkcji, gdy skrypt jako całość nie porywa prędkością…

    PS. A może na bazie jądra ARM zbudować coś. Np. zahardcodować tyle PHP ile się da. np. żeby indeksowanie tablic było instrukcją procesora ;). Żartuję, ale jakiś duży hosting mógłby pewne prace zasponsorować dla własnego dobra.

  13. @kkh:

    Jeżeli php miało by adnotacje czy coś takiego. Można by adnotować funkcje np @GPU, która by była wykonywana wtedy na procesorze graficznym. Zresztą, tak jak mówiłem, to bardziej pieśń przyszłość. Natomiast najbardziej przydałby się chyba teraz JIT. Może szkoda, że w świecie PHP nie ma tak jak wśród browserów konkurencji między różnymi engine’ami (JS). Konkurencja wymogła by przyśpieszenie.

  14. thek says:

    Ależ procesory w chwili obecnej mają hardcodowane pewne funkcje. Właśnie te tyczące hashy. Nie pamiętam teraz który, ale chyba w i7 i i5 AES jest sprzętowo akcelerowany i taki soft jak TrueCrypt to obsługuje. Ale to musiałbym poszperać jakie rodziny procków konkretnie.

    Co do GPU to on jest najlepszy do obliczeń na wektorach. Problemem jest jednak to, że większość skryptów webowych jest sekwencyjna i ich zrównolegnianie nie byłoby proste. A wątpię by stary kod ktoś chciał przerabiać. Prędzej napisał by nowy :) Równoległość i asynchroniczność trzeba zakładać już na etapie projektu, by się całość nie wywaliła.

  15. @thek

    przedmówcom chodziło o inny rodzaj hashu. Tak jak mówiłem, zrównoleglić można łatwo każdą operację na tablicy o ile operację na pojedynczym jej elemencie wykonuje funkcja która jest “pure” – prosto przekształca wejście na wyjście i nie implikuje żadnych efektów ubocznych. Więc w zasadzie wystarczyło by trochę poszperać w kompilatorze, aby wykrywał takie operacje (np. wykonywane przy użyciu funkcji array_map) i je optymalizował, wtedy odpadła by potrzeba przerabiania starych skryptów.

  16. thek says:

    Operacje na tablicach da się zrównoleglać gdy elementy nie są zależne. A co jeśli w tablicy przechowujemy jakąś wersję ciągu o określonym wzorze? Wiem, że można by element policzyć, ale gdy wyrazy są używane często, to prościej upchnąć je w tablicę i odwołać do określonego elementu już potem, bez ponownych obliczeń. Zwłaszcza gdy wzory są skomplikowane

    Równoległość zawodzi także w chwili rozgałęzienia. Są algorytmy ich przewidywania (polecam Stalmanna), ale dla skryptu php byłyby one niesamowitym narzutem kosztów.

  17. I was wondering if you ever considered changing the page layout of
    your site? Its very well written; I love what youve got to
    say. But maybe you could a little more in the way of content
    so people could connect with it better. Youve got an awful lot of text for only having one or 2 images.
    Maybe you could space it out better?

  1. There are no trackbacks for this post yet.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.