Názory k článku
PHP v rytmu Hip Hopu

Budete-li trochu studovat, zjistíte, že kvalita kódu a rychlost provádění jsou v nepřímé úměře. (Tedy: čím „hezčí kód“, tím pomaleší provádění).

Jelikož HipHop vytvářel (ten hnusný, zlý, ošklivý a velký Big brother, pan) Facebook, je naprosto zřejmé, jaký má ten projekt účel – rychlost. A jelikož narazili na limity PHP, které nelze dál posunout, tak měli dvě možnosti – buď to všechno přepsat, nebo si napsat quick’n’dirty řešení – HipHop je druhou variantou, ale jak se zdá, funguje.

Asi jsem se vyjadril moc neurcite - to co mi vadi je, ze misto rozumnych optimalizaci se provadi hromadny prevod do C++, ktery funguje pouze na specifickem OS a HW, ktery do sebe navic nabali vlastni web server - to je podle me ukazkova definice prasarny.
Jinymi slovy: "quick'n'dirty" = prasarna.

Takze si vlastne rozumime.

Jinak za rozumnou optimalizaci, ktera neni PRASARNOU, povazuji v prvni rade nejaky profiling, nalezeni bottlenecku, pak bud pouziti lepsiho algoritmu, coz byva casto vice nez dostatecne - a pokud to nestaci, prepsani POUZE bottleneckove casti do neceho rychlejsiho.
A nebo koupeni vice pameti nebo dalsich pocitacu - coz vyzaduje znalost konkretni situace - nekdy to muze byt levnejsi, nekdy ne.

A vidíte to. Vy tu diskutujete v diskuzi a Facebooku to, zdá se, funguje tak jak potřebuje. Je mnohdy lepší udělat prasárnu, než si vymýšlet, jak by to asi bylo teoreticky možná někdy lepší.

Proc by mel byt preklad do C++ prasarna? Pokud to chapu spravne, tak ten HipHop urcuje datove typy. Coz je ta hlavni optimalizace, jelikoz pokud vim, PHP je dynamicky typovany jazyk, takze musi typ zjistovat pri kazde operaci s promennou.

Nevim, jak byste vykonovou ztratu v tomhle chtel zjistit profilerem na urovni PHP. Samozrejme, muzete take profilovat samotne PHP; pak byste ale nejspis zjistil to, co vam rikam (staci se podivat, jak funguje hlavni interpretacni smycka), a predpokladam, ze to je to, co vyvojari HipHopu udelali.

Jen připomenu, že hiphop nepsali vývojáři Facebooku pro vás, ale pro sebe - na vás je pak posoudit, zda řešíte podobná omezení s podobnými parametry a výsledky cost/benefit analýzy. Pokud ne, nikdo vás nenutí to používat.

Naprosto presne! :-)

Ne, evidentně si nerozumíme.

Mohu pouze shrnout to, co psali i ostatní. Facebook to psal pro sebe, protože jemu to snížilo provozní náklady o 50%, jak tu psal autor článku.

Ukažte mi jiný způsob, jakým snížíte náklady o polovinu. Obávám se, že nákupem pamětí a procesorů a počítačů ty náklady nesnížíte. Optimalizace bottlenecků ty náklady taky neposune.

Ano, píšete-li kód v C nebo C++, není problém se ponořit v jedné proceduře do assembleru a část kódu přepsat. Ale v PHP to prostě nejde. Asi nerozumíte, že PHP má prostě nějaké limity, které už prostě dále posunout nejde bez změny technologií – a to přesně Facebook udělal.

A osobně si myslím, že je úplně jedno, je-li to řešení prasárna nebo ne. Důležité je, že to obsluhuje miliony požadavků za vteřinu, snížily se náklady, a ještě to funguje. Howgh.

Byla ještě jedna cesta s bottleneckem: Vytvořit si vlastní moduly PHP řešící právě tato místa třeba v C++ a ty potom v PHP používat. Když tuto techniku mohou používat vývojáři v Lua, tak proč ne v PHP?

Četl jste článek? Tuto techniku před HipHopem používali.

Článek jsem četl. Jsou 2 možnosti:
- snažili se optimalizovat části, které nemá smysl optimalizovat ve stylu pravidla 90:10
- chtěli vykopnout z operační paměti interpretr PHP

Podle mne je pravděpodobnější to druhé. Při zpracování textů rozdíl mezi kompilovanými a interpretovanými jazyky IMHO není zas tak podstatný, paměťová náročnost však mohla hrát svou roli.

Pokud vám bastl ušetří pár milionů dolarů, použijete ho?

