This comes up once or twice a year. The machine code you compile to is going to end up looking a lot like the current executor since you don't have strong types to help you optimize anything. You'd still need to pass the unions around and do runtime type juggling and all the overhead that comes along with that.
The idea behind PHP from day one was that it was an environment for wrapping compiled code. Things that are performance critical is written in C/C++ and things that aren't are left in the PHP templates. Whether you issue an SQL query from PHP or from a compiled C program doesn't affect the overall performance of the system so you might as well do that from PHP. If you are calculating a fractal, you write it in C and expose it to PHP with a get_fractal($args) function call so you can mark it up and easily change the args passed to the underlying function. It is really important for PHP to have as little overhead as possible between itself and the speed-critical code behind it and less important that the userspace executor is fast. That doesn't mean it should be slow. It should be as fast as we can make it, but not at the cost of convenience. -Rasmus Jacob Santos wrote: > 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. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
