Facebook-ontwikkelaars bouwen php-versneller

Ontwikkelaars bij Facebook hebben een source code transformer gebouwd die php-scripts omzet naar c++ en deze vervolgens compileert. Hiphop for PHP zou het cpu-gebruik op Facebook-webservers met 50 procent kunnen verminderen.

Software voor de scripttaal PHP is relatief eenvoudig aan te passen. Net als andere realtime geïnterpreteerde talen is PHP echter relatief traag en kan het veel geheugen van de webserver opslokken. Ontwikkelaars kunnen ervoor kiezen om php-scripts geheel of gedeeltelijk te herschrijven in het efficiëntere en snellere c++, maar hierdoor vermindert de toegankelijkheid van de code aanmerkelijk.

Ontwikkelaars bij Facebook hebben de afgelopen twee jaar aan het project Hiphop for PHP gewerkt om dit probleem op te lossen. De developers omschrijven hun creatie als een source code transformer die php-scripts omzet naar c++-code en deze vervolgens compileert met de gnu c++-compiler. Daarbij zijn enkele complexe maar relatief weinig gebruikte functies als eval() 'opgeofferd' om de snelheidswinst te maximaliseren.

Het grootste probleem voor de developers was dat de twee programmeertalen elk een fundamenteel ander typesysteem hanteren. Toch zijn de makers erin geslaagd om de load van de webservers van Facebook met HipHop for PHP tot 50 procent te verminderen. De broncode zal met een opensourcelicentie op de website GitHub gepubliceerd worden, zodat de community de php-versneller verder kan vervolmaken.

Video (4409735)

Reacties (116)

[kaesve]

Dit ziet er spannend uit.. ik vraag me af hoe dit precies werkt en hoe ze het verschil in typesysteem precies hebben opgelost. kan iemand daar misschien een tipje van de sluier over oplichten? als ik zo even snel het blog-artikel op facebook doorlees begrijp ik het nog niet echt namelijk..

word de code gewoon in zijn geheel geanalyseerd en daarna bekeken welke typen een variabele eventueel zou kunnen zijn/worden? is dat niet ontzettend bug-gevoelig?

[user109731]

Dit ziet er spannend uit.. ik vraag me af hoe dit precies werkt en hoe ze het verschil in typesysteem precies hebben opgelost. kan iemand daar misschien een tipje van de sluier over oplichten?

Ze gebruiken type inference om type informatie af te leiden. Van bepaalde variabelen kun je bijv. garanderen dat die altijd een int moet bevatten (het resultaat van een functie als strlen of een operator bijv.) Hiervoor kun je dan een C++ int gebruiken, en dat is uiteraard supersnel. Andere variabelen kunnen wel meerdere types bevatten, daar gebruiken ze een generiek type voor. Dat is natuurlijk langzamer, omdat je at runtime de juiste operator/functie moet kiezen voor het type, iets wat de PHP-interpreter voor elke operatie moet doen.

is dat niet ontzettend bug-gevoelig?

Nee, het type inference algoritme gebruikt bepaalde regels om types af te leiden, dat is in principe waterdicht.

[Reactie gewijzigd door user109731 op 23 juli 2024 07:09]

[MadEgg]

Lijkt me inderdaad lastig. Bijvoorbeeld bij object-serialisation in PHP, lijkt me vrij onmogelijk om dat in C++ te emuleren. Maar misschien valt dat ook in de categorie functies die opgeofferd zijn, net als eval.

Verder zijn objecten wel redelijk te herkennen, vooral bij de basic datatypes is het lastiger. Kan me zo voorstellen dat ze allen basic datatypen maar als string geimplementeerd hebben en een aantal functies gebruiken om die on the fly te converteren naar het geschikte datatype in C++.

[elmuerte]

Lijkt me inderdaad lastig. Bijvoorbeeld bij object-serialisation in PHP, lijkt me vrij onmogelijk om dat in C++ te emuleren.

Dat is niet onmogelijk hoor. De string object notatie van PHP is niet zo ingewikkeld, en de code genereren die van de C++ objecten een PHP object string maakt is bijna triviaal als je als je al de vertaling van het PHP type system hebt naar C++ type system.