Ona je otázka, zda nasazením HipHopu by se wikipedie naopak nezpomalila. Mám pocit, ale nehodlám to zkoumat, že wikipedia dost přepsala a značně zoptimalizovala zdrojové kódy řady funkcí v PHP ve své vlastní verzi.

Na rozdíl od HipHopu je zdokonalila použítím výrazně lepších algoritmů, než jsou v originálním PHP.

Aj napriek zlepšeniu algoritmov by ale stále bola réžia prekladu väčšia ako s použitím HipHop, či sa mýlim? HH by spracovával optimálnejší kód, čiže logicky by mal byť úmerne rýchlejší bez HH ale znova aj s HH.

Wikipedie by IMHO ničeho nedosáhla, protože poměr generovaného obsahu ku tomu cachovanému v místích oblastech je zanedbatelný.

Ta optimalizace by se měla týkat kódu, ne vlastních dat. Takže jednou se to přeloží do něčeho rychlejšího a potom už to funguje se všemi daty.

Nejde o optimalizaci dat, jde o to, že základem toho, že Wikipedie vůbec funguje, je masivní cachování. Tedy hodně velká část požadavků vůbec nedojde do PHP. (Ale když už tam dojde, tak by si to optimalizaci zasloužilo, byť si nejsem moc jist, jak moc je ten kód „PHP-bound“, i když prvotní testy HipHopu na MediaWiki vypadaly dost zajímavě.)

Díky za hezké představení HipHopu. Neuvažujete, že napíšete i o dalších technologiích Facebooku?

Nejprve se projde zdrojový kód, které se převede do jednotlivých jazykových elementů, tzv. tokenů. Z nich kompilátor vygeneruje bajtkód, tedy kód obsahující instrukce virtuálního stroje.

Popis je nepřesný. Z tokenů se musí ještě postavit abstraktní sytaktický strom (AST), aby byla jasná struktura programu. Teprve z něj se vůbec může generovat bajtkód.

Popsaný problém s Nette není vhodné řešit evalem, mnohem lepší by IMHO byla AOT kompilace šablon. Možná by si to vyžádalo i nějakou úpravu šablonovacího systému. Ten eval by se hodil spíše do první 'funguje to' verze.

Neříkám, že po tomto půjde již Nette bez problémů rozjet na Hiphopu, ale mělo by to řešit jeden z problémů.

Pro první "funguje to" verzi by snad mohlo stačit HipHopu předhodit projekt s již přeloženými šablonami (tzn. v tempu by byly PHP ekvivalenty Latte šablon).

Zkoušel to někdo?

To může narozdíl od evalu skončit (podobně jako některé další věci) na dynamickém načítání skriptů, ačkoli jsou již předkompilované.

PHP je v poněkud jiné situaci než V8: Na V8 obvykle buď běží jednoduchý skript (okořenění stránky), nebo nějaká webová aplikace (GMail), která se může malou chvíli načítat, ale pak má běžet rychle.

V prvním případě je režie malá, ve druhém př'ípadě není IMHO vzhledem k době běhu mnohdy až tak podstatná a kritická jako režie u PHP.

V8 má prostě JIT kompilátor (=> o néco vyšší režie při startu). A psát JIT pro PHP by se nevyplatilo, protože:
* u krátko běžících aplikací nemá dostatečný efekt a lepší je AOT (což vlastně udělali)
* AOT je jednodušší na implementaci než JIT.
* Změna životního cyklu PHP, která by umožnila nasadit efektivní JIT, by si mohla vyžádat přepsání aplikace a zasáhla by kvůli podpoře vláken dost i do vlastní implementace PHP.

Tedy, myslím, že udělali to nejjednodušší, co mohli, i když to tak možná na první pohled nevypadá.

Vyborny clanek ! Jiz delsi dobu se rozhoduju hip hop vyzkouset z vlastni zvedavosti . Myslim si , ze je to projekt mirne vydareny a pro "svizny" chod facebooku (pri tak velke zakladne uzivatelu) nezbytny. Tesim se na dalsi clanky open-sourceu z dilen facebooku :)

http://downloadingbirds.blogspot.com/2010/06/facebook-bezi-stale-na-php-mysql.html

Já tedy kód Facebooku neznám, ale rozhodně bych si nedovolil tvrdit, že Facebook není složitá aplikce :) Když člověk vezme v potaz množství dat, které jím proteče a to, že musí synchronizovat datacentra po celém světě, tak jsme rázem někde jinde.

Ano, kdybych napsal vlastní "Facebook" a rozjel ho pro své kamarády, tak to pravděpodobně nebude moc složitá aplikace.

Jj, přepsání do RoR by přineslo víc. Třeba celkem solidní zpomalení a spoustu nepěkných chvilek při snaze to vůbec rozchodit :)

