Dansk PHP-skaber til Version2: Facebooks PHP-værktøj er ingen revolution

Så vidt jeg ved så er det sjældent at det rent faktisk er script-koden der får en side til at køre langsomt. Ofte er det store queries mod databasen der dræner systemerne.

I artiklen "Så er det officielt..." angiver Facebook at de gennemsnitligt sparer 50% CPU-tid.

Blot et skift fra ASP til ASP.NET betyder en kraftig forøgelse i hastigheden. Så det er den vej vi skal.

Jeg venter bare på PHP.NET på samme måde som ASP.NET :)

For et normalt lille hygge-websted er PHP som sådan nok ikke en relevant flaskehals. Men når man skal skalere i et omfang som Facebook er der mange tommelfingerregler der ændrer sig gevaldigt.

Jeg har arbejdet med systemer hvor alene det at stat()'e alle PHP-filerne inden man begyndte at læse dem ind gav en mærkbar performance-forringelse. At oversætte en hel applikation til en enkelt binærblob kunne have afhjulpet det problem.

Hvis ens database er en dårligt opsat MySQL på en server med magnetskivedisk så skal der ganske rigtigt ikke mange databasekald til for at det bliver en ret altoverskyggende flaskehals, men det er et scenarie som er MEGET langt fra optimal databaseydelse.

PHP bliver hurtigt flaskehalsen hvis din site bliver en success og du kan gøre backend-access tilpas billigt. Grunden til at Facebook godt vil have det her er at de kan undgå at skulle skalere deres serverpark yderligere og i deres størrelse kan det økonomisk godt betale sig at have et par udviklere til at lave deres egen specialdesignede udgave af PHP.

Et site som Facebook har allerede droppet SQL for lang tid siden (det egner sig temmeligt ringe til deres formål) og derved begynder det at betyde noget. PHP er svært at arbejde med grundet dets knopskydningseffekt: Ting er blevet til efterhånden som der har været behov for dem. Det koster hvis man godt vil lave maskinoversættelse af det.

Et site som Facebook har allerede droppet SQL for lang tid siden (det egner sig temmeligt ringe til deres formål)

Kilde?

Check Facebook arkitektur http://www.infoq.com/presentations/Facebook-Software-Stack - synes ikke at han nævner at de har droppet SQL, snarer optimering af MySQL og brug af memcache.

Lars

Ifølge http://cns.ucsd.edu/lecturearchive09.shtml#Roth driver facebook "tusindvis" af mySQL-servere, derudover f.eks logsystemet "scribe", masser er erlang, python - og nu har de altså fået deres c++ oversætter færdig. De 100 mia billeder, eller hvor mange det nu er, leveres via cache / CDN mv.

Well facebook har 100-vis af servere der kører php og en masser der kører databaser bagved. Hvis de kan fordoble performance i php med deres Hiphop tool så kan de slukke for en masse af deres webservere og spare en masse penge/strøm/co2.

Blot et skift fra ASP til ASP.NET betyder en kraftig forøgelse i hastigheden. Så det er den vej vi skal.

Det er fakta at kompileret kode er hurtigere end fortolket kode. Årsagen er den simple at kompileret kode kan afvikles direkte af processoren i modsætning til et fortolket sprog.

Blot et skift fra ASP til ASP.NET betyder en kraftig forøgelse i hastigheden. Så det er den vej vi skal.

Det er fakta at kompileret kode er hurtigere end fortolket kode

Og hvad vil du så kalde .NET-kode - kompileret eller fortolket kode? Det er jo egentlig begge dele: Kildekoden oversættes til bytekode, og det fortolkes så runtime. Så i sidste ende køres det fortolket.

I tiden før HotSpot ville de fleste nok give dig ret i din udtalelse, men at sige kategorisk at kompileret kode er hurtigere end fortolket kode, giver ingen mening.

Det er fakta at kompileret kode er hurtigere end fortolket kode. Årsagen er den simple at kompileret kode kan afvikles direkte af processoren i modsætning til et fortolket sprog.

Tja, så længe naturligvis interpreteren ikke er designet til platformen. Assembler er jo også i princippet fortolket kode, f.eks. "compileret kode" er reelt set "forberedt kode". I stedet for alle disse krumspring med PHP=>C++, som jo i sidste ende er til =>byte, men under alle omstændigheder giver et overhead alligevel, bare mindre, kunne man måske sætte alle kræfter ind på et slags RISC-PHP, f.eks, der kan fortolkes af processoren direkte. Hvis ikke jeg husker fuldkommen forkert, men det gør jeg muligvis, blev der faktisk forsøgt sådan noget i de glade BASIC-dage i starten af 80'erne. Tror det hed "bee", eller sådan noget. Så hvorfor ikke i dag? Facebook kører med statsgaranti alligevel tilpassede apacher, så man kan jo lige så godt tage skridtet fuldt ud.

