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

Skaberen af PHP, danske Rasmus Lerdorf, ser ikke Facebooks nye PHP-til-C++-kodegenerator som noget, der for alvor skaber røre i PHP-andedammen.

Den danske skaber af scripting-sproget PHP, Rasmus Lerdorf, hilser Facebooks nye PHP-til-C++-værktøj, Hiphop for PHP, velkommen og kalder det en positiv udvikling.

Men det vil ikke ryste de værktøjer, der allerede nu findes til at optimere PHP-kode, i sin grundvold, vurderer Rasmus Lerdorf i en e-mail til Version2.

Hiphop for PHP er netop blevet offentliggjort af Facebook, der har udviklet værktøjet for at kunne omdanne PHP-kode til C++ og dermed få hurtigere kode ud i den anden ende.

Det har i gennemsnit givet 50 procent mindre CPU-forbrug på Facebooks webservere, afhængigt af siden, ifølge Facebooks egne oplysninger.

Facebook har månedligt over 400 milliarder PHP-baserede sidevisninger.

Vil ikke skubbe til Zend's position
Men Rasmus Lerdorf vurderer ikke, at Hiphop for PHP vil få de store konsekvenser for eksisterende værktøjer, der også er sat i verden for at optimere PHP-kode.

Ét af dem stammer fra firmaet Zend, som også står bag store dele af udviklingen af PHP.

Virksomhedens kommercielle produkt Zend Immediate Code kan oversætte PHP til en form for bytecode, hvilket ifølge virksomhedens egne oplysninger kan forbedre ydelsen med 40 til 100 procent.

I en e-mail til Version2 skriver Rasmus Lerdorf, at Hiphop for PHP efter hans vurdering ikke vil ændre den rolle, Zend spiller i PHP-miljøet.

»Jeg tvivler på det. Det (Hiphop for PHP, red.) er ikke et nyt runtime, men en PHP-til-C++-kodegenerator med nogle restriktioner,« skriver Rasmus Lerdorf.

Er der behov for et nyt runtime? Vi har tidligere talt om, at Yahoo's hjemmesider kører på generisk PHP, så hvorfor kunne Facebook ikke bruge de samme tricks som Yahoo?

»Facebook har besluttet, at de ikke har lyst til at skrive skræddersyede udvidelser i C/C++. Yahoo, derimod, har mere end 500 skræddersyede udvidelser, som de bruger til at interface'e med de forskellige, komplicerede backend-systemer, der klarer størstedelen af arbejdet,« skriver Rasmus Lerdorf.

Hiphop for PHP er nu frigivet som et open source-værktøj. Hiphop fungerer ved at oversætte PHP-kode til optimeret C++-kode, som igen kan oversættes med en C++-compiler og dermed give hurtigere kode.

Samtidig skræller Hiphop for PHP en række sjældent brugte features ud af PHP ? eksempelvis funktionen eval() ? fra for igen at forbedre ydelsen af koden.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (34)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Makholm Blogger

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.

  • 0
  • 0
Jesper Louis Andersen

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.

  • 0
  • 0
Carsten Sonne

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.

  • 0
  • 1
Ole Østergaard

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.

  • 0
  • 0
David Konrad

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.

  • 0
  • 0
Jacob Christian Munch-Andersen

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.

  • 0
  • 0
David Konrad

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.

  • 0
  • 0
Jacob Christian Munch-Andersen

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

  • 0
  • 0
David Konrad

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.

  • 0
  • 0
Rasmus Kaae

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.

  • 0
  • 0
Carsten Sonne

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

  • 0
  • 0
Carsten Sonne

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.

  • 0
  • 0
Carsten Sonne

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.

  • 0
  • 0
Thomas Vestergaard

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.

  • 0
  • 0
Per Sikker Hansen

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.

  • 0
  • 0
Carsten Sonne

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.

  • 0
  • 0
Peter Makholm Blogger

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...

  • 0
  • 0
Carsten Sonne

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

  • 0
  • 0
Jacob Christian Munch-Andersen

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.

  • 0
  • 0
Carsten Sonne

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.

  • 0
  • 0
Carsten Sonne

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.

  • 0
  • 0
Baldur Norddahl

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.

  • 0
  • 0
Baldur Norddahl

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.

  • 0
  • 0
Jacob Christian Munch-Andersen

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.

  • 0
  • 0
Log ind eller Opret konto for at kommentere