* Vlastní zkušenosti - doteď jsem vyzkoušel cca 12 různých RoR webových aplikací a jsou děsně pomalé. Navíc rozhejbat je bylo peklo. Ale na Redmine nedám dopustit :)

RoR - Ruby? To je další interpretovaný jazyk, podobně jako PHP. Pomohlo by přepsání do C++ nebo jiného kvalitního kompilovaného jazyka blízko hardwaru. I Java je mnohem rychlejší než PHP nebo Ruby.

Ano, Java... Ale možná tak co se vývoje týče. Pravda, nevím jak je a tom Java u webových aplikací ale cokoliv desktopového je otřesně pomalé. Protože ale Javu neznám, tak nejsem schopen říct, jestli je to Javou nebo jen neschopností programátorů, co jí používají.

Kdyz to neznate, tak proc mate potrebu se k tomu vyjadrovat?

To už je takový národní zvyk :-(*)

Díky za názor o RoR. Chtěl jsem ho vyzkoušet na vytvoření webové aplikace, ale nemám s ním žádné zkušenosti. Jen jsem si udělal pár konstrukcí v Ruby a došel jsem k závěru, že mi tento jazyk nevyhovuje. Pomalé aplikace rád nemám a tak zřejmě RoR ani nebudu zkoušet.

Cely problem rychlosti PHP je velka "vzdialenost" od CPU. Optimalizacia PHP ma svoje hranice uz len tym ze bezi pod virtualnou masinou. Hip hop nerobi nic ine len "priblizuje" kod blizsie k CPU. Cim sa ziska potrebny vykon.
Este jedna dolezita vec, ktora tu nebola spomenuta Apache + PHP nieje velmi optimalna kombinacia s pohladu uspory pamate. To sa da nahradit ciastocne kombinaciou nginx + php_cgi. Ked sa vsak pozriete na pamatove naroky hip hop kompilovanej aplikacie, zistite ze pamatove naroky tejto kombinacie su velmi nizke. Na jednom zeleze tak mozete prevadzkovat viac aplikacii, obsluzit viac uzivatelov. Ide teda aj o financnu usporu.

Viem si predstavit este lepsie riesenie ako hiphop a to je kompilacia priamo do ASM daneho CPU :-) Takto je nutna konverzia php -> g++, g++ -> asm.

Brrr, měli by to přejmenovat, jinak se toho netknu :)

jedině METAL!

Ideálně, ale nemusí být. V podstatě by mi stačilo cokoli co není hip hop. Ať si to pojmenují třeba Justin Bieber, všechno bude lepší než hip hop.

| -1

takze Busta Rhymes by bylo OK?

Samozřejmě.

tak asi tu ted budu za hlupaka, ze mezi rapem a hip-hopem nedelam rozdil (a nebo jeste za vetsiho hlupaka, protoze nevim jestli je Busta raper nebo hip-hoper)

no metal by stejne byl lepsi, to jo

"JavaScript v prohlížeči Google Chrome je několikrát rychlejší než PHP" nejak se u tohoto tvrzeni nechytam, jak si je mam vysvetlit?

Napište si složité funkce v JavaScript a PHP. Následně je spusťte na stejném počítači pomocí Chrome a php intrepretu a sledujte, za jak dlouho spočítají výsledek. Možná se míchají jabka s hruškama, ale danému tvrzení to bude odpovídat.

Asi jako věta
"JavaScript v prohlížeči Google Chrome je několikrát pomalejší než C"

jo takhle, tak melo byt rovnou napsano interpretace, ted uz to chapu :-)

On totiž javascript v chrome není přímo interpretovaný, je kompilovaný do bajtkódu a až ten je (velmi rychle) interpretovaný.

JavaScriptový engine Chromu V8 nepoužívá bajtkód, ale je kompilován přímo do nativního kódu.

Jak je na tom Hip Hop v porovnání s bCompiler - rozšíření PHP, které umožňuje uložit přímo onen Bytecode do souboru, načíst ho a následně rovnou interpretovat? Výhda? Funguje by byla, že by fungovalo jakékoli rozšíření.

Rozšíření funguje transparentně, že zvládá jak orig. zdrojové kódy, tak soubory uložené v bytecode.

http://www.php.net/manual/en/book.bcompiler.php

Prakticky by mělo být podobně rychlé jako při použití PHP s cache bajtkódu (například APC nebo eAccelerator) – tedy odpadne parsování a generování bajtkódu, ale samotné vykonávání programu se nezrychlí.

HipHop je v produkčním nasazení, bCompliler je experimentální

http://www.php.net/manual/en/intro.bcompiler.php