kunne man måske sætte alle kræfter ind på et slags RISC-PHP, f.eks, der kan fortolkes af processoren direkte.

Med forbehold for at jeg ikke er helt klar over hvad du mener så lyder det du snakker om ret meget som det ganske almindelige compiler koncept. En almindelig compiler oversætter koden til maskinkode som processoren kan køre direkte. PHP er et dynamisk sprog, hvilket groft sagt betyder at det indeholder nogle features som ikke har nogen simpel ækvivalent i maskinkode. Derfor må compileren bruge en masse ekstra kode, hvilket trækker ned i hastigheden.

Men i mange tilfælde bliver dynamisk kode slet ikke compileret da det er lettere bare at skrive en fortolker, som typisk vil være endnu langsommere.

Det er fakta at kompileret kode er hurtigere end fortolket kode.

Ja, med forbehold for at der er stor forskel på kvaliteten af både compilere og fortolkere, samt at det vist ikke er helt veldefineret hvad der er hvad.

Med forbehold for at jeg ikke er helt klar over hvad du mener så lyder det du snakker om ret meget som det ganske almindelige compiler koncept. En almindelig compiler oversætter koden til maskinkode som processoren kan køre direkte. PHP er et dynamisk sprog, hvilket groft sagt betyder at det indeholder nogle features som ikke har nogen simpel ækvivalent i maskinkode.

Jeg forstår din skepsis. Men assembler kan da også være dynamisk (det er ikke maskinkode, men alligevel) Og jeg er altså med på hvad forskellen på interpretere osv er, og hvorfor der skal oversættes - har trods alt nørklet med assembler og peek og poke osv.

Jeg tænker bare, helt naivt og primitivt "ud af boksen", at når vi nu i dag HAR flerkerne arkitekturer, så kunne man måske lave et reduceret PHP sprog der kunne fortolkes direkte, det kan man vel godt, og så lade de andre processer om det dynamiske, databasetilgang, talberegninger f.eks? Egentlig det samme som nu, men i stedet for at tænke "oversæt til maskinkode", eller C++, så sige at kernen skal kunne forstå "RISC-PHP". Lidt ligesom man begynder at lade mere og mere køre på grafikkortet, som vi vil se fremover. Altså, den enkelte CPU har lad os sige 8 kerner, lad den ene fortolke et reduceret ikke-dynamisk PHP, og resten om resten. Måske tåbeligt, men at "oversætte" PHP til C++ som igen oversættes til byte virker ikke fremtidsorienteret.

Et reduceret ikke-dynamisk PHP vil stort set blive til det samme som Java eller C++.

I øvrigt er der ikke nødvendigvis noget kørselstidstab ved at oversætte gennem flere led, C og C++ er gode mellemsprog som lægger sig forholdsvist tæt op ad hardwaren, hvis et stykke kode skal kompliceres væsentligt for at blive til C, så er det sandsynligvis fordi det er nødvendigt for at koden overhovedet kan blive til maskinsprog.

Processorkerner født til at afvikle et specifikt sprog forekommer som en ret dødfødt ide, sprog og processorer passer allerede sammen. De steder hvor sprog og processorer ikke passer så godt sammen er det fordi sproget bruger en struktur som det ikke er hensigtsmæssigt at implementere i hardware.

Er du i øvrigt helt på det rene med forskellen på bytekode og maskinkode? http://en.wikipedia.org/wiki/Bytecode

Processorkerner født til at afvikle et specifikt sprog forekommer som en ret dødfødt ide, sprog og processorer passer allerede sammen.

Virkelig, ud i al fremtid - og vi behøves aldrig mere tænke nyt? Naturligvis er min tankerække jo ikke særlig velfunderet, det er bare en ide, en strøtanke, men det er vel (forhåbentlig) ikke evig gyldigt, det du skriver ovenover. Nuvel, du har muligvis ret.

Hvis målet er at lave backend-koden super-duper hurtig. Hvorfor så overhovedet skrive det i et fortolket sprog som PHP? I mit hoved ville det være bedre at skrive det i f.eks. C++ eller tilsvarende.

Og hvad vil du så kalde .NET-kode - kompileret eller fortolket kode? Det er jo egentlig begge dele: Kildekoden oversættes til bytekode, og det fortolkes så runtime. Så i sidste ende køres det fortolket.

Nej, bytekoden i IL bliver JIT kompileret af CLR'en inden den afvikles direkte på processorren på samme måde som C, C++, Delphi, VB og andre kompilerede sprog.

http://www.programmersheaven.com/2/FAQ-DOTNET-MSIL-Explained

