Zend PHP JIT open sourced

Zend PHP JIT open sourced(mail-archive.com)

63 points by sathvikl 11 years ago | 15 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.

smt88 11 years ago | |

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.

TazeTSchnitzel 11 years ago | | |

Facebook doesn't touch the original PHP interpreter.

ukandy 11 years ago | |

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

juliangregorian 11 years ago | |

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

pjmlp 11 years ago | | |

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.

thejosh 11 years ago | | |

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

singingfish 11 years ago | | |

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

McGlockenshire 11 years ago |

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.

nes350 11 years ago | |

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

gopalv 11 years ago |

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