Stelling: HHVM is de toekomst.

Introductie
PHP is traag. Door de werking van PHP duurt het laden van PHP lang, te lang. Vooral bij meerdere requests schaalt het slecht. Dat moet beter en dat vinden de makers van HHVM (Facebook) ook. Ze hebben een stukje software ontwikkeld dat het laden veel sneller moet maken, vooral bij meerdere bezoekers tegelijk. Nieuwsgierig? Check de website. Op zoek naar cijfers? Klik hier. Het heeft wel een nadeel: niet alle PHP functies worden goed ondersteund. Het is (nog) niet altijd inzetbaar maar het HHVM team is druk bezig met het doorontwikkelen van de software. Overigens is de voorganger HipHop for PHP (HPHPc).

De stelling:

"HHVM is de toekomst,,

Hoe denken jullie hier over? Blijft PHP bestaan, gaan we over naar HHVM, gaat PHP compleet veranderen... Shout! Geef je mening of heb je vragen, het mag. Ik ben benieuwd wat jullie hier van vinden.

Ik denk van niet om eerlijk te zijn. Ik denk dat normale XCache ook zijn werk doet, en zou het niet raar vinden dat het ook binnenkort standaard in PHP komt.

Voor de rest achter schalen denk ik dat Apache 2.4 ook verbeterd is. Uiteraard kan altijd beter. Geen idee hoe het in vergelijking is met HHVM!

Nieuwe technologie is altijd goed, er word ook geexperimenteerd met mod_lsapi (LiteSpeed)
"Apache mod_lsapi is a module based on LiteSpeed Technologies API for PHP, Ruby and Python. It offers excellent PHP performance, low memory footprint coupled with great security and support for opcode caching."

Whoops, zit er al ingebouwd @opcache

Eerlijk gezegd denk ik niet dat HHVM het wordt.
Op dit moment zie ik nog veel in PHP-FPM, omdat HHVM toch wel issues heeft met compatibiliteit.

PHP zelf heeft ook een stap gezet richting gecompileerde code met PHP NG.
Mijn vermoeden is dat de ontwikkeling binnen PHP NG de ontwikkeling van HHVM gaat inhalen.
Maar het is zeker wel goed dat er een alternatief is ontstaan zodat ook de PHP ontwikkelaars weer even op scherp staan.

Zo ver ik weet heeft HHVM ook zijn problemen en kan nog niet alles er goed mee overweg. Zoals xentos zegt is er veel te behalen met een goede opcacher die dacht ik vanaf vanaf PHP 6 standaard zit ingebouwd.
Daarnaast is inderdaad een dyamische pagina steeds opnieuw opbouwen die er toch 99,9% van de keren hetzelfde uitziet inderdaad traag. Maar daarvoor heb je gelukkig tegenwoordig Nginx, Varnish en andere caching oplossingen. Ook key–value stores zoals Redis zijn hiervoor in opkomst zodat je complete elementen van de een website direct uit het werkgeheugen van de server kunnen worden geladen.

Daarom denk ik niet dat HHVM de toekomst is maar dat er veel meer naast PHP is wat mogelijke toekomst biedt voor snellere websites.

Uhm... ik snap die hhvm stap van facebook eigenlijk niet. Met een 'trillion pagevies per month' zou ik me een asic maken die niks anders deed dan facebook crap uitspugen. En niet kloten met tooltjes die voor het 'grote publiek' ook moeten werken.

Oorspronkelijk geplaatst door systemdeveloper

Uhm... ik snap die hhvm stap van facebook eigenlijk niet. Met een 'trillion pagevies per month' zou ik me een asic maken die niks anders deed dan facebook crap uitspugen. En niet kloten met tooltjes die voor het 'grote publiek' ook moeten werken.

Ik zie niet zo veel overlap tussen dingen waar ASICs erg goed in zijn (bit manipulatie zoals hashing, FFT en andere signal processing, packets switchen ) en dynamische webcontent maken zoals facebook uitspuugt.