Maar misschien valt dat ook in de categorie functies die opgeofferd zijn, net als eval.

Eval wil je in principe toch nooit gebruiken. Want het is een security risk, en het heeft behoorlijk performance impact (je kan bijvoorbeeld geen op-code cache gebruiken).

[MadEgg]

Nou ja, ik bedoel meer deserialisation natuurlijk. Je laadt een object uit een string, maar wat voor object is het? In PHP hoef je je daar niet druk over te maken, maar C++ doet dat natuurlijk wel, in ieder geval wel als er een 1-op-1 relatie tussen een PHP-class en een C++-class bestaat.

[Laurens-R]

Lijkt me niet zo onmogelijk hoor.

Ook PHP moet ergens in de pipeline geconverteerd worden naar native code voor de uitvoer. Dat gegeven alleen al maakt het per definitie mogelijk in C++.

Je zal er alleen een library aan functies omheen moeten maken, om het wat gemakkelijker te maken.

[wootah]

Oh ik dacht dat er zoiets kwam als eAccelerator, die cached gewoon php scripts zodat alles sneller gaat.
Heeft bij mij tot nu toe 30-50% meer snelheid gegeven
maarja, c++ is natuurlijk wel beter.

Wat ik niet begrijp is dat php niet object georiënteerd is en c++ wel... was het dan niet makkelijker om het in ansi c te doen? kun je het nog verder optimaliseren

[Chip.]

In principe zijn alle programeertalen object georiënteerd. Het is geen programmeer aspect enkel een zien/denk aspect.

[siepeltjuh]

Hmm echter moet de taal wel de middelen aanbieden om OO te werken.

PHP dat dat voor versie 4 niet, en met versie 4 eigenlijk nog niet best.

[Chip.]

Hoeft niet. OO is een manier van denken. Programmeertalen bieden enkel mogelijkheden om OO makkelijker te programmeren.

[Caelorum]

Dit lijkt alleen maar zo omdat er zo ontzettend veel OO-talen zijn.
Er zijn echter ook talen waarin het niet mogelijk is om objects te maken en waar OO programmeren dan wel echt onmogelijk wordt.

Daarnaast heb je ook de talen als Haskell met functional programming.

[Reactie gewijzigd door Caelorum op 23 juli 2024 07:09]

[deadinspace]

Dit lijkt alleen maar zo omdat er zo ontzettend veel OO-talen zijn.
Er zijn echter ook talen waarin het niet mogelijk is om objects te maken en waar OO programmeren dan wel echt onmogelijk wordt.

Dat is echt onzin. Zoals al genoeg mensen hier hebben gezegd, om object-georiënteerd te programmeren heb je geen OO-taal nodig.

Ik programmeer bijvoorbeeld redelijk veel in C (geen OO-taal), maar hou voor niet-triviale programma's meestal wel een OO-structuur aan. Bij OO in C is het gebruikelijk om een (pointer naar een) struct te gebruiken als object. Een World "object" is dan bijvoorbeeld zo te definiëren in C:

typedef struct _World World;
struct _World
{
____char *name;
____int connection_fd;
};

Constructor en destructor functies kunnen er dan als volgt uitzien:

extern World *world_create( char *name )
{
____World *w;

____w = malloc( sizeof( World ) );
____w->name = strdup( name );
____w->connection_fd = -1;

____return w;
}

extern void world_destroy( World *w )
{
____if( !w )
________return;

____if( w->connection_fd > -1 )
________world_disconnect( w );

____free( w );
}

En het aanmaken en gebruiken van World objecten gaat dan als volgt:

World *world;

world = world_create( "bla" );
world_connect( world, "tweakers.net", "1234" );

/* doe wat leuks */

world_destroy( world );

Daar, OO code in een niet-OO taal. OO-talen maken dit makkelijker, door een gunstigere syntax aan te bieden voor OO-constructies, en door sommige dingen wat te automatiseren, wat natuurlijk een voordeel is. Maar noodzakelijk is het zeker niet.

[Reactie gewijzigd door deadinspace op 23 juli 2024 07:09]

