Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28288
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <BD.A5.39663.C8A3FE54@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 07 Mar 2007 16:19:45 -0600
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: PHP Just-In-Time Compiler
From: dragonwing@dragonu.net (Jacob Santos)

Has anyone tried this or know of anyone who is interested in 
implementing this for the Zend Engine? I tried searching the archives 
and didn't find anything on this topic. (Would Google help? No, only 
turns up some commercial PHP compiler for PHP 4.x.

I believe it is possible currently using the Zend Engine and working it 
either on top of APC or in place of APC. It would quite possibly help if 
I ventured further into the Zend Engine and looked at APC source.

Researching the topic has bought forth a very complex subject matter, 
which I suppose is one reason why it hasn't been implemented yet. It is 
easier (yes?) to compile to opcode and then interpret that or compile 
directly to machine code than building a JIT for all known CPU 
architectures (there goes two long years! More if I try to implement it 
and I do plan on trying... and will fail at it, but it should be 
interesting and fun to say the least).

The reason why I ask is after looking at speed comparsions, PHP does 
appear to fall behind even Ruby and Python. It is becoming difficult to 
justify continuing coding using PHP based on what would appear to be 
objective speed results. They perhaps, might not of used the APC or 
optimizer in the speed comparisons.

Discussions with my teacher on the subject matter further proved my 
assertion that PHP would be better served with JIT compiler than APC 
(Sorry! Sad but true). I will try to justify my statement and let more 
intelligent people of this mailing list beat me down, if the case is 
that I'm wrong.

Native Machine code will always be quicker than interpreting Opcode (I 
would so much assume that the PHP engine interprets and takes action 
upon the passed Opcode to the engine using APC). The reason from my 
research is that, well, you are passing the opcode through a layer 
before hitting the CPU whereas the machine code can pass directly to the 
CPU. Also machine code does not need to be interpreted by the machine 
and saves from that overhead.

It is possible to keep the PHP engine in control, while still running 
the JIT compilation. Little fuzzy on exactly how this would work. Would 
the compiled PHP script call PHP Engine, or would the PHP Engine call 
the compiled PHP script, or keeping it all in memory and somehow 
combining the two? Assembler seems quite fascinating, as well as 
learning other tidbits about compiling and languages I did not know before.

Two possible open source projects that would speed the process up 
considerably are GNU Lightning (http://www.gnu.org/software/lightning/) 
and YASM, the library not the compiler 
(http://www.tortall.net/projects/yasm/wiki). GNU Lightning seems to be 
the "best" choice from reading the brief description as it would work 
for most architectures (Apple included), which would work for PHP best 
interest as it is available for many platforms. From my reading, YASM 
library only works for x86 and x86-64 architectures. Lightning is also 
made for JIT, and therefore fits better for quick testing and deployment.

I'm not asking for anyone to take the project up, just what you think of 
me doing something like this and your opinion on the merits of JIT 
compiling.