Daarnaast zijn ontwikkeltijden langer, zijn ze minder flexibel, en is de pool kandidaat-developers die erop kan coden een stuk kleiner dan voor een taal/tool die ook bij het 'grote' publiek bekend is.

Oorspronkelijk geplaatst door visser

Ik zie niet zo veel overlap tussen dingen waar ASICs erg goed in zijn (bit manipulatie zoals hashing, FFT en andere signal processing, packets switchen ) en dynamische webcontent maken zoals facebook uitspuugt.

Daarnaast zijn ontwikkeltijden langer, zijn ze minder flexibel, en is de pool kandidaat-developers die erop kan coden een stuk kleiner dan voor een taal/tool die ook bij het 'grote' publiek bekend is.

Een asic is gewoon een app. specifiek circuit en is niet gelimiteerd tot bitmanipulatie e.d.
En dynamisch... mja, het is maar wat je daaronder verstaat. 95% van wat facebook uitspuugt komt uit een cache en is in principe weinig dynamisch aan. Dat kan in principe best hardwarematig afgehandeld worden.
De pool mogelijke ontwikkelaars doet niet echt ter zake. Ook apache, php e.d. wordt als eentjes en nulletjes uitgevoerd en kan gewoon op een chip gemikt worden. Als je bv. naar php kijkt dan loop je al snel tegen bv. 500 functies aan terwijl een programmeur er vaak maar 50-100 gebruikt (als het al zoveel is). Daarbij zijn er veel functies die als assembler plugin xxxx keer sneller zijn dan een php versie.

Als je dan ook nog dingen zoals operating system, bytecode, in time compiling e.d. gewoon kunt overslaan en dus je hardware veel effectiever kunt uitbuiten, kom je toch een stuk verder dan alleen een php vervanger knutselen.

My 2 cents (ex. btw)

Oorspronkelijk geplaatst door systemdeveloper

Een asic is gewoon een app. specifiek circuit en is niet gelimiteerd tot bitmanipulatie e.d.
En dynamisch... mja, het is maar wat je daaronder verstaat. 95% van wat facebook uitspuugt komt uit een cache en is in principe weinig dynamisch aan. Dat kan in principe best hardwarematig afgehandeld worden.
De pool mogelijke ontwikkelaars doet niet echt ter zake. Ook apache, php e.d. wordt als eentjes en nulletjes uitgevoerd en kan gewoon op een chip gemikt worden. Als je bv. naar php kijkt dan loop je al snel tegen bv. 500 functies aan terwijl een programmeur er vaak maar 50-100 gebruikt (als het al zoveel is). Daarbij zijn er veel functies die als assembler plugin xxxx keer sneller zijn dan een php versie.

Als je dan ook nog dingen zoals operating system, bytecode, in time compiling e.d. gewoon kunt overslaan en dus je hardware veel effectiever kunt uitbuiten, kom je toch een stuk verder dan alleen een php vervanger knutselen.

My 2 cents (ex. btw)

Een ASIC werkt met dezelfde chip technologie en circuits als een general purpose CPU. Sterker, in fab technologie lopen ASICs meestal wat achter op de 'latest en greatest' general purpose CPUs.
'in hardware is sneller' is hetzelfde soort statement als een manager die roept "dan moet je meer computers gebruiken om het sneller te maken'. _Soms_ werkt het zo simpel.

Wat tegenwoordig relatief traag is, is access tijd van (groot)ram. General purpose CPUs besteden een fors deel van hun (semi-oneindige) transistor- en powerbudget aan het verstoppen van die memory latency via Out of Order execution (iets anders doen terwijl je op cache/memory access wacht) en slimme branch prediction - pre-fetchen en uitvoeren van de verwachte uitkomst van een branch die nog genomen moet worden.
Kleine lokale geheugens , of geheugens met een speciale access (zoals tcam) kunnen wel veel sneller zijn. Maar zijn klein of gebruiken veel stroom.
Ook is er een aardig verschil tussen 'streaming' access en random access.

ASICs, die in fabtechnologie (en dus kloksnelheid) al achterlopen op de high-end general purpose CPUs winnen dan alleen op dingen die feitelijk bitmanipulatie op een klein blokje data zijn (crypto , packet handling) , of andere vergelijkbare operaties op goed voorspelbare datastromen (GPUs met een stel vector en matrix operaties doen - streaming access + wat een set van brede registers ).