[sfc1971]

Eh, weet je dit zeker, want dat is toch ECHT niet zo.

[Kirth]

Inderdaad. Gaarne had ik Wousert eens zien OOP bronselen in ASM of zelfs C.

[MikeN]

In C kan het prima, je moet alleen zelf wat meer moeite doen.

[sys64738]

check this out: http://www.planetpdf.com/codecuts/pdfs/ooc.pdf

Je moet er van houden. Het is ook niet mijn ding. Liever een taal die deze plumbing dingen voor me doet.

[MadEgg]

PHP is sinds PHP4 object georienteerd, en sinds PHP5 doet het qua classes niet meer onder voor C++ en andere programmeertalen.

Zo vreemd is de keuze voor C++ dus niet. Bovendien denk ik dat de snelheidswinst als gevolg van het gebruik van C ipv C++ verwaarloosbaar is als de code afkomstig is van een source code tranlator.

[kaesve]

hier ben ik het niet helemaal mee eens.. php ondersteunt inderdaad programeren mbv classes en object-instanties, maar php is als taal niet bepaald georienteerd op het programmeren met objecten. Vooral doordat de taal niet type-strong is, is programmeren met objecten in php heel anders dan programmeren met objecten in bijvoorbeeld java of c#, want juist dan wil je weten met wat voor type object je steeds te maken hebt.

[sys64738]

Smalltalk is een van de puurste OO talen die ik ken en is tevens weak-typed.

Waek typing zegt niets over het wel of niet OO zijn van een taal. Net als strong-typing heeft weak-typing zijn voor en nadelen maar dat maakt het een of het ander niet minder of meer geschikt voor OO.

@s.stok: of je post is per ongeluk onder mijn post komen te hangen of je hebt mijn post niet goed gelezen. Ik probeer alleen maar uit te leggen dat static of dynamic typing niet bepaald of een taal OO is of niet.
Ik wist overigens niet dat php beide ondersteund maar het klinkt mij als een slecht idee. Je kunt twee style dwars door elkaar heen programmeren wat de leesbaarheid niet ten goede komt en je krijgt daarnaast de nadelen van beide typeringen op de koop toe.

[Reactie gewijzigd door sys64738 op 23 juli 2024 07:09]

[s.stok]

PHP ondersteund beide.
Je kan voor een parameter een bepaald type afdwingen, sinds PHP 5.3 kunnen dat PHP types als Array, String, Integer zijn.

Een Class of interface afdwingen is al langer mogelijk.
Sinds PHP5

[hostname]

Je kan in PHP 5.3 helemaal geen types afdwingen. Sinds PHP5 kan je alleen een array, class of interface afdwingen. Er is op de mailinglijst van de developers wel een discussie geweest (met patches) over dit, en het algemene idee was dat het een goed idee is en geimplementeerd moet worden. De exacte implementatie is echter een behoorlijk discussiepunt. Nu zijn er meerdere RFC's en ik heb er al een paar maanden niks meer over gehoord...

[Verwijderd]

Smalltalk[..] en is tevens weak-typed.

Ga je mond spoelen.

[MadEgg]

Java en C# zijn veel object georienteerder dan C++. C++ biedt er ondersteuning voor maar dringt het niet op; in Java kan je gene programma schrijven zonder een class te maken.

Dat wat voor C++ geldt geldt ook voor PHP; het kan, maar hoeft niet. En zowel in C++ als in PHP heb je prima methoden om erachter te komen met wat voor object je werkt, type-strong of niet. Bij PHP heb je alleen meer mogelijkheden om daar op run-time pas achter te komen terwijl in C++ het grotendeels bij compile-time al duidelijk moet zijn.

[sys64738]

PHP kun je ook object georienteerd mee werken, alleen wordt dat bijna nooit gedaan. Heb ooit wel een project gedaan waar we wel netjes OO werkten met PHP.

In C++ ben je trouwens ook niet verplicht om OO te werken dus wat dat betreft is de mapping wel goed.

Wat ik wel knap vind is dat ze van een weak-typed taal een strong typed taal kunnen maken. Volgens mij is het heel moeilijk om overal precies te kunnen bepalen met wat voor type object/primitive je te maken hebt.

