On Tue, Aug 26, 2008 at 6:57 AM, Jonathan Bond-Caron <[EMAIL PROTECTED]>wrote:
> On Mon Aug 25 06:28 PM, steve wrote: > > 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? 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
