Speaking as someone who's hit the barriers of PHP performance for many years, this is a good start. But I wish it was done a little nicely from the community p

Speaking as someone who's hit the barriers of PHP performance for many years, this is a good start. But I wish it was done a little nicely from the community point of view (the >4gb strings stuff). I'm considerably less talented than Dmitry and I spent several months of my life trying to unsuccessfully write a JIT for PHP - most of what stopped me was the rest of the Zend engine itself. While I was maintaining PHP-APC, I spent many weeks trying to write a basic block JIT for php, when Zend is using the CGOTO core (FYI, if you are still using APC, switch to Zend OpCache). This would compile code which didn't have any jumps into a native chunk and swap out the opcode's handler location into my native chunk. The little I did actually do ended up being fairly involved assembly rewrites of the inner loop. http://notmysock.org/blog/php/optimising-ze2 http://notmysock.org/blog/php/optimising-ze2 No matter what I did, the issues of the bytecode organization (the ->result reference) and the lack of type verifiability in the code generation resulted in me slowly throwing away every prototype somewhere between the for loop and running the default benchmark.php. I haven't read through all the changes yet, but IMHO the Zend engine will be an absolute pain to deal with until we get to type inference/verifiability into the bytecode format so that integers get integer register ops in the JIT instead of always being zval_* based. But a cleanup was due. And a faster VM (either HHVM or PHPng++) is good news for the regular PHP users.