[Mister_X]

huh, wat?? nooit gedaan? Ik doe niet anders joh!!! Als je het niet doet ben je in mijn ogen slecht bezig, niet lullig bedoelt, maar dan heb je gewoon nog veel te leren !! ... OO Is de key tot effecienty en performance!

[pasz]

Denk dat jij ook nog veel te leren hebt. OO is een andere manier van denken, maar zeker geen sleutel tot performance en/of efficiency.

[Verwijderd]

Precies. Als je objecten verkeerd gebruikt (run-time binding of een complexe class voor ieder wissewasje aanmaken en weer weggooien) dan heb je meer nadeel dan voordeel.

Bovendien zijn OO ontwikkelen en een OO programmeertaal twee hele verschillende dingen. Je kunt OO programma's maken met C (kijk naar de Linux kernel) en je kunt procedureel programmeren met C++.

[elmuerte]

Je kunt OO programma's maken met C (kijk naar de Linux kernel)

Nee, en nee.
Je kan wel het idee van OOP benaderen met C (door enge structs met function pointers), maar dat is niet echt OOP.

[Verwijderd]

Natuurlijk is dat OOP!
OOP=code en data bij elkaar. Als je onder de motorkap naar een C++ class kijkt dan zul je de 'enge structs' en functionpointers ook tegenkomen (google eens op vtable). C++ verpakt dat in een mooi jasje maar het principe is exact hetzelfde!

[Mister_X]

Ppppfff
Timmeren is ook een manier van denken...

Alles is een manier van denken!! Elke handeling verreist .. je snapt me wel niet? Ik heb geen zin om miereneukerige discussies te houden over OO en manier van denken. OO is een manier van programmeren, het niet toepassen van OO is inefficient, en kan leiden tot een slechte performance van je toegepaste (van library is dan al geen sprake) code. Als je dat niet inziet ga je zelf maar terug de boeken in, waarom denk je dat het uberhaupt bestaat ehhhhh efficienter met je library omgaan?

Het creatief zijn in oplossingen is natuurlijk dus ook een sleutel tot succes, maar dat geld met alles zo.

@ hierbeneden, als je objecten verkeerd gebruikt heb je ook nog wat te leren dus ...

Ik verander me statement voor de iets mindere creatievere mensen:

"Het niet toepassen van OO of het half toepassen van OO, "KAN" leiden tot slechte peformance en efficienty" (maarja met zo'n statement kun je natuurlijk alle kanten uit..)

Maargoed wie ben ik met 10 jaar werkervaring, ik ben vast ook de enige die zegt dat Doctrine ruk is ...

ik ga weer verder met me "efficiente" ORM, waar je toch echt OO voor nodig heb (doen en denken)


@Door EvilB2k, woensdag 3 februari 2010 13:50

right, ik heb geen flauwbenul waar je reactie op slaat? Als je een porsche de sloot in rijd is hij ook niet meer de snelste? lol

Je kunt toch zodanig programmeren dat je voor 1 oplossing ipv 20 maar 5 regels nodig hebt? dat kan o.a. door denken (dohhhh) en goed toepassen van een library en/of code?

[Reactie gewijzigd door Mister_X op 23 juli 2024 07:09]

[Verwijderd]

Ik denk dat je zelf de boeken in moet. Een library is niet per definitie OO. En OO maakt een programma niet efficient. In heel veel embedded toepassingen waar performance en afmetingen van de binary zeer belangrijk zijn wordt (vrijwel) nooit een OO taal toegepast. Voor sommige toepassingen zoals automotive zijn functiepointers zelfs verboden (MISRA voorschriften).

Je hoeft er ook geen ellenlange discussie over te voeren: OO is een handige manier om met complexe problemen om te gaan. OOP is een manier van programmeren voor het implementeren van complexe problemen. Een OO programmeertaal maakt het makkelijk om OO te programmeren. Dat zijn drie losstaande dingen die je naar hartelust kunt combineren.

Tot slot: OO is beslist niet zaligmakend en zeker geen strooizout waarmee alle complexe programmeerproblemen als sneeuw voor de zon verdwijnen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 07:09]