Dat is waarom je wel een bitcoin miner in een asic hebt, of een GPU , maar geen GCC asic.

Ga je de asic generieker maken, dan wordt het gewoon een CPU die alleen een aantal technologie generaties achterloopt.

Ja, je kunt wat deel functies (zoals het uitsturen van statische content over TCP) in een paar asics verpakken. Sterker, dat soort appliances bestaan (voor video streaming). Misschien dat facebook die ook gebruikt, dat weet ik niet.
Maar je krijgt niet snel een 'php asic' die tig keer sneller is dan een gewone cpu.

Een kleine pool ontwikkelaars (cq langere inwerktijd) is een nadeel als je snel wilt groeien en snel wilt nieuwe applicaties releasen, iets wat facebook duidelijk wil.
Werken met een 'special purpose' architectuur is gewoon fors anders en het kost tijd voordat developers alles eruit halen wat er in theorie mee kan. (Zie bv de Cell processor van de PS3 - een min of meer normale power4 general purpose cpu met een aantal co-processors ).

Het is een beetje jammer om met een asic meestal naar een miner te refereren aangezien ik het daar niet over heb. Een gcc asic zou ook weinig zin hebben omdat gcc gebruikt wordt om de uiteindelijke code te knutselen en dat an sich niet eens snel hoeft te zijn. Maar een gestripte custom 'php' binary op een chip mikken die direct zijn ram kan aanspreken is echt wel een stukje sneller dan een binary van disk lezen, plugins erbij laden, source files laden, 'compileren' naar bytecode en via een interpreter naar een chip jagen.

Een kleinere pool ontwikkelaars blijf ik geen reden vinden. FB heeft toch al snel een 1000 ontwikkelaars en denk maar niet dat die overal eruit halen wat erin zit
COBOL ontwikkelaars zijn ook een kleine pool. Zet er genoeg geld tegenover en je krijgt ze toch wel.

Maar los van dat, er zijn genoeg onderdelen van een php applicatie die gewoon al stukken sneller kunnen door ze bv in c te maken ipv. in php. Stel fb heeft ergens een fibonacci functie (ik zou bij god niet weten waarom, maar stel), dan kun je dat in php knutselen of in c, waarbij de laatste wel een stukje sneller is. Zelfs met general purpose cpu's verplaats je zo toch langzaam delen van je app een stuk korter bij je hardware dan dat je dit ergens in een myfiboclass.php gooit. Je kunt het dan nog in je os kernel gooien en mocht je die functie echt heel leuk vinden kun je hem verplaatsen naar een SoC.

Er zijn trouwens wel wat IEEE docs over dynamisch configureerbare SoC's op basis van bitstreams die ergens hetzelfde doen. (al zal dat niet met zoiets dufs als fibonacci zijn, maar ik had even geen ander voorbeeld).

Anyway, we zullen zien wat het over 10 jaar geeft

Oorspronkelijk geplaatst door systemdeveloper

Het is een beetje jammer om met een asic meestal naar een miner te refereren aangezien ik het daar niet over heb. Een gcc asic zou ook weinig zin hebben omdat gcc gebruikt wordt om de uiteindelijke code te knutselen en dat an sich niet eens snel hoeft te zijn. Maar een gestripte custom 'php' binary op een chip mikken die direct zijn ram kan aanspreken is echt wel een stukje sneller dan een binary van disk lezen, plugins erbij laden, source files laden, 'compileren' naar bytecode en via een interpreter naar een chip jagen.

Welk soort dingen wel of niet sneller worden als je ze in een asic stopt heeft gewoon te maken met vrij fundamentele chip architectuur issues.
Een ASIC is geen toverdoos waar je een wens en een cheque in gooit en "het" komt er sneller uit.
De woordenboek definitie 'applicatie specifiek ic' is geen belofte dat je elke toepassing goed in een asic krijgt.

