With all the news of TraceMonkey bringing an order of magnitude speed
increase to JavaScript, it was only a matter of time before someone
brought up (again) the idea of doing JIT for PHP, so I'll take the
flack and let it be me. The part that knocked me over was the "work
began just about 60 days ago" part. Of course, that needs to be put in
context -- they were working on tracing in Tamarin before trying it in
SpiderMonkey, so there was a huge amount of time dedicated building up
experience that is not counted in that 60 days.
Even so, I think there is good evidence that such a project can be
done in a reasonable timeframe. The largest users of PHP with large
PHP server farms could see significant savings in hardware, and really
ought to consider such a project. (And please, no comments on how
speed of PHP doesn't matter because databases are slow -- such is not
the case for people with such large PHP server farms).
So, perhaps this is the right time, with a nice case study, for PHP
coders at some of these big users to pursue resources for JIT in PHP.
Cough. Facebook. Cough. Yahoo. Cough. Please excuse my coughs...
steve schrieb:
With all the news of TraceMonkey bringing an order of magnitude speed
increase to JavaScript, it was only a matter of time before someone
brought up (again) the idea of doing JIT for PHP, so I'll take the
flack and let it be me.
http://cvs.php.net/viewvc.cgi/pecl/llvm
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
I know llvm allows nicer licensing such that the runtime can be
embeded -- is this what this extension does?
On Mon, Aug 25, 2008 at 10:51 AM, Sebastian Bergmann
sb@sebastian-bergmann.de wrote:
steve schrieb:
With all the news of TraceMonkey bringing an order of magnitude speed
increase to JavaScript, it was only a matter of time before someone
brought up (again) the idea of doing JIT for PHP, so I'll take the
flack and let it be me.http://cvs.php.net/viewvc.cgi/pecl/llvm
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Has anyone had success compiling PHP with LLVM?
On Mon, Aug 25, 2008 at 10:51 AM, Sebastian Bergmann
sb@sebastian-bergmann.de wrote:
steve schrieb:
With all the news of TraceMonkey bringing an order of magnitude speed
increase to JavaScript, it was only a matter of time before someone
brought up (again) the idea of doing JIT for PHP, so I'll take the
flack and let it be me.http://cvs.php.net/viewvc.cgi/pecl/llvm
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Has anyone had success compiling PHP with LLVM?
I haven't tried it, here is a good summary:
http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdf
In short, it is 'slower' but that seems to be without any caching of the
"bytecode"
Bytecode is not opcode:
http://www.santosj.name/general/computers/byte-code-vs-op-code/
Right now, the most effective strategy to optimize php is executing opcodes
using an "opcode" cache such as APC (facebook & others use this).
That's from my research, maybe someone can correct me here.
Isn't using something like Zend Guard (converts code into opcode) then
caching the opcodes essentially JIT?
Even if opcode is not binary, it's still a fast intermediate form that gets
translated into machine binary, isn't that JIT?
On Tue, Aug 26, 2008 at 6:57 AM, Jonathan Bond-Caron jbondc@openmv.comwrote:
Has anyone had success compiling PHP with LLVM?
I haven't tried it, here is a good summary:
http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdfIn short, it is 'slower' but that seems to be without any caching of the
"bytecode"Bytecode is not opcode:
http://www.santosj.name/general/computers/byte-code-vs-op-code/Right now, the most effective strategy to optimize php is executing opcodes
using an "opcode" cache such as APC (facebook & others use this).That's from my research, maybe someone can correct me here.
Isn't using something like Zend Guard (converts code into opcode) then
caching the opcodes essentially JIT?Even if opcode is not binary, it's still a fast intermediate form that gets
translated into machine binary, isn't that JIT?
i think that depends on what happens inside of php.. since i dont know the
inner workings im guessing executing opcodes is pretty much the same thing
every time, that is a certain opcode correlates to some precompiled code
which is feed some variables at runtime. whereas in JIT, w/ java anyway, it
actually takes bytecode (precompiled by the users [in .class files]) and
compiles down to binary as certain pieces of bytecode are compiled. that
compiled bytecode is then availble to the jvm through the remainder of that
instances lifetime.
so although php executes opcodes on an, as needed basis, i think the
difference is that opcode correlate to precomipled binary, whereas w/ JIT,
compilation (from opcode to binary) is actually occurring at runtime.
http://schmidt.devlib.org/java/jit-compilers.html
-nathan
Has anyone had success compiling PHP with LLVM?
I haven't tried it, here is a good summary:
http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdfIn short, it is 'slower' but that seems to be without any caching of the
"bytecode"
So yes, we were able to make a JIT compiler for PHP, that is able to produce
(and execute) binary code out of PHP scripts. It integrates nicely with the
Zend VM and requires no modifications to it.
The project is nowhere near completion, as caching of the code isn't
implemented yet. Also, off-line compilation (i.e. producing standalone
executables) is not working yet as well.
There's also another project (completely unrelated and independent) that
aims to compile PHP scripts to .NET bytecode (MSIL), but the approach is
quite different.
That's from my research, maybe someone can correct me here.
Isn't using something like Zend Guard (converts code into opcode) then
caching the opcodes essentially JIT?
The products available out there do not produce machine code, so I wouldn't
call them JIT compilers.
Nuno