Hvis målet er at lave backend-koden super-duper hurtig. Hvorfor så overhovedet skrive det i et fortolket sprog som PHP? I mit hoved ville det være bedre at skrive det i f.eks. C++ eller tilsvarende.

Du skal jo have en webserver der kan finde ud af at afvikle din backen-kode. Samtidig skal det være et potentielt performance problem. Det er nok trods alt ikke så tit af afviklingsmiljøet er den store flaskehals.

Hvis der ikke kræves web adgang bliver backend'en jo oftest også afviklet i et andet miljø end en webserver og kodet i et kompileret sprog, f.eks. C++. Hele problemet er sådan set kommunikation og snitflader. Her vinder HTTP og browseren stort over alternativerne.

Ja, med forbehold for at der er stor forskel på kvaliteten af både compilere og fortolkere, samt at det vist ikke er helt veldefineret hvad der er hvad.

Jo, Det er helt veldefineret. Kompileret kode er kode der kan afvikles direkte af hardwaren (evt. en virtuel hardware). Fortolket kode er alt det andet.

Det er klart at kode der afvikles af en virtuel maskine, jo i sagens natur vil være langsommere end kode der afvikles af fysisk hardware.

Det er klart at kode der afvikles af en virtuel maskine, jo i sagens natur vil være langsommere end kode der afvikles af fysisk hardware.

Med risiko for at starte en flame-war, men netop det der eksempel holder ikke.
Kode afviklet på Javas Virtuelle maskine sker f.eks. meget hurtigere end afviklingen af almindelig bytekode direkte på jernet.

Problemet med virtuelle maskiner optræder udelukkende i forbindelse med allokering af system-ressourcer. Hvilket gør, at de bestemt langtfra altid er det rigtige valg.

(De kan til gengæld føles langsommere, fordi det - ligesom med en fysisk maskine - tager lidt tid at starte dem op.)

Jeg vil også godt protestere mode de skarpe skelnen mellem fortolket og kompileret kode. F.eks. bliver Java kompilet til et format, der fortolkes af JVM'en. Distinktionen ligger i programmernes rolle - ikke i inputtet.

Hvorfor skulle man trækkes med at skrive C++ i hånden, når man kan skrive det hurtigt i PHP og derefter oversætte det til C++? Performance-mæssigt vil det være det samme resultat, men ved at skrive det i PHP først sparer du en masse udviklingstid oveni.

Jeg vil også godt protestere mode de skarpe skelnen mellem fortolket og kompileret *kode*. F.eks. bliver Java kompilet til et format, der fortolkes af JVM'en. Distinktionen ligger i programmernes rolle - ikke i inputtet.

Fair nok. Beskrivelsen var upræcis. Helt præcis er forskellen afviklingen af koden.

Kompileret kode kan afvikles direkte af en (måske virtuel) hardware.

Fortolket kode behandles bid for bid af en fortolker. Et klassisk eksempel er en tekstfil der læses, parses og eksekveres linie for linie.

Virtuelle maskiner har principielt 2 måder at afvikle en midlertidig byte kode (f.eks. MSIL eller java bytecode): kompilering til native binær kode (maskinkode), typisk via JIT kompilering eller at fortolke koden som en klassisk fortolker.

At Java afvikles hurtigere fortolket end JIT kompileret, fortæller vist mere om kvaliteten af JIT kompileren og integrationen af denne i Javas kørselsmiljø.

Rent teknisk vil det altid være det optimale at få afviklet kode direkte af hardwaren, i stedet for at have noget kode der skal afvikle koden.

Fortolket kode behandles bid for bid af en fortolker. Et klassisk eksempel er en tekstfil der læses, parses og eksekveres linie for linie.

Uha, det er vist ikke mange sprog der er implementeret sådan. Det skulle da lige være shell script. Jeg tror vist ikke engang at man gjorde sådan i klassisk tid...

@Peter Makholm

Måske du kan gøre rede for hvordan en fortolker virke anno 2010?

PHP er tilsyneladende fra version 4 gået over til også at bruge IL kode. Byte koden blive afviklet af en virtuel maskine, Zend Engine.

Så, rent teknisk bliver PHP faktisk først kompileret og derefter fortolket.

Præcis hvordan en virtuel maskine afvikler kode, skal jeg så ikke gøre mit klog på, men igen principielt er der kun 2 muligheder: kompileret (JIT) eller fortolket (evt. en blanding).

List teknisk forklaring på PHP IL:
http://blog.libssh2.org/index.php?/archives/92-Understanding-Opcodes.html

Måske du kan gøre rede for hvordan en fortolker virke anno 2010?