[Laurens-R]

Maargoed wie ben ik met 10 jaar werkervaring,

Ook ik programmeer nu al behoorlijk wat jaren, maar op de dag dat ik een dergelijke opmerking maak, vind ik dat mijn baas mij mag ontslaan (ook al heb ik 40 jaar ervaring!). Elke dag leer ik weer wat nieuws en andere mensen hebben nou eenmaal langer en beter nagedacht (of relevantere ervaring) over zaken waar ik wat minder tijd voor had.

huh, wat?? nooit gedaan? Ik doe niet anders joh!!! Als je het niet doet ben je in mijn ogen slecht bezig,

Ppppfff

dat kan o.a. door denken (dohhhh)

heb je ook nog wat te leren dus ...

Ik verander me statement voor de iets mindere creatievere mensen:

Aan deze reacties is je 10 jaar werkervaring in ieder geval niet af te lezen.

Op deze site zitten duizenden tweakers die (net als jij) programmeren om de kost te verdienen (alhoewel ik gezien de manier waarop je reageerd vermoed dat je werkervaring wat aangedikt is). Van elkaar leren levert in ieder geval meer op, dan iedereen indirect als incompetent te bestempelen en te kleineren in zijn of haar mening.

edit: kleine wijzigingen.

[Reactie gewijzigd door Laurens-R op 23 juli 2024 07:09]

[Mister_X]

Dat zijn jou woorden, ik bestempel niemand als incompetent, ik word er alleen zo moe van dat je hier op de frontpage niets 'vanzelfsprekend is' alles moet benadrukt worden want anders word je verkeerd begrepen, elke detail van je argument (hoe vanzelf sprekend het ook is) moet je eraan toevoegen want anders 'klopt het niet'.

Zoek voor de gein eens op mijn nick op het forum, iedereen begint ergens.

@ncoesel

nee dat snap ik, maar moet je dat nou benadrukken, ik weet heus wel wat een library is, moet ik dan ook nog zeggen wat er in een library hoort? (alles in feite wat je wilt bewaren aan code ...)

[flowerp]

