Zend PHP JIT open sourced | Hacker News Reader

Zend PHP JIT open sourced

mail-archive.com

63 pointssathvikl15 comments

As much as their technological contributions are appreciated, the slow creep of Zend branding (and its own, different licensing) into PHP is not a good thing. Opcache is part of PHP now, yet it's Zend branded everywhere and has a bus factor of one (nobody can understand the source code except a Zend employee - every time anything's changed in the engine, Opcache breaks and he has to go and fix it). Similarly, it's not good that the Zend Engine is marked with a Zend Technologies copyright notice either. It's the core PHP runtime, yet if you read the notices you'd think it was some proprietary product donated by or licensed from them.

Pure open source doesn't seem to exist in this decade; all large enough projects seem to die without corporate sponsorship.

Of course, most good opensource have a corporate arm behind them, which helps fund development.

It was already like that with the projects that hit big.

Linux got lots of contributions from companies that would rather invest into it than paying UNIX licenses.

Eventually it got lots of support from the likes of IBM and Intel, because its existence suited their business.

GCC got lots of support when UNIX vendors started charging for their SDKs and smaller shops invested into it.

Likewise for many other projects.

Perl is thoroughly alive, large and not excessively corporate sponsored. Then again it's largely on the backchannel at the moment.

Zend Engine has been under it's own Zend license for 15 years I reckon. The web would probably look very different without Zend.

Zend now has a much larger, better-funded competitor with better engineers -- Facebook. I agree that it was a bad thing that Zend was trying to dominate the PHP community, but there's no longer a monopoly.

Facebook doesn't touch the original PHP interpreter.

In a language where the rules are defined by what one implementation does, once an alternative implementation has the necessary critical mass, that becomes the language.

So I guess HipHop will simply leapfrog them.

If I remember correctly, Facebook was submitting PHP patches for a long time, especially when they concerned security.

And once there's 100% parity between HHVM and Zend's interpreter, why would I, as a user, care whether the competitors are working on the same product?

Honestly, by creating a spec and a new implementation from scratch, Facebook has done far more (in far less time) for PHP than Zend has in the last 5+ years.

Everyone interested in this needs to read the thread carefully. This is not an actual JIT, and the synthetic benchmark is even more misleading than normal benchmarks.

Link to the benchmark in question: https://gist.github.com/dstogov/12323ad13d3240aee8f1

This is a good start to the conversation - PHP needs a fast JIT (& it can have a good one too), but it doesn't entirely help that the strict typing RFC has foundered.

About five years ago, I started to work on a basic block PHP JIT using libjit, mostly out of frustration of dealing with the dull progress I was making with pecl APC's speed & concurrency issues.

The JIT started off simple and then went nowhere for four months because the primary requirement for register allocator (and the jit_type_t SSA) is an actual type - the zval_ variables cannot sit on a register.

There's an old sys-con paper[1] by my guru, who found a way to build a direct threaded JIT which could run in partial JIT mode without working out how to handle complex exception handling or making non-inlined function calls out of the JIT (the engine was called CVM).

The reason my PHP JIT failed to do anything relevant was due to the opcode structure of PHP which triggers a halting problem version of type-checking which both JVM and .NET IL avoids. In this context, it should be mentioned that the .NET IL bytecode is actually polymorphic (i.e JVM has iadd/ladd/fadd, while the IL has just add & add.ovf).

The types of the variables on the ->op1 and ->op2 needn't be the same type in PHP, so that each opcode is actually prefixed by a routing to the right binary operator table [2].

This means that the memory bandwidth overheads and branch prediction mechanisms on the JIT generated code would be nearly exactly the same as the regular C implementation of the engine.

HHVM works around the exact same problem by forcing the type specification as a HACK-LANG type system, which allows it to really go ahead and optimize the pointless type-checking.

PHP needn't entirely force strict-typing across the board, but at least needs to prevent different codepaths from ending up at the same opcode with vastly different types.

That one detail is effectively stopping a sane JIT from being built for PHP - because it neither a register machine (like perl6/parrod), nor a stack machine (like JVM, .NET or Python), but an opcode sequence more tied together like a rough DAG connected via ->op1, ->op2, ->result, along with the TMPVAR indexes.

That gets insanely complex to process very quickly as you have to traverse every-path including branch-backs to generate type traces through it - the loop could execute once where $a is an int and again with $a being a float.

All that said, this is an AOT engine - it does use LLVM, but is mostly entirely compiled before running (like old HipHop C++ compiler) and then does not by-pass the overheads introduced by the lack of type verifiability for an opcode.

[1] - http://www2.sys-con.com/itsg/virtualcd/dotnet/archives/0103/... [2] - https://github.com/php/php-src/blob/master/Zend/zend_vm_gen....

What makes PHP different from JS? Given the performance improvements realized in JS with JIT engines it seems the same benefits should be possible in PHP.

It took a lot of work to get JS to its current speed. Here the incentive is that for the web to be fast, JS has to be fast.

That incentive breaks on the server where you can use any language you want anyway.

Reply on news.ycombinator.com