
Zend PHP JIT open sourced - sathvikl
https://www.mail-archive.com/internals@lists.php.net/msg76332.html
======
TazeTSchnitzel
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.

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

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

------
McGlockenshire
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
Link to the benchmark in question:
[https://gist.github.com/dstogov/12323ad13d3240aee8f1](https://gist.github.com/dstogov/12323ad13d3240aee8f1)

------
gopalv
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/...](http://www2.sys-
con.com/itsg/virtualcd/dotnet/archives/0103/weatherley/index.html) [2] -
[https://github.com/php/php-
src/blob/master/Zend/zend_vm_gen....](https://github.com/php/php-
src/blob/master/Zend/zend_vm_gen.php#L687)

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

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