Een zekere zin is het als nadeel te zien van PHP dat men nu -nog- steeds die OO wel-of-niet discussie voert. In veel andere moderne talen (Java, C#, C++, Objective-C, ...) is dit tegenwoordig een complete non-discussie, iets wat mensen zich misschien nog herinneren van een decennium of meer geleden.

Daar tussendoor is al de discussie geweest van wel of niet ORM en tegenwoordig ligt de focus zo'n beetje op wel of niet concurrent programmeren.

Om NU nog te discusseren over wel of niet OO... het voelt gewoon een beetje raar aan eigenlijk...

[Laurens-R]

OO is een denkwijze.

Als je denkt dat zoiets de key tot performance is, moet je even nadenken over het feit dat onderwater een computer helemaal niets afweet van classes. Niets meer dan een reeks aan data en CPU instructies.

[sander_vk]

We kunnen natuurlijk allemaal in assembler gaan coden. Dan krijg je echt snelle en efficiënte programma's van.

Het onderhouden en bugs vrij houden van de code is dan alleen een ander verhaal.

[servies]

Met elke taal kun je object georienteerd werken. Het is alleen dat je met de specifieke talen wordt gedwongen. In C kun je heel goed object georienteerd programmeren, je moet alleen jezelf dan in bedwang houden in tegenstelling tot een OO taal die jou wel dwingt...

[sys64738]

Ja ok, mijn formulering was wat scheef. PHP is een object georienteerde taal omdat ie je actief helpt bij het schrijven van OO programmatuur.

Persoonlijk schrijf ik toch liever OO programma's in een OO taal dan dat ik alle plumbing zelf moet doen.

[SH4D3H]

Wat ik niet begrijp is dat php niet object georiënteerd is en c++ wel... was het dan niet makkelijker om het in ansi c te doen? kun je het nog verder optimaliseren

Vanaf versie 5 is de ondersteuning voor OOP sterk toegenomen.
Sowieso maakt het voor een compiler weinig uit, het is slechts een voordeel voor de programmeur.

[elmuerte]

C++ is niet beter omdat C++ beter is. Het grootste voordeel halen ze uit het feit dat hun brakke gegenereerde C++ code door de compiler geoptimaliseerd wordt.

En PHP is net zo object georienteerd als C++ is. Natuurlijk hadden ze het ook kunnen vertalen naar C. Maar dat zou waarschinlijk wat meer moeite kosten omdat ze alle objecten zouden moeten unrollen.

[Ramoonus]

waarmee heb je getest?

[NL-RaVeR]

Wow, dat is erg mooi. Maar hoe werkt dit dan aan de webkant? Lijkt me niet dat je zo C++ code kan draaien op je apache server of zie ik dit verkeerd?

[arjankoole]

Wow, dat is erg mooi. Maar hoe werkt dit dan aan de webkant? Lijkt me niet dat je zo C++ code kan draaien op je apache server of zie ik dit verkeerd?

het wordt volgens mij niet veel gebruikt, maar je had altijd een mod_c++ waarmee je exact dat kon doen.

[Rembert]

Huh? mod_c++??? Bestaat dat? Een mod die c++ code interpreteert op Apache?

Als je C++ code hebt gecompileerd, dan kun je het gewoon als CGI uitvoeren. Dat kan in de cgi-directory maar als je de server zo configureert dat alle bestanden eindigend op .cgi ook uitvoerbaar zijn, dan werkt het out-of-the-box. Geen modje bij nodig (die naar mijn weten ook niet bestaat en volkomen overbodig is)

Let wel: gecompileerde C++ code is niet portable: het draait op het systeem waar je het hebt gecompileerd alsook direkt vergelijkbare systemen. Heb je het op Ubuntu gecompileerd dan kun je het niet meenemen naar bv. een windows Apache oplossing.

[analog_]

However zou het in de linux wereld geen ramp zijn om bv. de source code van een open source pakketje te verdelen via rpm/deb. Closed source wereld zal er meer last van hebben.

[Verwijderd]

mod_cpp
http://sourceforge.net/projects/modcpp/

[SA007]

CGI ondersteuning (draaien van binairies welke http headers snappen) zit al heel wat langer in apache dan php support.
En dat is dit in principe, een gecompileerde versie van een script wordt een binairy en zal dus wel via het CGI systeem van apache werken.

[Huppie]

*correctie*

Het kan zowel via FastCGI draaien als met behulp van een interne webserver.

[NL-RaVeR]

Oke, wist ik niet. Weer wat geleerd vandaag. Erg mooie ontwikkeling als je zo de load van je servers kan verminderen en de performance van je scripts kan verhogen .

[Yakotb]

Ze werken aan native Apache-ondersteuning.

[MadEgg]

Leuk idee, maar in de praktijk weinig bruikbaar denk ik. Alleen voor grote websites die hun eigen servers in beheer hebben; ik gok dat er weinig webhosts zijn die klanten gaan toestaan om binaries uit te voeren via de webserver.

Verder vraag ik me af in hoeverre dergelijke resultaten niet zijn te behalen door wat efficiëntere code te gebruiken in PHP. Maar goed, bij Facebook praten we natuurlijk wel over een gigantische traffic.

[sys64738]

Ja maar voor kleine sites is het natuurlijk sowieso niet zo'n issue. Die staan toch niet echt te kraken onder de load van al die gebruikers.

Dus zodra dit echt speelt, heb je waarschijnlijk ook al een eigen server in beheer.

[pasz]

Dat ligt eraan. Als je een ASP.NET applicatie maakt, upload je ook 'binary' DLLs.
Een hosting partij kan niet makkelijk bekijken wat er in deze DLLs zit.

Het is dus meer een kwestie van rechten geven dan van het gebruik van binaries.

[hostname]

Het eerste probleem is simpel op te lossen door zelf de code aan te leveren en je hosting partij die te laten compileren met HipHop...

Verder is er natuurlijk best winst te halen door efficientere code te schrijven, maar er is ook winst te behalen in PHP. Nu compileer je het namelijk elke keer als er een request is, en gooi je de gecompileerde data weer weg. Je doet dus heel veel elke keer opnieuw. Als je dit 1x gaat doen, is dat al een hele verbetering en dat helpt ook weer mee. En bij sites als Facebook betekent 1% sneller ook dat ze 1% minder servers nodig hebben, wat weer duizenden euros kan besparen.

[Verwijderd]

Beetje raar dat dat nog niet eerder toegepast is, ik kan me voorstellen dat er bedrijven zijn die hier veel meer belang bij hebben. Daarintegen, die sociale sites zitten wel altijd vol met code ja... Nette verbetering dacht ik zo, en het spaart het milieu ook weer ^^

[Paitor]

Helemaal niet vreemd dat het niet vaker toegepast is. Om zo'n enorm project op te zetten is veel kostbaarder dan het voor tweakers is (bijvoorbeeld) om een extra server in je server rack te gooien. Dus dan houdt het heel snel op voor een bedrijf om te investeren in zo'n 'nutteloos' project

[Verwijderd]

Volgens mij zijn echt al tig projecten die de een of andere scripttaal omzetten naar C/C++ en dat vervolgens compilen naar een ELF binary. In ieder geval voor perl en python.
Probleem is dat die dingen vaak niet volledig zijn en problemen hebben met 3rd party libraries. Zal met facebook niet anders zijn, zal een applicatietje zijn die specifiek voor facebook werkt.

[Siebsel]

Appcelerator (http://www.appcelerator.com/) doet hetzelfde volgens mij, of ik snap 't niet Goed, dat is voor desktop/iphone apps en niet echt specifiek voor server apps, maar het idee is volgens mij wel ongeveer hetzelfde.

[kaesve]

volgens mij begrijp jij het inderdaad verkeerd. Ik ken appcelerator niet zo goed, maar zo te zien is dat vooral bedoelt voor webdeveloppers die apps op andere platvormen willen maken dan het web, maar geen andere taal willen leren.
het doel van dit project is om server-sided code flink te optimaliseren, niet zo zeer om van een stukje php-software een native app te maken.
(please, correct me if i'm wrong)

[Verwijderd]

Dat soort accelerators cached volgens mij de bytegecompilede (of wat voor tussenstap PHP ook gebruikt) code, waardoor de parsestap overgeslagen kan worden en je dus wat snelheidswinst hebt. Volledig ander principe dan het elders vertalen van taal A naar taal B (of C) en dat compilen naar een CGI binary.

[swtimmer]

Erg netjes van Facebook. Vooral dat ze het open source aanbieden. Toch wel fijn dat de grote bedrijven regelmatig wat terug doen voor de "samenleving".

[elmuerte]

Ze doen het ook voor zichzelf. Door het open source te maken hopen ze meer gebruikers en ontwikkelaars aan te trekken die mee helpen aan het verbeteren van het product. Facebook haalt geen profeit uit het voor zich zelf houden van deze software omdat ze niet in de software verkoop business zitten.

[bomberboy]

Ik vermoed dat ze het eerder voor een groot deel doen omdat ze moeten. De code is momenteel nog niet beschikbaar. Maar het lijkt me heel waarschijnlijk dat ze een heleboel bestaande open source bibliotheken en code gebruikt hebben bij deze ontwikkeling.

Afhankelijk van de gebruikte licentie moet je dan ook de aanpassingen en afgeleide werken opnieuw beschikbaar maken. Als ze het nu vlotjses presenteren als " wij stellen dit ook voor jullie beschikbaar" komt dat heel wat beter over dan wanneer ze volgend jaar "betrapt" worden.

[Nick_S]

Ik ken maar weinig licenties die stellen dat je de code altijd openbaar moet maken. Zelfs de GPL, welke toch wel als meest strict/open wordt beschouwd, stelt dat je je code alleen beschikbaar moet maken als je de binaries gaat distribueren. Als jij zelf de tool gebruikt voor eigen gebruik distribueer je niks, en hoef je dus ook niets open te maken.

Van het volgende ben ik iets minder zeker, maar volgens mij zouden ze als de software gedeeltelijk onder gpl valt, zelfs een service mogen aanbieden om voor andere bedrijven hun php source gecompileerd weer terug te geven, aangezien je hier niet de tool distribueert maar alleen het resultaat.

[elmuerte]

Ja, het laatste is ook correct voor de GPL. Want, geen enkele echte Free Software/Open Source Licentie zal beperking opleggen van het gebruik van de software.

Maar, als voor het gebruik van de HipHop output weer GPL libraries nodig zijn wordt het lastiger.

[Nick_S]

Dan moeten ze dus de output van de tool als code geven. Niet de tool zelf. maar de gegenereerde C++ code.

[swtimmer]

Nou ja, je zou kunnen denken dat ze 50% minder server kracht nodig hebben dan concurrenten. Als je bijvoorbeeld altijd de hyves pagina snelheid zag en dat vergeleek met die van facebook (kom nooit op hyves, dus weet niet hoe dat tegenwoordig is) was facebook een stuk vlotter en daarom dus ook een stuk aangenamer werken. Nu zou hyves (of een ander social platform) dezelfde trucs kunnen uithalen als FB om sneller te kunnen werken!

[Rob Coops]

Het probleem was niet zo zeer de traagheid van de scripts als de load op de servers, als je plotseling van uit een kleine hosting server groeit naar een setup met vele servers en heel erg veel database requests dan kom je al snel op een probleem waar je database(s) niet zo maar mee overweg kunnen. In het filmpje meld men dat er 400 miljard pageviews voobij komen op de Facebook servers. Natuurlijk zal Hyves niet zo groot zijn maar met een onstuimige groei zo als bij hyves zul je snel moeten opschalen en dat is niet makkelijk. Al is het alleen al dat je aan database proxies moet gaan denken en dingen als caching van data en tables of query results.

Hyves is in middels een stuk beter en ik weet zeker dat dat meer gebaseerd is op hardware scalling. Het is nu eenmaal moeilijk om even snel zeg 1000 webservers op te zetten en gewoon even aan je database the hangen. Met deze oplossing zullen ze niet zo snel een veel snellere oplossing hebben maar eerder minder servers nodig hebben en dat is het belangrijkste minder kosten met de zelfde hoeveelheid pageviews en gebruikers. De extra executie snelheid wordt tenietgedaan door de latency op het netwerk, zeker als je bedenkt dat een pagina waarschijnlijk niet meer dan een paar milliseconde draait, als je van de 8 naar de 4 milliseconde gaat dan heb is er niemand die het zal merken omdat het al snel 20 miliseconde duurt voor de packets bij jouw zijn aan gekomen.

Met andere worden het is groen (minder servers met de zelfde performance is minder vervuiling) en minimaal net zo belangrijk het is lekker goedkoop wat betreft hardware, want groen is leuk maar meer dollars (ook groen btw) in je zak is veel belangrijker natuurlijk.

[willyb]

Eigenlijk zou het wel eens mooi zijn om een en dezelfde taken voor een website eens uit te schrijven in verschillende talen, om vervolgens een te kijken welke het beste performance geeft.

Ik denk aan een testje tussen PHP, ASP.Net, JSP/JAVA, Ruby, Coldfusion, etc.

[Verwijderd]

vergeet Python en Perl niet. Worden ook best veel gebruikt. (denk aan google)

[MBV]

http://shootout.alioth.debian.org/ vergelijkt opstarttijden en diverse algoritmen

[IntToStr]

Dit lijkt een beetje op een nieuwe feature in de JVM voor Java. Ze hebben daarin de ondersteuning voor scripttalen flink verbeterd, waardoor bijv. ook PHP kan worden uitgevoerd door de JVM.

Erg technisch verhaal over hoe ze daar de verschillen met weak/strong typing hebben opgelost, maar het was erg veelbelovend. Testen met Ruby toonden al aan dat er veel performancewinst is te halen op deze manier.

[mcDavid]

Ik zat me juist van de week af te vragen, of er niet net zoals tegenwoordig de compilende javascript-engines van moderne browsers doen, er ook zoiets in PHP zou zitten. Ik denk dat dit bericht die vraag wel behoorlijk beantwoord!