Wydano kod HipHop PHP od Facebooka
- Dodano: 22 lutego 2010
- Wprowadził: spookypld
- Komentarze: 28
W zasobach repozytorium GitHub pojawiła się stworzona na potrzeby Facebooka aplikacja open source tłumacząca kod PHP na bardzo dobrze zoptymalizowany kod C++. Jak wykazały pierwsze testy, dzięki zastosowaniu HipHop for PHP zanotowano 50-cio procentową redukcję wykorzystania mocy procesora tak serwowanej strony Facebooka w stosunku do wersji działającej na Apache!
Facebookowy HipHop for PHP można wykorzystać do odciążenia procesorów serwera. Jest to możliwe dzięki translatorowi, który tłumaczy kod PHP na C++, co daje możliwość kompilacji na kod binarny np. za pomocą g++. Tak skompilowana aplikacja jest mniej zasobożerna, gdyż nie ma potrzeby jej ciągłego interpretowania przez kompilator PHP.
Jak wykazały pierwsze testy przy zastosowaniu HipHop for PHP, przy takim samym jak w przypadku zastosowania Apache ruchu nastąpił spadek obciążenia procesora o 50%. Jednocześnie stwierdzono, że aplikacja obsłuży dwukrotnie większy ruch przy wykorzystaniu mniejszej o 30% mocy procesora.
Aplikacja powinna znaleźć zastosowanie przede wszystkim w dużych firmach, które muszą tworzyć rozszerzenia kodu PHP w języku C++. Dotychczas konieczne było oddelegowanie lub zatrudnienie nowych programistów do pracy z rozszerzeniemi, a w efekcie wiązało się odpowiednio z wydłużeniem czasu pracy nad projektem lub ze zwiększonymi nakładami finansowymi.
Obecna wersja HipHop PHP pracuje z PHP 5.2, ale wkrótce jej kod powinien zostać zaktualizowany do pracy z PHP 5.3 Kod aplikacji jest otwarty.
Treść została pierwotnie opublikowana pod adresem http://bit-tech.net.pl/otwarty-kod-facebook-hiphop-php-na-githubie Jestem jej autorem i posiadam pełne prawo do jej opublikowania na OSNews.pl
Więcej informacji: http://wiki.github.com/facebook/hiphop-php/
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
28 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
może ktoś jest bardziej obeznany z tematem, ale jak dokładnie to działa? To zastępuje serwer HTTP czy dział jako CGI (z newsa trudno mi to jednoznacznie określić). Oraz czy to kompiluje cały kod czy można kompilować pewną część kodu aby potem użyć go jako rozszerzenie do PHP ?
Na stronie sprawdzałem na szybko i znalazłem tylko jak zainstalować (nie szukałem dokładnie, bo jakoś jeszcze nie potrzebuję aż takiej optymalizacji)
Jak to działa? Czego używa do łączenia się z bazami?
W skrócie:
- można skompilować od razu całą aplikację lub odpalić hh jako demona (lub serwer) i pozwolić mu na kompilację żądanych plików "w locie";
- może działać jako samodzielny serwer WWW, ale myślę że nie będzie trudno zmusić do współpracy z Apache;
- ma parę zaawansowanych opcji – można na przykład określić liczbę plików .cpp które mają zostać wygenerowane – bez tej opcji jeden plik .php = jeden plik .cpp
- działa tylko na 64-bitowych systemach – z tego powodu nie mogłem go jeszcze przetestować
To już było:
http://osnews.pl/hiphop-akcelerator-php-od-dewelo…
Protip: Czytaj uważnie. Ten news jest o wydaniu HH4PHP, Twój był o zapowiedzi.
Czytam uważnie.
Nie ma czego zazdrościć, są ciekawsze tematy.
A według mnie nie warto pisać całego wpisu tak szybko, skoro i tak było wiadomo, że w ciągu kilku dni wydadzą źródła.
To po co pisałeś??
Czytaj uważnie, mam na myśli Twój wpis.
Nie każ mi myśleć.
Chłopaki załóżcie sobie kółko polonisty i nie siejcie opinii poza tematem. Od razu widać, że jesteście redaktorami, bo się panoszycie.
Co do tematu, to ciekaw jestem czy porównywali czyste php czy z modułem akceleracji. Po jego włączeniu php przyspiesza kilkukrotnie bo nie parsuje kilka razy tego samego pliku.
"na bardzo dobrze zoptymalizowany kod C++"
To jakiś żart, czy co? PHP jest językiem o dynamicznej typizacji – bez wcześniejszego uzupełnienia dokładnej informacji o typach, nie da się wygenerować bardzo dobrze zoptymalizowanego kodu. Nie sądzę, by to zrobili, skoro do tej pory nie udało się to twórcom takich projektów jak IronPython czy JRuby. To by też tłumaczyło niewielkie przyspieszenie, które uzyskali (co jak co, ale różnice wydajności między PHP a dobrze zoptymalizowanym kodem Java/.NET/C++ są o ponad rząd wielkości większe niż 50%, na niekorzyść PHP).
@Królik: o ile pamiętam IronPython to najszybsza maszyna Pythona.
Królik nie twierdzi, że nie.
Z tego co mi wiadomo to najwolniejsza, masz jakieś testy ?
@salomon: na pewno nie najwolniejszą, ale też nie najszybsza. Jak widzę od 2.4 sporo się poprawiło w wydajności.
Tutaj najnowsze porównanie: http://ironpython.codeplex.com/wikipage?title=IP2…
Przepraszam Pythona (choć używam i wydajność ZAWSZE mi odpowiadała).
Tak na upartego to w wersji 2.6 mamy tylko IronPythona i Cpythona, więc najwolniejszy…
IronPython chodzi na CLI czyli VM .NET-owej a ta jest istotnie chyba najlepszą z obecnie dostępnych. Co innego sam język, który nawet w wersji klasycznej demonem prędkości nie jest, a co dopiero na JVM I CLI – tam RAM i cykle żre bez opamiętania. Ale to kwestia nie maszyn i nawet nie języka, tylko po prostu konkretnych implementacji.
Kwestia języka. Zauważ, że na tym samym JVM (CLI) Java (C#) chodzą duuużo szybciej niż Python, Ruby, PHP, JavaScript i inne podobne wynalazki. Natomiast relatywnie nowa Scala (na pewno nowsza od Rubyego i Pythona) chodzi na JVM/CLI praktycznie tak samo szybko jak Java/C#. No, ale Scala jest statycznie typowana z bardzo elastycznym systemem typów (co powoduje, że kod jest tak samo zwięzły jak w Pythonie, ale nie trzeba zylionów testów jednostkowych).
Po prostu wygenerować efektywny kod bez informacji o typach jest cholernie trudno – jeżeli funkcja deklaruje, że może przyjmować dowolne obiekty, to musisz przeanalizować CAŁY kod, który ją wywołuje, żeby być w stanie policzyć rzeczywiste górne ograniczenie dla typu obiektu. Dopóki tego nie masz, musisz wołać pola/metody w sposób pośredni, który jest b. niewydajny, bo np. uniemożliwia inlining. A brak inline uniemożliwia kolejne optymalizacje. No i efekt jest taki jaki widać…
"Tak skompilowana aplikacja jest mniej zasobożerna, gdyż nie ma potrzeby jej ciągłego interpretowania przez kompilator PHP."
Niestety twój argument o interpretacji użyty do potwierdzenia tezy jest fałszywy.
Zobacz np. testy *interpretowanego* Basha, który wypadł w testach lepiej niż kompilowane C++. Szokujące i dziwne, ale tak wyszło. Więc twoje uzasadnienie jest błędne.
No ale co z tezą? Są jakieś badania albo inne uzasadnienia?
A link do tych testow?
tak samo można udowodnić wyższość dowolnego języka który opiera się na interpretacji kodu aniżeli kompilacji do bin'a.
dzieje się tak dlatego, że wirtualna maszyna potrafi wykryć procesor i dostosować się do jego możliwości, wykorzystując – bądź nie – dodatkowe rozkazy.
a przypadku c++ używa się -march=i386 , bo i po co
eh, Ci "testerzy"
jak powiedział Stalin – nieważne kto głosuje, ważne kto liczy głosy
> a przypadku c++ używa się -march=i386 , bo i po co
Dotyczyloby to takze maszyn wirtualnych, jesli chcesz byc konsekwentny.
Mogliby dać możliwość pisania wstawek w C++, tak jak sie w C robiło asmowe. Wtedy optymalizator zostawiałby te wstawki na żywca do kompilatora.
Po co ? Po to kilku ubermózgów pisało HipHop-a aby masa kodotłuków mogła pisać w PeHaPie i się nie przejmować. Zaraz by się znalazł geniusz który by zaczał pisać własne wstawki i tylko rozwalał to co działa dobrze.
A po to, że ten hip-hop przyspiesza raptem o połowę, a ponoć konstrukcja języka (dynamiczne typowanie) to fundamentalny problem w optymalizacji i na dużo więcej nie można liczyc. Przy podejściu hip-hop (kompilacja do C++) umożliwienie robienia wstawek byłoby prawdopodobnie za darmo. Ja nie twierdzę, że to jest rozwiązanie na wszystkie bolączki i pozbawione wad, ale co Ci szkodzi taka furteczka? Nie chodzi o to by cały skrypt przerobić na mix PHP z C, ale mieć możliwość odpowiedniego potraktowania wąskiego gardła.
A tak ogólniej, to sobie pomyślałem, że może miałby sens jakiś dodatkowy rodzaj zmiennej, takiej która ma raz na zawsze ustalony typ. Nie upieram się przy tym, bo mi trochę brakuje teorii języków, ale może to by uczyniło pracę optymalizatorów łatwiejszą.
Najprościej by było jakby przepisali wszystko na jakiś wysokopoziomowy język statycznie typowany (niekoniecznie C++). No, ale to jest strasznie dużo roboty, więc nie dziwię się wcale, że poszli tą drogą. Prowizorka, ale ważne że trochę działa.
Obawiam się, że i tak rozszerzenia będą konieczne, gdy:
1. stajemy przed poważnym problemem wydajnościowym, np. napisanie parsera, zakodowanie kosztownego algorytmu którego nie ma w standardowych funkcjach. 50% turbo w tym wypadku niewiele daje.
2. pomijamy względy wydajnościowe, ale nie możemy czegoś zrealizować, bo dostępne w PHP funkcje tego "nie widzą". Np. chcemy zaimplementować obsługę nietypowej bazy danych, jakiegoś odwołania do OS albo sprzętu.
2X przyśpieszenie kosztem kompilacji do C++ może wydawać się sporym osiągnięciem, ale przydały by się testy porównawcze z innymi językami. Na podstawie innych zestawień, które pamiętam, taki kod nadal będzie wolniejszy niż odpowiednik w Java/Python/Ruby itp (alfabetycznie).
Podobny projekt, kompilujący do bytekodów JVM chwalił się przyśpieszeniem od 3x do 6x.
Z biegiem lat, jestem coraz mniej przekonany do zalet statycznej kompilacji. Tak nawiązując do dyskusji o flagach kompilatora (powyżej). Całkiem niedawno walczyłem z kawałkiem kodu, który był szybszy w Javascript niż w C. Dopiero po licznych próbach, udało mi się tak dobrać flagi by czas wykonywania był "porównywalny".