----- Original Message ----- From: "Sterling Hughes" <[EMAIL PROTECTED]>
> The point, if you'd really like to know is that PHP is *not* > optimized to do matrix operations (which is one of the examples), or > infinitely recursive loops (I'm not even addressing the code at this > point) -- but that makes little difference in a real world script. The real world is made up of method calls, array access, counts, echo's, hashes, string concatenation, file i/o. This benchmark tests those. > > As a side note, If you couple PHP with the Zend Optimizer and/or Zend > Cache (or APC Cache for that matter), you'll see PHP start smoking on > these examples. Ie, *free* external products can make PHP extremely > fast. Does the Zend Cache or APC Cache do things I wasn't aware of? Did you run these examples under these caches and see PHP start smoking? Sterling, generally these products just cache the result of an intermediate compilation step, they do not speed up the actual calls. > > PHP is a web scripting language first and foremost (although it can > be used for other things like cron jobs, or even GUI's). A good > benchmark wouldn't match PHP against languages like C, *of course* C > will be faster -- there is no way to bring PHP even close to the > speed of a *well written* (key phrase) C program. But PHP is also a > very easy language to develop with and use, so of course you trade > of some speed. > > It really is stupid to have trivial operations like a large set of cascading > loops or matrix multipication. In real life cases is where > benchmarks count, and in those cases PHP does a superb job when it > comes to performance. A proper benchmark would take into account, > RPC, Database access, output capabilities, system accesses, file > i/o (sorta-kinda-maybe benchmarked in the test cases, but not > properly done.) The matchups I was interested in are not C, that is another red herring you are throwing around. Take a look at perl (a scripting language) which is in this space and which I have actually been talking about. And these "trivial operations" are trivial for a reason, they allow you to focus in on specific aspects of a languge. When you write your RPC/Database/Output/System/File I/O benchmark good luck figuring out where the problems in any of the languages lie, those types of benchmarks are even more difficult to rely on since a ton of factors can confuse the issue even more. And before you keep on hammering on the fact that that type of benchmark is the one you would see written, take a look at Microsft/Sun/Oracle who benchmark their "pet store" apps and have no hope of agreeing on anything. Complex apps can be written 30 ways to Sunday, and a small semantic difference can blow results out of the water. The fact is benchmarking is hard, and "really stupid trivial" can be useful. > > Anyways, the challenge is down, here's the code, optimize away. Then we can > > talk about the real causes for PHP slow performance :) They still may be as > > trivial as bad compile time or config settings but I think this bad php > > programmer thing is a red herring. > > > > Well: > > 1) He didn't compile with --enable-inline-optimizations I myelf lean towards these kinds of configuration boo-boo's as a source of problems. --enable-inline does not appear to be one of them. > 2) He's not using the Zend Optimizer Propriatery product, not part of php default distro > 3) From a "base installation" perspective, he should be using while > loops not for loops (which he does in the Perl example). This does help, but perl still performs 3x faster on my system. > 4) he should be using ++$var not $var++ (from a "base installation" > perspective). Makes no appreciable difference. I continue to see these "stupid trivial" benchmarks as useful. I think that "code it in C if you care about performance" is a bogus argument, those of us coding real world apps have to occasionaly meet deadlines. Given that, it is nicer to see PHP perform better. Hopefully at the end of this dicussion that may be the case, or at least we'll all be up on how important various compile flags are. - August -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