"Markt" of "niet zinvol" zijn echt niet de enige redenen waarom een bitcoin miner, een GPU, een DSP, of een switch wel 'goed' in asic stijl hardware gaan en een 'GCC ASIC' zou eindigen als een CPU.

In het bovenstaande deel zou de voornaamste versnelling te halen zijn om de bytecode te cachen en die te laten uitvoeren, en dat staat nog helemaal los van asic vs general purpose cpu , maar ligt alleen aan het software landschap.
Als het eenmaal op uitvoeren van bytecode aankomt kun je nog best wedden op een stevige (OoO) CPU boven een in-order en lager geklokte asic .

Een kleinere pool ontwikkelaars blijf ik geen reden vinden. FB heeft toch al snel een 1000 ontwikkelaars en denk maar niet dat die overal eruit halen wat erin zit
COBOL ontwikkelaars zijn ook een kleine pool. Zet er genoeg geld tegenover en je krijgt ze toch wel.

Time to Market is duidelijk belangrijk voor FB. Vissen in een grote vijver (en het talent daar uit filteren) maakt dat heel wat makkelijker dan in een niche gaan zitten, mensen binnenkopen, trainen en dan ontdekken dat ze 'het' niet zo erg hebben.
Vergeleken daarmee is het optimaliseren op #transistors in je DC helemaal het verkeerde criterium.

Maar los van dat, er zijn genoeg onderdelen van een php applicatie die gewoon al stukken sneller kunnen door ze bv in c te maken ipv. in php. Stel fb heeft ergens een fibonacci functie (ik zou bij god niet weten waarom, maar stel), dan kun je dat in php knutselen of in c, waarbij de laatste wel een stukje sneller is. Zelfs met general purpose cpu's verplaats je zo toch langzaam delen van je app een stuk korter bij je hardware dan dat je dit ergens in een myfiboclass.php gooit. Je kunt het dan nog in je os kernel gooien en mocht je die functie echt heel leuk vinden kun je hem verplaatsen naar een SoC.

Ik zou ook zeker adviseren om sqrt() niet uit te coden in native PHP, maar deze functie door de bytecode interpreter de bijbehorende FPU functie te laten aanroepen.
Enzo. Maar op dit niveau is het puur software tuning.

De kracht/winst van een ASIC bouwen gaat pas daarna spelen, als de architectuur en (assembler)primitieven van een CPU of systeem niet goed passen op het probleem.

En als het probleem vaak genoeg voorkomt, migreren die functies soms weer terug naar de (general purpose) CPU.
Hardware Floating Point berekeningen begonnen op een dedicated chip, de FPU. (8087/80287 bij Intel, 68881 bij Moto).

En werden later een vaste unit van de CPU. Wat vector (simd) functies begonnen in de eerste 'accelerated' graphics kaarten, kwamen bij de CPU (Altivec,3DNow/MMX,SSE{2,3,4}), en leven in nog uitgebreider vorm weer in graphics chips.
Crypto functies (vaak simpel en spotgoedkoop in hardware) zijn bij de CPU instructieset gekomen. (AES-NI)

Er zijn trouwens wel wat IEEE docs over dynamisch configureerbare SoC's op basis van bitstreams die ergens hetzelfde doen. (al zal dat niet met zoiets dufs als fibonacci zijn, maar ik had even geen ander voorbeeld).

Anyway, we zullen zien wat het over 10 jaar geeft

Het is zoals Pim zegt goed dat iedereen weer even op scherp staat en dat er ook tijd gestoken wordt naar php-ng. Je merkt wel dat hhvm wat meer tractie krijgt, maar je kunt hetzelfde zeggen voor php-fpm eigenlijk. Je moet wel echt een use case hebben voor hhvm om er gebruik van te gaan maken. Als php-ng goed werkt verwacht ik eerder dat daar de toekomst ligt.

