Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
I have measured Quercus php performance compared to standard php with APC on a ecommerce workload and found that Quercus php performed slower than standard php + APC. Regards, Basant. On Aug 16, 2009, at 11:16 AM, Tom Boutell wrote: Re: the performance of PHP, if it's badly implemented, shouldn't Quercus (a reimplementation of PHP in Java) run rings around it? In reality, Quercus is faster than PHP without APC, but with APC the Quercus team themselves admit it only roughly matches the original PHP in speed. http://www.caucho.com/resin-3.0/quercus/ I guess you could spin this the other way though. Java optimizes well, but not as well as raw C. Standard PHP, being implemented in raw C, ought to have some performance advantages over a reimplementation in Java. But apparently not so much. On Sun, Aug 16, 2009 at 1:53 PM, Lothar Scholzsch...@scriptolutions.com wrote: Hello Paul, PB Yes, by many times. Part of that might be the expense of PHP's weak PB typing and references. No. Smalltalk, Javascript, Lua they all have the same problem with it and they solve it in much more clever and performant ways. Javascript with its class free OO is even harder and with V8 they have a much much better solution. It's just the implementation - not the language. PB They cause most operations to be more PB expensive, even if they are not used in that particular operation. PB I did a performance analysis of PHP in a paper I have in submission. PB You might find it interesting (comment welcome): PB https://www.cs.tcd.ie/~pbiggar/wip-sac-journal.pdf. Thanks, just had a 10min quick look at it - hope to find some more time later. And first of all begin a tool writer (IDE Developer) myself i can't agree more about the problems with the source is the specification idea. Strong Language Warning This sucks so huge and is such a fucking lazy argument of an incompetent language development team. By the way greetings to Matz and his team who also sucks with his CRuby. I really questioning the skills of a lot of core programmers when i read the PHP manual section about namespaces. Simple questions about scopes of identifier aliasing - nothing of this is specified. A buggy implementation should solve as reference? Damn'd fucking college boys. This was an acceptable development method for PHP3. /Strong Language Warning Okay i must cool myself down. I've seen that you talked about branch prediction misses in your paper. Did you ever tried to compile the original PHP with different compilers, for example from intel or sun studio? Did you test or have you ever heard of someone who tested the influence of the profiling feedback that modern C compilers offer? (Well don't ask me - it's somewhere on my TODO list - but i also haven't had the time yet). -- Best regards, Lothar Scholzmailto:sch...@scriptolutions.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
On Aug 16, 2009, at 2:25 PM, Paul Biggar wrote: I've seen that you talked about branch prediction misses in your paper. Did you ever tried to compile the original PHP with different compilers, for example from intel or sun studio? Did you test or have you ever heard of someone who tested the influence of the profiling feedback that modern C compilers offer? (Well don't ask me - it's somewhere on my TODO list - but i also haven't had the time yet). I tried FDO with gcc 4.4 on phc generated code, but not on the PHP interpreter. I've not looked at other compilers either. I tried Sun Studio 12 feedback profile based optimization on Solairs sparc and found only a small gain (~1.5%) in a ecommerce php application. Moreover feedback optimizations works sometimes if it is trained with same set of samples (which I avoided in my measurements). Feedback optimization however helped me find out where compiler is doing additional inlining. Coolstack provided php binaries which is compiled with Studio 12 feedback optimization. Basant. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
Hello Paul, PB Yes, by many times. Part of that might be the expense of PHP's weak PB typing and references. No. Smalltalk, Javascript, Lua they all have the same problem with it and they solve it in much more clever and performant ways. Javascript with its class free OO is even harder and with V8 they have a much much better solution. It's just the implementation - not the language. PB They cause most operations to be more PB expensive, even if they are not used in that particular operation. PB I did a performance analysis of PHP in a paper I have in submission. PB You might find it interesting (comment welcome): PB https://www.cs.tcd.ie/~pbiggar/wip-sac-journal.pdf. Thanks, just had a 10min quick look at it - hope to find some more time later. And first of all begin a tool writer (IDE Developer) myself i can't agree more about the problems with the source is the specification idea. Strong Language Warning This sucks so huge and is such a fucking lazy argument of an incompetent language development team. By the way greetings to Matz and his team who also sucks with his CRuby. I really questioning the skills of a lot of core programmers when i read the PHP manual section about namespaces. Simple questions about scopes of identifier aliasing - nothing of this is specified. A buggy implementation should solve as reference? Damn'd fucking college boys. This was an acceptable development method for PHP3. /Strong Language Warning Okay i must cool myself down. I've seen that you talked about branch prediction misses in your paper. Did you ever tried to compile the original PHP with different compilers, for example from intel or sun studio? Did you test or have you ever heard of someone who tested the influence of the profiling feedback that modern C compilers offer? (Well don't ask me - it's somewhere on my TODO list - but i also haven't had the time yet). -- Best regards, Lothar Scholzmailto:sch...@scriptolutions.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
Re: the performance of PHP, if it's badly implemented, shouldn't Quercus (a reimplementation of PHP in Java) run rings around it? In reality, Quercus is faster than PHP without APC, but with APC the Quercus team themselves admit it only roughly matches the original PHP in speed. http://www.caucho.com/resin-3.0/quercus/ I guess you could spin this the other way though. Java optimizes well, but not as well as raw C. Standard PHP, being implemented in raw C, ought to have some performance advantages over a reimplementation in Java. But apparently not so much. On Sun, Aug 16, 2009 at 1:53 PM, Lothar Scholzsch...@scriptolutions.com wrote: Hello Paul, PB Yes, by many times. Part of that might be the expense of PHP's weak PB typing and references. No. Smalltalk, Javascript, Lua they all have the same problem with it and they solve it in much more clever and performant ways. Javascript with its class free OO is even harder and with V8 they have a much much better solution. It's just the implementation - not the language. PB They cause most operations to be more PB expensive, even if they are not used in that particular operation. PB I did a performance analysis of PHP in a paper I have in submission. PB You might find it interesting (comment welcome): PB https://www.cs.tcd.ie/~pbiggar/wip-sac-journal.pdf. Thanks, just had a 10min quick look at it - hope to find some more time later. And first of all begin a tool writer (IDE Developer) myself i can't agree more about the problems with the source is the specification idea. Strong Language Warning This sucks so huge and is such a fucking lazy argument of an incompetent language development team. By the way greetings to Matz and his team who also sucks with his CRuby. I really questioning the skills of a lot of core programmers when i read the PHP manual section about namespaces. Simple questions about scopes of identifier aliasing - nothing of this is specified. A buggy implementation should solve as reference? Damn'd fucking college boys. This was an acceptable development method for PHP3. /Strong Language Warning Okay i must cool myself down. I've seen that you talked about branch prediction misses in your paper. Did you ever tried to compile the original PHP with different compilers, for example from intel or sun studio? Did you test or have you ever heard of someone who tested the influence of the profiling feedback that modern C compilers offer? (Well don't ask me - it's somewhere on my TODO list - but i also haven't had the time yet). -- Best regards, Lothar Scholz mailto:sch...@scriptolutions.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
Hi Tom, On Sun, Aug 16, 2009 at 7:16 PM, Tom Boutellt...@punkave.com wrote: Re: the performance of PHP, if it's badly implemented, shouldn't Quercus (a reimplementation of PHP in Java) run rings around it? In reality, Quercus is faster than PHP without APC, but with APC the Quercus team themselves admit it only roughly matches the original PHP in speed. Having spent a few years working on a PHP compiler (phc - phpcompiler.org), I can suggest a few reasons for this. Mostly, its hard to get fast when you have a small team. The effort involved in even making a language match the underspecified, ad-hoc nature of PHP's reference implementation is staggering. Roadsend seem to have the same problem. Secondly, all of PHP's libraries are similarly specified. They are all written using the Zend API, and there are about 5000 functions. A compelling reimplementation must reimplement large portions of this. Its no small challenge. In short, I believe the lack of great speedups from other PHP implementations (including my own) can be attributed at least partially to the implementation difficulty and under-specification of PHP the language. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
Hi Lothar, On Sun, Aug 16, 2009 at 6:53 PM, Lothar Scholzsch...@scriptolutions.com wrote: PB Yes, by many times. Part of that might be the expense of PHP's weak PB typing and references. No. Smalltalk, Javascript, Lua they all have the same problem with it No, I disagree. Javascript, Lua and Smalltalk are much simpler languages. None of them have references, which make many of the implementation techniques more complicated. The weak typing you find in Lua and Javascript are not as complex as in PHP. Lua has no variable-variables. And there is plenty going on behind the scenes that make improving the interpreter hard. Take a look at Section 2 of my optimizer paper to see some of the challenges (https://www.cs.tcd.ie/~pbiggar/#wip-optimizer) and they solve it in much more clever and performant ways. Javascript Yes, they often do. But there is still a larger challenge with PHP. with its class free OO is even harder and with V8 they have a much much better solution. Its very difficult for an interpreter to take advantage of PHP's static class hierarchy. So its not much of an advantage. V8 is a JIT, so its unfair to compare it to a straightforward interpreter. JIT's have plenty of disadvantages, most of all portability - V8 runs on very few platforms. It's just the implementation - not the language. In my opinion, its almost certainly both. I've argued that pretty strongly in my papers. Strong Language Warning This sucks so huge and is such a fucking lazy argument of an incompetent language development team. It think its more the lack of a language implementation team. I don't think there is anybody spending significant time on making the PHP interpreter faster. I've seen that you talked about branch prediction misses in your paper. Did you ever tried to compile the original PHP with different compilers, for example from intel or sun studio? Did you test or have you ever heard of someone who tested the influence of the profiling feedback that modern C compilers offer? (Well don't ask me - it's somewhere on my TODO list - but i also haven't had the time yet). I tried FDO with gcc 4.4 on phc generated code, but not on the PHP interpreter. I've not looked at other compilers either. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
