ReadWriteWeb - Pri Facebooku so danes objavili, da njihovi inženirji delajo na prevajalniku, ki prevaja PHP kodo v C++. Osemmesečni projekt nosi ime HipHop for PHP in bo izdan pod odprtokodno licenco, obljublja pa precejšnje pospešitve izvajanja PHP aplikacij.
HipHop se obnaša podobno kot ostali prevajalniki, saj naprej opravi analizo kode in vseh deklaracij, zatem dodeli ustrezne tipe vsem objektom na koncu pa zgenerira vmesno kodo. Od ostalih se pa razlikuje v tem, da v je v primeru HipHopa ta vmesna koda v C++. Tule potem v prevajanje vskoči g++ in prevede rezultat z dodatnimi optimizacijami v strojno kodo.
O rezultatih prevajanja trenutno še ni veliko znanega, pri Facebooku pa pravijo, da je uporaba prevajalnika pri njih zmanjšala obremenitev strežnikov za več kot polovico. Druga trenutno znana dobra lastnost HipHopa pa je, da prevajana PHP koda ne sme vključevati stavka eval.
HipHop bi moral biti na voljo danes zvečer na GitHubu.
Ker prevedena koda porabi manj pomnilnika in CPUja kot taka ki se interpretira.
Torej, PHP je lahek jezik za naucit se, dobis ogromno programerjev, hitro se razvija v njem, ampak pozre veliko MB in Mhz ko se zivaja na strezniku. Nasprotno je pa c++ dosti bolj tog, ampak dela hitreje.
S hiphopom so pa pri FB naredili to, da ohranijo fleksibilnost razvoja v PHPju in izkoristijo prednosti izvajanja ze prevedene kode.
Ja men se zdi logično zakaj prevajajo v C++ in ne direkt v strojno kodo. Ker prvič je veliko več ljudi ki zna/obvlada C++ kot pa tistih ki obladajo strojno kodo, prevajat v C++ je lažje, ter prevajalniki in c++ v strojno kodo že obstajao in tudi dobro delujejo.
Je pa to samo moje mnenje glede na moje precej majhno znanje na tem področju.
As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug. We are able to get new engineers ramped up at Facebook a lot faster with PHP than with other languages, which allows us to innovate faster.
Kaj je HipHop for PHP:
HipHop for PHP isn't technically a compiler itself. Rather it is a source code transformer.
Zakaj spreminjati PHP kodo v C++ z HipHop for PHP in ne pišejo (prepišejo) določene dele kompleksne PHP kode v C++ kot "PHP extension":
PHP's roots are those of a scripting language, like Perl, Python, and Ruby, all of which have major benefits in terms of programmer productivity and the ability to iterate quickly on products. This is compared to more traditional compiled languages like C++ and interpreted languages like Java. On the other hand, scripting languages are known to be far less efficient when it comes to CPU and memory usage. Because of this, it's been challenging to scale Facebook to over 400 billion PHP-based page views every month.
One common way to address these inefficiencies is to rewrite the more complex parts of your PHP application directly in C++ as PHP Extensions. This largely transforms PHP into a glue language between your front end HTML and application logic in C++. From a technical perspective this works well, but drastically reduces the number of engineers who are able to work on your entire application. Learning C++ is only the first step to writing PHP Extensions, the second is understanding the Zend APIs. Given that our engineering team is relatively small -- there are over one million users to every engineer -- we can't afford to make parts of our codebase less accessible than others.
Znanje C++a je pri prevajanju nima nobene veze, saj večina programerjev tudi ne pozna RTLa pa veselo uporablja gcc.
Fora je preprosto v tem, da za C++ imaš že precej dobre optimizacijske prevajalnike (čeprav C++ ni lih jezik ki bi se dal izjemno optimizirati) in v tem, da očitno Facebook preprosto nima ljudi in časa (kar tudi omenjajo), ki bi znali napisati in vzdrževati "pravi" prevajalnik.
Piše da če vas zanima spletno programiranje da se učite PHP programski jezik ker boste bolj produktivni in inovativni. Za spremembo te kode v C++ in večjo učinkovitost izvajanja kode z vidika porabe CPU ciklov in porabe sistemskega spomina... Bo pa skrbel HipHop for PHP. ;)
Problem je sam v tem da maš preveč PHP aplikacij že spisanih, katere se ne splača portat na Javo... prav tako pa morš za programiranje v Javi (za razliko od PHP) dejansko znat vsaj malo programirat ;)
Problem je sam v tem da maš preveč PHP aplikacij že spisanih, katere se ne splača portat na Javo... prav tako pa morš za programiranje v Javi (za razliko od PHP) dejansko znat vsaj malo programirat ;)
Pri Facebooku so danes objavili, da njihovi inženirji delajo na prevajalniku, ki prevaja PHP kodo v C++.
Dejansko ni pravi prevajalnik. Prej kaksen converter.
Ne vem zakaj niso uporabili rajsi Roadsend PHP, ki bazira na LLVM s katerim bi lahko IMHO dosegli boljse rezultate. Ali pa phc. Ne dvomim da C++ pridela tukaj dodatni overhead, ki ga je tezko optimizirati oz. implementirati, kakor na kaksen bolj low level nivoju (lambda metode, reflection, dodajanje novih metod v classe, ...).
Mal sem skeptičen do pohitritve. Namreč, če aplikacija ni napisana v C++ stilu, potem ne dobiš dosti. Večina keywordov v C++ je namenjena temu, da aplikacija dela hitreje in ravno zato je C++ tako zaj*ban, če hočeš pravilno programirati v njem.
PHP ima že vgrajen garbage collector. PHP nima referenc (za neosnovne tipe), ampak le kazalce. PHP nima ne-virtual funkcij. PHP ima že vgrajeno introspekcijo. PHP scope spremenljivk je drugačen. Kako boš to prevedel v C++, da ne boš dobil še enkrat toliko overheada?!
da očitno Facebook preprosto nima ljudi in časa (kar tudi omenjajo), ki bi znali napisati in vzdrževati "pravi" prevajalnik.
Zakaj bi jih pa imel? FB ima enako težavo in enak izziv, kot ga ima vsako drugo podjetje z nekaj zgodovine IT-ja: legacy. Nesmiselno je vse prepisovati in vzdrževati v nekem drugem XYZ jeziku, če lahko to naredi stroj vse do sedaj zbrano znanje v ljudeh pa ohraniš.
interpreted languages like Java
Fail. Vsak svojega imena vreden JVM izvaja bytecode tako, da jo prevede v strojno kodo takoj, ko je to potrebno (JIT compile). PHP runtime pa je tisti, ki jo neposredno interpretira. Tudi razni cacher-ji za PHP shranjujejo samo preveden bytecode, s čemer se pridobi v hitrosti, ker več ni potreben korak iz izvorne kode v bytecode. Sam bytecode pa se še vedno interpretira.
Zato je hitrost izvajanja programov v JVM zelo blizu tistim prevedenim iz C/C++ neposredno v strojno kodo, v določenih (celo ne tako zelo obskurnih) primerih pa jo celo preseže. PHP pa igra nekje v nekem drugem področju.
Pa mimogrede še en blast from the past: Tudi VB že najmanj od 4.0 naprej (klasičen VB, ne VB.NET) aplikacije prevaja tako, da najprej VB kodo prevede v C++, potem pa C++ prevede v strojno. Yay! MS did it in 1995 already.
Večina keywordov v C++ je namenjena temu, da aplikacija dela hitreje in ravno zato je C++ tako zaj*ban, če hočeš pravilno programirati v njem.
Ok, najprej mnenje, da C++ kode ni glih enostavno optimizirati (enostavno v primerjavi s čim?), sedaj pa še neke rezervirane besede, ki omogočajo hitrejše delovanje...
Za prvo me zanima s čem se primerja, za drugo me pa zanima katere so te magične besede. Jaz namreč ne poznam niti ene.
Zato je hitrost izvajanja programov v JVM zelo blizu tistim prevedenim iz C/C++ neposredno v strojno kodo, v določenih (celo ne tako zelo obskurnih) primerih pa jo celo preseže.
huh, lahko podas kaksen primer oz. referenco? slisal sem sicer, da jvm optimizira kodo za racunalnik, na katerem tece... mogoce, ce je slab c compiler, ms/ intel pa dvomim, da prehiti.
Sicer pa nevem zakaj stroj nebi znal optimizirat. Vecina optimizacije so pac taki triki ki poslabsajo berljivost kode in povecajo hitrost izvajanja, tako da IMO celo boljse da to dela stroj, kot clovek :)
Zato je hitrost izvajanja programov v JVM zelo blizu tistim prevedenim iz C/C++ neposredno v strojno kodo, v določenih (celo ne tako zelo obskurnih) primerih pa jo celo preseže.
huh, lahko podas kaksen primer oz. referenco? slisal sem sicer, da jvm optimizira kodo za racunalnik, na katerem tece... mogoce, ce je slab c compiler, ms/ intel pa dvomim, da prehiti.
JVM predeve java bytecode v strojno kodo, takoj ko ugotovi da stvar malo veckrat rabis. Recimo ponavadi prva iteracija zanke se ni prevedena, ampak potem pa takoj prevede zanko in se stvar zacne izvajati zelo hitro. Ce hoces videti kako pocasna je java ki se interpretira potem pozeni z parametrom -Djava.compiler=NONE
Malo teorije. Primerjav hitrosti je veliko na netu, google it.
Dejansko ni pravi prevajalnik. Prej kaksen converter.
Džizs, kaj drugega pa je prevajalnik če ne "konverter"? Vzame eno kodo (karkoli je) in jo da v drugo kodo (karkoli je). Čist preprosto. In kot sem že v novici lepo razložo, se HipHop drži precej standardnega postopka prevajanja stvari.
Ok, najprej mnenje, da C++ kode ni glih enostavno optimizirati (enostavno v primerjavi s čim?)
V primerjavi z dobro zasnovanim jezikom. C++ ima nekaj smotanih (recimo temu "legacy" odločitev), ki delajo resne probleme pri analizi in s tem tudi večji optimizaciji kode. Recimo prevajanje ločeno datoteke in linkanje na koncu je ena takih cvetk (sicer so to že reševali, samo so v večini pridelali precej pankrtske pare prevajalnikov/linkerjev, ki niso bili kompatibilni z ničemer), templating sistem ti prav tako dela krasne probleme pri optimizaciji velikosti, potem splošna "low-level" zasnova je taka, da zahteva poglobljeno analizo kode (ki je tehnično NP-poln problem...) in preprečuje poglobljeno optimizacijo, avtomatska uporaba SIMD ukazov je prav tako otežena zaradi manjka jezikovnih konstruktov, ki bi dali prevajalniku nasvete o tem, da o manjku nekaj tako osnovnega kot je threading model v specifikaciji jezika niti ne govorim.
Bo dovolj?
JVM predeve java bytecode v strojno kodo, takoj ko ugotovi da stvar malo veckrat rabis. Recimo ponavadi prva iteracija zanke se ni prevedena, ampak potem pa takoj prevede zanko in se stvar zacne izvajati zelo hitro. Ce hoces videti kako pocasna je java ki se interpretira potem pozeni z parametrom -Djava.compiler=NONE
Tule je morda treba omenjati, da to dela samo HotSpot JVM v "client" konfiguraciji. Privzeta nastavitev je namreč "server" konfiguracija, kjer gre celoten program kar takoj čez JIT (kar podaljša čas zagona, se pa zato vse skupaj izvaja še hitreje).
Sicer pa nevem zakaj stroj nebi znal optimizirat. Vecina optimizacije so pac taki triki ki poslabsajo berljivost kode in povecajo hitrost izvajanja, tako da IMO celo boljse da to dela stroj, kot clovek :)
Ker stroj ne zna kaj si ti hotel s tistim napisati (še posebej v najnižjih jezikih) in ker mora biti zaradi tega čimbolj konzervativen, da ne vnese lastnih hroščev v končni program (recimo GCCjevci so se v zgodnjih verzijah uspešno v nogo ustrelili s preveč agresivnimi, a zelo "common sense" preprostimi, optimizacijami pri številih s plavajočo vejico).
Malo teorije. Primerjav hitrosti je veliko na netu, google it.
Od tistih treh potencialnih točk, kjer je C/C++ počasnejši, sem sam že večkrat srečal 2. točko: GC opazno pospeši delo z objekti na kopici. Dodatno k temu pa se prišteje še lastnost GC-ja, da konsolidira operacije na kopici. free/malloc oz. new/delete ne porabita veliko časa pri posamičnih klicih, vendar je poraba opazna, ko je potrebno narediti večje število operacij. GC v modernem JVM počaka, da se sprosti večji blok, nato pa ga sprosti kot celoto, kar je cenejša operacija, kot pa sprostiti npr. 10.000 posamičnih blokcev pomnilnika.(*)
V primerjavi z dobro zasnovanim jezikom.
Ja, naštel si cel kup pomankljivosti, še vedno pa ne vem kateri je tako zelo dobro zasnovan jezik, da se jim izogne... da se ga da tako zelo dobro strojno optimizirati.
Back on topic: kakorkoli že, mislim, da je prevajanje PHP v strojno kodo lepo nakazalo kje so omejive interpretiranih jezikov v splošnem. Pri širjenju je tako velikokrat ceneje, da se obstoječo opremo bolje izkoristi, kot pa, da se kupuje vedno nove škatle. C++ pa je tukaj samo nujno zlo, da so se izognili razvoju lastnega prevajalnika/optimizacije v strojno kodo. Za ta jezik je oboje že na voljo in stroškovno se razvoj tople vode v tem primeru evidentno ne bi izplačal.
(*) Ja, vem, da lahko to v C++ narediš sam, s knjižnico ali pa z uporabo OS API-jev. Niso pa to elegantne rešitve, ki bi pripomogle k manjši ali bolj berljivi kodi. Performančno pa dosežejo predvsem izenačenje z JVM, če pa tega že presežejo, pa so razlike minimalne. Praviloma tudi vedno manjše, kot bi jih vložen čas upravičeval.
Resnični vprašanje je koliko je PHP koda povezana z loadom na HWju? PHP ni programski jezik za obdelave itd. zna pa hitro uporabljat loočene zunanje servise, ki so optimirani.
Skratka če znaš izkoriščat moč podatkovnih baz in optimirat "obdelave" z nečim na ravni strjne kode ti PHP porablja DO 1% vseh resoursov!
Po domače povedano en napačen (neustrezen, manjkajoč) index na mysql tabeli lahko povzroči dvig celotnih resoursov za 1000%, strojno preveden PHP napram neprevedenemu bo pa pridobil max. 10%.
FB je spisan zanič zato pa ima probleme s PHPjem; oz. sam še nisem videl da bi bilo ozko grlo v PHPju; večinoma je to baza, konfiguracija http serverja, FS, ...
@Utisevalec: torej na kratko povedano praviš, da razvijalci FB nimajo pojma kaj počno in zato optimizirajo nekaj, kar nima veze z ničemer, njihovi empirično zbrani podatki pa so napačni, saj nikakor ne more biti res, kar pravijo.
prav tako pa morš za programiranje v Javi (za razliko od PHP) dejansko znat vsaj malo programirat ;)
Ja, taka je razširjena percepcija.
Ampak če v PHPju nekdo nekaj spaca (ne da bi pravzaprav vedel kaj počne), je to še vedno le zmazek. Tak da tudi za PHP ni slabo, če znaš malo programirati. ;)
@Utisevalec: torej na kratko povedano praviš, da razvijalci FB nimajo pojma kaj počno in zato optimizirajo nekaj, kar nima veze z ničemer, njihovi empirično zbrani podatki pa so napačni, saj nikakor ne more biti res, kar pravijo.
Hm...
Troll....
Hja, samo taksno trolanje ni dalec od resnice.
Takoj ko PHPju naraste kompleksnost se zacnejo kazati pomanjljivosti samega jezika. Kakrsna koli telovadba v PHPju te stane precej veliko casa. Ze ena sama zanka v kateri premetavas stringe sem ter tja je lahko cokla v celi aplikaciji.
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...
@Utisevalec: torej na kratko povedano praviš, da razvijalci FB nimajo pojma kaj počno in zato optimizirajo nekaj, kar nima veze z ničemer, njihovi empirično zbrani podatki pa so napačni, saj nikakor ne more biti res, kar pravijo.
Hm...
Troll....
Ne ne pravim ...
Če je PHP ozko grlo potem naj gredo na kaj drugega .. aja ne morejo, so že globoko v dreku! FB se je razvil prehitro oz. na osnovah, ki niso predvidevale takih razsežnosti, zaradi tega je postal počasen in je edina pohitritev nadgradnja HW - oz. je ceneje narediti optimizacijo PHPja kot pa spisat kodo na novo (to veliko pove o stanju kode in razsežnostih problema).
To da imajo probleme s PHPjem pa ne morem razumet, saj sam FB (ogrodje in vse osnovne funkcionalnosti) sestojijo iz podatkov. Če imajo te podatke v razumno postavljenih podatkovnih bazah potem se vsa preračunavanja in filtriranja izvajajo tam. PHP je (kot sem omenil) samo vmesnik, ki ti dinamično porine vsebino v browser!
Pa da ne bo kdo razumel narobe, sam ustvarjam v PHPju močne aplikacije in je pri meni že primarni jezik tudi za shell oz. sistemske skripte.
Nekdo je omenil Zend Optimizer ... jst pa omenjam eAccelerator; to so orodja za smisleno optimizacijo PHP skript (izvedena koda in cache).
Džizs, kaj drugega pa je prevajalnik če ne "konverter"? Vzame eno kodo (karkoli je) in jo da v drugo kodo (karkoli je). Čist preprosto. In kot sem že v novici lepo razložo, se HipHop drži precej standardnega postopka prevajanja stvari.
Potem, ko preberes besedo racunalnik, si v mislih predstavljas obicajni kalkulator? Bodimo cimbolj splosni pa bo folk mislu da je to dejansko ta prav compiler, ki bo nekega dne podpiral PHP v celoti.
Problem language converterjev (to se pravi visje nivojskih med sabo) je vedno, da skoraj nikoli ne bodo podpirali vso funkcionalnost izvornega jezika. Ce jo pa ze bodo, bodo pa doloceni deli sila pocasni. Pri kompilerjih je pa seveda to drugace, ker je ciljni jezik nizji.
Potem, ko preberes besedo racunalnik, si v mislih predstavljas obicajni kalkulator? Bodimo cimbolj splosni pa bo folk mislu da je to dejansko ta prav compiler, ki bo nekega dne podpiral PHP v celoti.
Daj preberi si še enkrat prvi odstavek tvojega linka. Poleg tega... morš meti hudo domišljijo da C++ označiš za isto nivojski kot PHP :P
Me zanima kako ta "kompiler" prevede taksne metode.
Preprosto, je ne. Kar je tudi jasno napisano. Kar je tudi common sense. Statični compiler mora zbuildat zraven interpreter ali samega sebe za to simulacijo.
Tak da tudi za PHP ni slabo, če znaš malo programirati.
Še huje: za PHP menim, da je nujno potrebno, da že znaš dobro programirati, če kaniš početi karkoli bolj kompleksnega - nekaj kar presega linearno funkcijo, ki doda podatke v HTML predlogo.
Takoj ko PHPju naraste kompleksnost se zacnejo kazati pomanjljivosti samega jezika.
Sintakse ali runtime? Za runtime se ve, da interpreterji ne omogočajo ravno nekih hudih performans. To konec koncev tudi ni njihov cilj. Za sintakso pa se da povedati marsikaj negativnega, mislim pa, da so v ta projekt vodile pomankljivosti interpreterja in ne omejitve sintakse.
Cela stran govora optimizaciji, pa niti beseda o Zend Optimizer
Zato ne, ker je shranjevanje bytecode nekaj, kar naj bi normalen runtime naredil avtomatično, ne pa nekaj "ekstra". Pa tudi zato ne, ker interpreter še vedno interpretira bytcode in tako sploh ne igra iste igre, kot jo igra prevajalnik. Hruške in krompir.
Če je PHP ozko grlo potem naj gredo na kaj drugega .. aja ne morejo, so že globoko v dreku!
Dobrodošel v ResničenSvet™, kjer ne vržeš celotne razvojne ekipe in vsega znanja skozi vrata samo zato, ker si zadel plafon. Katera koli druga odločitev bi bila bistveno bolj tvegana, imela bi za posledico bistveno višje stroške in prehod bi trajal bistveno dlje, kot bi to bilo potrebno.
FB se je razvil prehitro oz. na osnovah, ki niso predvidevale takih razsežnosti
Če govorimo o PHP je to vezana trgovina. Z alternativnimi okolji se ne bi tako hitro razvijal in ga bi prehitel nekdo drug. S PHP pa se zgodi pač to, kar se je zgodilo. V prvem primeru FB sploh ne bi obstajal, v drugem primeru pa imaš, kar pač imaš.
in je edina pohitritev nadgradnja HW
RTFA. Kar so naredili so naredili zato, ker HW več ni možno nadgrajevati. Zakaj ne, je stara zgodba: scalability gre v zadnjih letih horizontalno. Več vzporedno delujočih jeder, frekvenca posamičnih jeder pa se bistveno več ne zvišuje. PHP runtime tega preprosto ne prenese in je res postal performančna cokla. Težavo je FB rešil tako, da ni zamenjal sintakse, ampak je vrgel ven runtime, ki preprosto več ne izpolnjuje zahtev. O vzrokih za to posledico so javno jokali že lani, če ne še prej...
To da imajo probleme s PHPjem pa ne morem razumet, saj sam FB (ogrodje in vse osnovne funkcionalnosti) sestojijo iz podatkov.
Ko boš imel sistem, ki se razteza preko 5% števila strežnikov, ki jih obvladuje FB, ki bo dostopal do 5% podakov, ki jih hrani FB in, ki bo stregel 5% sočasnih uporabnikov, kot jih streže FB, potem boš zagotovo razumel. Do takrat pa tvoje dosedanje izkušnje pač ne zadoščajo. Stvari niso niti pod razno tako enostavne.
Daj preberi si še enkrat prvi odstavek tvojega linka. Poleg tega... morš meti hudo domišljijo da C++ označiš za isto nivojski kot PHP :P
Jasno! C++ in PHP sta oba visjenivojska jezika.
The name "compiler" is primarily used for programs that translate source code from a high-level programming language to a lower level language
. Evo drugi odstavek. In to jaz pravim da je ZAME PRAVI kompajler.
Dejansko potem ti pravis konverjerju iz C# v VB.NET in obratno PRAVI kompiler. Jaz bi mogoce to razlozil keremu, ki nima pojma o programiranju, ne pa na slo-tech strani. Sorry.
To da imajo probleme s PHPjem pa ne morem razumet, saj sam FB (ogrodje in vse osnovne funkcionalnosti) sestojijo iz podatkov.
Ko boš imel sistem, ki se razteza preko 5% števila strežnikov, ki jih obvladuje FB, ki bo dostopal do 5% podakov, ki jih hrani FB in, ki bo stregel 5% sočasnih uporabnikov, kot jih streže FB, potem boš zagotovo razumel. Do takrat pa tvoje dosedanje izkušnje pač ne zadoščajo. Stvari niso niti pod razno tako enostavne.
Razumem ... FB engine za load balancing teče v PHPju; nadzor sistema teče v PHPju; SQL server je dejansko PHP CLI skripta, ki streže bazo! To so stvari, ki delajo overhead v sistemu in edino uporaba PHPja na teh mesti ima za posledico lahko 1x hitrejše izvajanje celotne apliakacije (FB cluster) če jo kompajlaš. Če uporabljajo PHP v ta namen so zgrešili že prvi ovinek.
Kot sem rekel; pravilna uporaba PHPja pomeni, da ko pride HTTP zahtevek od klienta, ga http server usmeri in požene PHP (10% loada casa zahtevka), PHP zahtevek po algoritmu obdela (10%) in pošlje na višji nivo (relacijska/objektna baza), kjer se sprožijo poizvedbe v za-to pripravljenem in optimiziranem okolju (60%), rezultat poizvedb gre nazaj na PHP ki ga dodatno obdela in oplemeniti (10%), nato pride nazaj do http serverja in le-ta ga vrne klientu (20%). Vmes so overheadi na ravni protokolov znotraj sistema oz. mreže (skupno +10%) ... skratka 90% procesorske moči za zahtevek gre za razne HTTP serverje, bazno okolje, komunikacijske protokole - PHP jih pobere pa 10%.
Na FB se uploada 2000 slik na sekundo, servira se jih 1,2 milijona na sekundo, o velikosti baze nebi. Nekaterim to nekaj pomeni, drugi pa to enacijo z enim wordpress blogom :)
Da, ampak bytecode caching nima veliko veze s tistim, kar dela zadeva opisana v novici.
V primeru, da imaš na strežniku nameščen PHP je že skoraj samoumevno, da imaš nameščen tudi nek bytecode cacher (xcache / eaccelerator / whatever).
OK, v čem se pa potem pefromančno razlikuje PHP bytecode od Java in .NET bytecode?
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...
V tem kar smo zgoraj povedali, da se java bytecode (predvidevam da tudi .net) v vecini primerov ne interpretira ampak se ob zagonu prevede v strojno kodo (JIT).
Največja napaka desetletja je bila narejena 4. novembra 2008
Oni so goljufali in Alah je goljufal, Alah je najboljši prevarant. (Koran 3:54)
Citiraj svetega očeta Benedikta XVI. in postani "persona rudis"...
Sheeshh. Bistri, saj je res že vse zgoraj popisano. Pozabi že enkrat na bytecode. Ta se interpretira, JVM in CLR pa delata JIT. Primerjave med tema dvema pristopoma sploh ne more biti. Hruške in krompir.
Relacijska baza za sistem v velikosti Facebooka? Srsly?
Zakaj pa ne? S pravilno implementacijo je to keks za "en SQL server".
ROFLMAO. Ta odgovor mi je pa res polepšal današnji večer.
Ali bi morda spet potrebovali kakšen članek ali novico na temo kje RDBMS "popuši" in zakaj obstajajo tudi drugačne baze podatkov.
Ali pa se raje začnemo pogovarjati o spindlih, pa kako zahteve razpršiti in optimizirati dostope do diskovja in morda še kakšno o scatter-gather (map reduce) pristopih, ki sestavljajo skupaj vsebino neke strani.
PHP runtime zagotovo ni ravno dorasel takšnim dimenzijam dela, kot jih ima FB. Vendar pa po drugi strani brez PHP kot jezika (sintakse) FB sploh ne bi bil nikoli spočet.
Glede PHP bytecode-a. Primer za tiste, ki poznajo malo bolje JVM in CLR. To je del vmkit projekta (LLVM podprojekt), ki skompajla Java in .NET IL v native kodo. Kolikor vidite iz te kode je LLVM koda napram GCC neprimerno bolj clean za studiranje in delanje svojih kompaljerjev. Zakaj ne bi nekaj podobnega naredili za PHP? Poglejte si tudi clang/LLVM (C++/C/ObjC kompiler).
Druga moznost, glede na to da je MS investiral kar nekaj denarja v Facebook, bi lahko npr. uporabili DLR, ki ga uporablja IronPython in Ruby frontenda za .NET CLR.
Skratka blazno me zanima zakaj so izlocili druge moznosti. Namrec razni PHP acceleratorji ze samo s cache OPcodes so vsaj 50% hitrejsi, kolikor tudi oni trdijo za to resitev. Upam da pridejo cimprej kaksni benchmarki.
In se nazadnje. Veliko resitev bazira na eval funkcionalnosti. Zelo preproste in ogromno uporabljene resitve so razni MVC, Smarty in podobno, ki bazirajo na nekih zunanjih templatih, ki seveda vsebujejo kodo, ki se v ozadju klice kot eval.
Se raje ne vtikam v vojno o tem kako je php dober jezik ali ne.. pri sistemih velikostnega reda FB se pomoje precej pozna, da se čim več stvari dogaja asinhrono, da nimaš ravno triggerjev ampak background jobe itd. Drug velik point je to, da so zelo verjetno bottlenecke že sproti izolirali in jih ponovno implementirali izven php okolja, če je bilo to le možno.
V tem sistemu dobesedno preskočijo vse sloje abstrakcije web serverja, file systema, .. in gredo direktno alocirati bloke na disku s kompletnim in-memory indeksom. Verjetno je serviranje fotk ratal bottleneck hitreje kot pa generiranje php strani - vsaj sodeč po precej hardcore implementaciji. Skratka - optimizacija jezika je bila stvar, ki so se jo lotili po tem ko so že izčrpali možnosti pohitritve arhitekture baz in serviranja slik. Naslednja stvar za poštimat je izgleda bil php.
@mspiller: OK. Smo poštekali. Rad imaš LLVM. Je zanimiv. Je zabaven. Je pregleden. Got it! Ampak v tvojih rokah izgleda kot kladivo, vsak problem, ki ga vidiš pa kot žebelj.
Morda si pa spregledal vse, kar je bilo od 2008 naprej napisano o FB in kar je bilo napisano že tukaj: - da eksplicitno niso želeli narediti svojega prevajalnika v native codo, temveč so želeli izkoristiti že obstoječe projekte - da nimajo želje "študirati optimizacijo", da bi jih zanimalo kako pregledna koda je v GCC - da ne bodo stran vrgli celotne arhitekture in infrastrukture samo zato, da bodo naredili prehod na CLR - da razni PHP eacceleratorji delajo samo cacing bytecode in ne prevajajo v native, kar se je izkazalo kot omejitev (RTFA) - še več rešitev, kot pa na MVC ali pa smarty bazira na kodi, ki jo študent 1. letnika FRI potegne ven iz svoje riti, pa to še ne pomeni, da je rešitev vsaj približno uporabna za dimenzije s katerimi se srečuje FB. - eval is evil in FB ga ne potrebuje.
Kot manjša zgodbica v razmislek pa je nek zelo znan in široko uporabljan kos kode napisan v PHP, ki poganja eno izmed bolj znanih spletnih mest v Sloveniji. Pa sploh ne najbolj obiskano. Za RDBMS zadošča en strežnik, za PHP skripte je potrebno imeti več njih, da se zahtevki porazdelijo. Strojna oprema, čeprav performančno zelo sposobna, preprosto ne omogoča, da bi en strežnik s PHP-jem stregel vse zahteve. Navkljub vsem memcached in eaccelerator trikom. Nea gre. Ko enkrat srečaš takšen sistem, potem daš kapo dol razvijalcem FB, da so to ladjo s talo malo spremembami v PHP runtime peljali tako dolgi in jo pripeljali tako daleč.
Ni za prazen nič v članku napisano, da so povabili "Zend" k sebi, da jim pojasnijo kaj so storili. Sam bi prej rekel, da jim pojasnijo kje ga (zendovci) serjejo.
Na FB se uploada 2000 slik na sekundo, servira se jih 1,2 milijona na sekundo, o velikosti baze nebi. Nekaterim to nekaj pomeni, drugi pa to enacijo z enim wordpress blogom :)
Kaj pa ima to veze s slikami? Saj jih ne shranjujes v relacijsko bazo, se meta podatkov o slikah ne.
Veze ima to samo toliko, da se pojasni, da je že na statični vsebini takšna količina prometa, da se ti zvrti... nekateri bi pa za seboj vlekli še neke RDBMS-je in govorijo o "pravilno postavljenih indeksih".
Kar je čisto lepo in prav, ampak s FB to nima nič skupnega in številke včasih pomagajo doumeti razliko.
Veze ima to samo toliko, da se pojasni, da je že na statični vsebini takšna količina prometa, da se ti zvrti... nekateri bi pa za seboj vlekli še neke RDBMS-je in govorijo o "pravilno postavljenih indeksih".
Kar je čisto lepo in prav, ampak s FB to nima nič skupnega in številke včasih pomagajo doumeti razliko.
No, pravilno postavljeni indexi nekaj stejejo, to je ja itak jasno! ;)
No v glavnem gre pa zato, da se tudi relacijske baze lahko skalirajo in tudi ogromne kolicine podatkov lahko serviras iz relacijske baze vsekakor pa se to ne strese iz rokava kar tako v enem popoldnevu. Poleg tega pa vsega vseeno ne mores tlaciti v relacijske baze.