Persoonlijk denk ik dat HHVM wel de toekomst is maar samen met PHP. Zoals iedereen aangeeft heeft HHVM compatibiliteit issues en die worden weggewerkt. Toch zal het achterlopen wat functionaliteit betreft op PHP maar het is heel goed inzetbaar voor de zaken waar het wel goed mee werkt. Voor de shared hosting diensten is HHVM niet geschikt maar voor specifieke projecten wel. Denk aan Magento maar ook diverse frameworks. Op korte termijn zie ik het niet als vervanger van PHP maar ik denk dat het zeker een concurrent kan worden/is voor applicatie specifieke servers.

Oorspronkelijk geplaatst door xentos

Ik denk van niet om eerlijk te zijn. Ik denk dat normale XCache ook zijn werk doet, en zou het niet raar vinden dat het ook binnenkort standaard in PHP komt.

Voor de rest achter schalen denk ik dat Apache 2.4 ook verbeterd is. Uiteraard kan altijd beter. Geen idee hoe het in vergelijking is met HHVM!

Nieuwe technologie is altijd goed, er word ook geexperimenteerd met mod_lsapi (LiteSpeed)
"Apache mod_lsapi is a module based on LiteSpeed Technologies API for PHP, Ruby and Python. It offers excellent PHP performance, low memory footprint coupled with great security and support for opcode caching."

Whoops, zit er al ingebouwd @opcache

Ik zou zeggen zoek eens naar de statistieken, zoals bijv http://www.dev-metal.com/phps-hiphop...x-15-20-times/. De verschillen tussen deze technologieën zijn groot en als je naar de statistieken kijkt die ik in mijn openingspost heb gelinked dan zie je dat het bij veel requests veel beter performed dan standaard PHP. Wat het verschil is met een caching technologie weet ik niet maar uitgaande van dev-metal zou ik zeggen dat het een groot verschil blijft.

Oorspronkelijk geplaatst door PimEffting

Eerlijk gezegd denk ik niet dat HHVM het wordt.
Op dit moment zie ik nog veel in PHP-FPM, omdat HHVM toch wel issues heeft met compatibiliteit.

PHP zelf heeft ook een stap gezet richting gecompileerde code met PHP NG.
Mijn vermoeden is dat de ontwikkeling binnen PHP NG de ontwikkeling van HHVM gaat inhalen.
Maar het is zeker wel goed dat er een alternatief is ontstaan zodat ook de PHP ontwikkelaars weer even op scherp staan.

Als ik naar de benchmarks kijk dan heeft het inderdaad tov PHP een grote performance winst (tot 30%). Het zal nog even duren maar als ik het goed begrijp is dit nog maar het begin.

Zonder PHP is er geen HHVM dus de stelling is enigszins vreemd maar men zal de engine bedoelen die de PHP code uitvoert.
Voor JIT zijn er al jaren meerdere oplossingen voor PHP (bijv Quercus), daar is HHVM niet de enige in. Ik zie niet waarom dat zou veranderen in de toekomst, elke oplossing heeft zo zijn voor- en nadelen.

Oorspronkelijk geplaatst door gjtje

Zonder PHP is er geen HHVM dus de stelling is enigszins vreemd maar men zal de engine bedoelen die de PHP code uitvoert.
Voor JIT zijn er al jaren meerdere oplossingen voor PHP (bijv Quercus), daar is HHVM niet de enige in. Ik zie niet waarom dat zou veranderen in de toekomst, elke oplossing heeft zo zijn voor- en nadelen.

Heb je zelf ervaring met andere JIT oplossingen? Ben wel benieuwd naar Quercus, ik heb er zelf nog niet mee gespeeld. Vraag me overigens ook af of deze oplossingen somehow inzetbaar zijn voor shared hosting omgevingen. Niet als standaard systeem maar een optionele keuze. Ik denk zelf dat voor een shared hosting omgeving teveel haken aan een JIT oplossing kan zitten.

Ik heb in het verleden met Quercus lopen spelen maar niet in detail uitgewerkt, de basis functies werken.

Sowieso is Java hosting natuurlijk al een aparte tak van sport en dan verwacht men meestal een omgeving op basis van Tomcat i.p.v. Resin (wat ik persoonlijk een veel fijnere oplossing vind :|) dus voor dit soort oplossingen zal je in de shared hosting hoek denk ik weinig animo vinden.