Jeg tror der skal tæt på én redegørelse til for hver fortolker/virtuelle maskine/compiler der findes. Det er jo et stykke Frankenstein uden lige når først vi begynder at se på V8 og lignende.

kompileret (JIT) eller fortolket (evt. en blanding).

Og det er ved den eventuelle blanding at forskellen på en kompiler og en fortolker bliver udtværet, måske bliver eval og lignende fortolket mens resten er kompileret, måske afvikles koden fortolket, men stumper som gentages ofte bliver kompileret, der er mange muligheder.

Jeg tror der skal tæt på én redegørelse til for hver fortolker/virtuelle maskine/compiler der findes. Det er jo et stykke Frankenstein uden lige når først vi begynder at se på V8 og lignende.

Der er skrevet adskillige bøger om CLR :-)

Det findes ligeledes en del, formegentligt mere, litteratur om JVM.

Og det er ved den eventuelle blanding at forskellen på en kompiler og en fortolker bliver udtværet, måske bliver eval og lignende fortolket mens resten er kompileret, måske afvikles koden fortolket, men stumper som gentages ofte bliver kompileret, der er mange muligheder.

Ja, men det laver ikke om på at rent teknisk er der 2 vidt forskellige ting.

Som oftest er det ret tydeligt hvordan et sprog bliver afviklet.

Ift. virtuelle maskiner, er det som regel også ret nemt at finde ud af hvordan den specifikke implementering afvikler koden. Bare man gider bruge tiden på at læse om det.

Lige for at slutte diskutionen af kan jeg anbefale at læse Structured Computer Organization skrevet and den gode Andrew S. Tanenbaum. Nogle kender ham måske fra studiet.

Han beskriver forholdet mellem kompilering og fortolkning således:

Det ene sprogs kompilerede output bliver fortolket af det næste underliggende niveau. Sådan kan man opbygge lag for lag en egentlig eksekvering.

På samme vis kan man betragte en processor som en fortolker af maskinkode. Processoren har selv microcode der faktisk afvikler maskinkoden.

Nederste niveau er manipulation af bits på gate niveau. Det er her det faktiske arbejde sker.

Sådan kan man betragte forholdet mellem fortolkning og kompilering. Kompileret kode er noget der direkte kan afvikles (fortolkes) af næste maskinlag.

Hvorfor skulle man trækkes med at skrive C++ i hånden, når man kan skrive det hurtigt i PHP og derefter oversætte det til C++? Performance-mæssigt vil det være det samme resultat, men ved at skrive det i PHP først sparer du en masse udviklingstid oveni.

Nej, det bliver næppe det samme resultat.

PHP er et sprog med dynamiske typer. Det vil sige at en variabel $i kan være et heltal, en streng eller noget helt tredie.

Tager du en stump kode, f.eks. "$j = $i + $i;" så er den generede C++ kode nødt til først at undersøge hvilken type $i har. Er $i et heltal, så er $j også et heltal som indeholder 2$i. Er $i derimod en streng, så er $j simpelthen 0. Koden kan derfor ikke oversættes til C++ som "j = i + i;" ().

I stedet skal det oversættes til noget i dur med:

j = i->t == INTTYPE ? new IntType(((IntType) i)->v + ((IntType) i)->v) : i->t == FLOATTYPE ? new FloatType(((FloatType) i)->v + ((FloatType) i)->v) : IntType(0);

(med forbehold for at det er et årti siden jeg sidst har lavet noget seriøst i C/C++, men ideen burde være klar nok).

(*) medmindre man bruger operator overloading til at simulere effekten, men den generede maskinkode vil være ordner mere effektiv hvis "i" er en "int"-type i stedet for en klasse.

De dynamiske typer kan man ofte komme ud over med en kompiler som ved hjælp af statisk analyse kan fastslå at nogle variable kun vil kunne antage bestemte typer af værdier. Eval funktionen er dog ret svær at passe ind i den sammenhæng.

Hvordan vil du lave typeinferens på kode som det her:

[code=php]
function foo($bar,$i) {
print $bar[$i]+10;
}
$bar[0] = "foo";
$bar[1] = 5;
foo($bar,0);
foo($bar,1);
[/code]

PHP er et minefelt af funktioner som acceptere eller returnere ukendte typer. Som illustreret giver selv et simpelt array problemer.

Dermed ikke sagt at man ikke kan lave en del optimering. Du kommer bare ikke uden om en masse tilfælde hvor du er nødt til at behandle variabler som ukendte typer.

Jeg skriver at nogle, ikke alle, variable kan reduceres til statiske. I pæn kode vil det gælde for næsten alle variable. Selvfølgelig bliver man nødt til at bevare funktionalitet til at behandle dynamiske variable som ikke kan reduceres. Men det vil normalt ikke være noget stort problem for ydelsen.