On Wed, Mar 07, 2007 at 04:19:45PM -0600, Jacob Santos wrote: > 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
You don't understand how APC is used. On large web sites that run APC each PHP file will, eventually, end up being compiled once and end up in the bytecode cache. On these sites the PHP code that is run is known and does not change (often). A good administrator will ensure that the cache is large enough so that you don't get thashing -- memory is cheap. The above might not be true for an ISP that hosts many virtual sites, but then APC may not help them much. What APC does is to eliminate the continual recompilation to bytecode. JIT is different. The language (eg Java) is compiled to a bytecode and then often stored in a file. This bytecode will then run later, possibly on another machine. The JIT translates the bytecode to machine code just prior to it being executed - a function/... at a time, only translating the bits that are needed. JIT translates the bits of bytecode that are needed into machine code. So you see that they are really different things. I suppose that you could add an extra JIT step to APC that translated bytecode to machine code as it is needed -- to get the big win it probably ought to cache the machine code as well. I suspect that if this were to be done, APC/translator would probably be best translating all the bytecode to machine code on the assumption that most of the code is going to be run eventually anyway and that the hit of a full translation is small considering that the code is going to be run many times. Quite how big the win would be I don't know. Much PHP execution is NOT nice integer/... loops that make fast machine code but involves function calls for things like string manipilation, these functions are in machine code anyway (written in C). So the improvement might not be as much as you expect. There are also some PHP features that I suspect don't map to machine code well (like the use of the symbol table). I'll let others talk about that. It would make PHP more complicated to distribute since a translator to CPU specific machine could would be needed. > intelligent people of this mailing list beat me down, if the case is > that I'm wrong. Before thinking about this: try to demonstrate how much we would gain on typical web sites. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include <std_disclaimer.h> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
