Re: [PHP-DEV] Re: Shootout
This is not really surprising, and the test is not really fair, the PHP code is not written by an experienced php programmer, and thus, would naturally be slower, on person benchmarks like this are simply too dependent on the person writing the code. -Sterling Give me a break. Did you even check a SINGLE one of the routines? Since you ARE an experienced php programmer I'm attaching the nested loop test where PHP scored at the BOTTOM of all 30 languages for you to optimize. I mean, I looked over a number of the snippets and they are very straightforward, especially the same way tests. This type of knee-jerk (and spectacularly uninformed) discounting of results gets us nowhere and as you can probably tell irritates me no end :). There are too many folks too quick to sound authoratative on an issue. Read through the site, Doug is aware of the problems in benchmarking (everyone who has ever tried doing them is probably aware) and worked hard to overcome many of them. 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. - August ?php/* $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $ http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a$n; $a++) for ($b=0; $b$n; $b++) for ($c=0; $c$n; $c++) for ($d=0; $d$n; $d++) for ($e=0; $e$n; $e++) for ($f=0; $f$n; $f++) $x++; print $x\n; ? Perl took 18 CPU secs, PHP 85. -- 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]
Re: [PHP-DEV] Re: Shootout
This is not really surprising, and the test is not really fair, the PHP code is not written by an experienced php programmer, and thus, would naturally be slower, on person benchmarks like this are simply too dependent on the person writing the code. -Sterling Give me a break. Did you even check a SINGLE one of the routines? Since you ARE an experienced php programmer I'm attaching the nested loop test where PHP scored at the BOTTOM of all 30 languages for you to optimize. I mean, I looked over a number of the snippets and they are very straightforward, especially the same way tests. This type of knee-jerk (and spectacularly uninformed) discounting of results gets us nowhere and as you can probably tell irritates me no end :). There are too many folks too quick to sound authoratative on an issue. Read through the site, Doug is aware of the problems in benchmarking (everyone who has ever tried doing them is probably aware) and worked hard to overcome many of them. 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. - August ?php/* $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $ http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a$n; $a++) for ($b=0; $b$n; $b++) for ($c=0; $c$n; $c++) for ($d=0; $d$n; $d++) for ($e=0; $e$n; $e++) for ($f=0; $f$n; $f++) $x++; print $x\n; ? Perl took 18 CPU secs, PHP 85. -- 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]
Re: [PHP-DEV] Re: Shootout
This is not really surprising, and the test is not really fair, the PHP code is not written by an experienced php programmer, and thus, would naturally be slower, on person benchmarks like this are simply too dependent on the person writing the code. -Sterling Give me a break. Did you even check a SINGLE one of the routines? Since you ARE an experienced php programmer I'm attaching the nested loop test where PHP scored at the BOTTOM of all 30 languages for you to optimize. I mean, I looked over a number of the snippets and they are very straightforward, especially the same way tests. This type of knee-jerk (and spectacularly uninformed) discounting of results gets us nowhere and as you can probably tell irritates me no end :). There are too many folks too quick to sound authoratative on an issue. Read through the site, Doug is aware of the problems in benchmarking (everyone who has ever tried doing them is probably aware) and worked hard to overcome many of them. 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. - August ?php/* $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $ http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a$n; $a++) for ($b=0; $b$n; $b++) for ($c=0; $c$n; $c++) for ($d=0; $d$n; $d++) for ($e=0; $e$n; $e++) for ($f=0; $f$n; $f++) $x++; print $x\n; ? Perl took 18 CPU secs, PHP 85. -- 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]
Re: [PHP-DEV] Re: Shootout
Could you specify which $n you were using, and also provide the equivalent Perl script that you used? Zeev On Sat, 29 Dec 2001, August Zajonc wrote: This is not really surprising, and the test is not really fair, the PHP code is not written by an experienced php programmer, and thus, would naturally be slower, on person benchmarks like this are simply too dependent on the person writing the code. -Sterling Give me a break. Did you even check a SINGLE one of the routines? Since you ARE an experienced php programmer I'm attaching the nested loop test where PHP scored at the BOTTOM of all 30 languages for you to optimize. I mean, I looked over a number of the snippets and they are very straightforward, especially the same way tests. This type of knee-jerk (and spectacularly uninformed) discounting of results gets us nowhere and as you can probably tell irritates me no end :). There are too many folks too quick to sound authoratative on an issue. Read through the site, Doug is aware of the problems in benchmarking (everyone who has ever tried doing them is probably aware) and worked hard to overcome many of them. 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. - August ?php/* $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $ http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a$n; $a++) for ($b=0; $b$n; $b++) for ($c=0; $c$n; $c++) for ($d=0; $d$n; $d++) for ($e=0; $e$n; $e++) for ($f=0; $f$n; $f++) $x++; print $x\n; ? Perl took 18 CPU secs, PHP 85. -- Zeev Suraski [EMAIL PROTECTED] http://www.zend.com/ -- 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]
Re: [PHP-DEV] Re: Shootout
Sure,
These are not my tests but Doug's. He compiled default so --debug
and --inline-optimization not kicking in. Startup cost also counted, but he
tried to run long enough to amortize that.
n was 16.
perl code was something like this.
#!/usr/local/bin/perl
# $Id: nestedloop.perl,v 1.2 2000/12/30 21:42:57 doug Exp $
# http://www.bagley.org/~doug/shootout/
use strict;
my $n = ($ARGV[0] 0) ? $ARGV[0] : 1;
my $x = 0;
my $a = $n;
while ($a--) {
my $b = $n;
while ($b--) {
my $c = $n;
while ($c--) {
my $d = $n;
while ($d--) {
my $e = $n;
while ($e--) {
my $f = $n;
while ($f--) {
$x++;
}
}
}
}
}
}
print $x\n;
--
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]
Re: [PHP-DEV] Re: Shootout
Taking that code and coupling the Zend Optimizer, PHP and Perl were
approximately the same speed (Perl was 8% faster, but that probably varies
across platforms).
W/o the optimizer PHP was 2 times slower, but again, that's only because
this is not a very real-world piece of code, at least for our space
(scripting languages).
Zeev
On Sat, 29 Dec 2001, August Zajonc wrote:
Sure,
These are not my tests but Doug's. He compiled default so --debug
and --inline-optimization not kicking in. Startup cost also counted, but he
tried to run long enough to amortize that.
n was 16.
perl code was something like this.
#!/usr/local/bin/perl
# $Id: nestedloop.perl,v 1.2 2000/12/30 21:42:57 doug Exp $
# http://www.bagley.org/~doug/shootout/
use strict;
my $n = ($ARGV[0] 0) ? $ARGV[0] : 1;
my $x = 0;
my $a = $n;
while ($a--) {
my $b = $n;
while ($b--) {
my $c = $n;
while ($c--) {
my $d = $n;
while ($d--) {
my $e = $n;
while ($e--) {
my $f = $n;
while ($f--) {
$x++;
}
}
}
}
}
}
print $x\n;
--
Zeev Suraski [EMAIL PROTECTED]
http://www.zend.com/
--
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]
Re: [PHP-DEV] Re: Shootout
August Zajonc wrote: These are not my tests but Doug's. He compiled default so --debug and --inline-optimization not kicking in. Startup cost also counted, but he tried to run long enough to amortize that. By default, PHP is built without debugging. By the way, what happened to the plan of turning on inline optimization by default? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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]
Re: [PHP-DEV] Re: Shootout
Sucks when you need to use a proprietary extension to a language to make
it benchmark well.
George
On Saturday, December 29, 2001, at 12:27 PM, Zeev Suraski wrote:
Taking that code and coupling the Zend Optimizer, PHP and Perl were
approximately the same speed (Perl was 8% faster, but that probably
varies
across platforms).
W/o the optimizer PHP was 2 times slower, but again, that's only because
this is not a very real-world piece of code, at least for our space
(scripting languages).
Zeev
On Sat, 29 Dec 2001, August Zajonc wrote:
Sure,
These are not my tests but Doug's. He compiled default so --debug
and --inline-optimization not kicking in. Startup cost also counted,
but he
tried to run long enough to amortize that.
n was 16.
perl code was something like this.
#!/usr/local/bin/perl
# $Id: nestedloop.perl,v 1.2 2000/12/30 21:42:57 doug Exp $
# http://www.bagley.org/~doug/shootout/
use strict;
my $n = ($ARGV[0] 0) ? $ARGV[0] : 1;
my $x = 0;
my $a = $n;
while ($a--) {
my $b = $n;
while ($b--) {
my $c = $n;
while ($c--) {
my $d = $n;
while ($d--) {
my $e = $n;
while ($e--) {
my $f = $n;
while ($f--) {
$x++;
}
}
}
}
}
}
print $x\n;
--
Zeev Suraski [EMAIL PROTECTED]
http://www.zend.com/
--
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]
--
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]
Re: [PHP-DEV] Re: Shootout
Interesting... There are a couple of other tests that PHP does poorly on. http://www.bagley.org/~doug/shootout/lang/php/ might be worth looking at. --enable-inline-optimization only made a small difference for me. Generally my results matched up pretty closely with Dougs for the few tests I did on my machine and I didn't catch a lot of unoptimized code. While these are clearly synthetic tests, that looping was similar actually to something I did for a big reference tree of 400,000 odd users that would take up to an hour to complete. Web apps in the end are made up of a bunch of these synthetics. What was suprising to me is that other scripting players like perl did reasonably well on some of them. Java has a more impressive showing than I would I have thought as well. Certainly some interesting food for thought. - August Curious looking forward (ZE2) where PHP is moving performance wise. My sense is that the focus is more feature oriented. - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: August Zajonc [EMAIL PROTECTED] Cc: Sterling Hughes [EMAIL PROTECTED]; Markus Fischer [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 9:27 AM Subject: Re: [PHP-DEV] Re: Shootout Taking that code and coupling the Zend Optimizer, PHP and Perl were approximately the same speed (Perl was 8% faster, but that probably varies across platforms). W/o the optimizer PHP was 2 times slower, but again, that's only because this is not a very real-world piece of code, at least for our space (scripting languages). Zeev -- 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]
Re: [PHP-DEV] Re: Shootout
Another question, what CFLAGS/CPPFLAGS were used during the compliation of
the test programs for languages that allow compilation? As well as what
cflags were used to compile the intepreters for languages that do not compile
individual programs such as PHP AWK.
In my experience even something as small as lack of -O3 flag can result in a
major performance loss.
Prottoss
[EMAIL PROTECTED]
ICQ: 23361082
http://mediaminer.org/
On December 29, 2001 03:26 pm, August Zajonc wrote:
Sure,
These are not my tests but Doug's. He compiled default so --debug
and --inline-optimization not kicking in. Startup cost also counted, but he
tried to run long enough to amortize that.
n was 16.
perl code was something like this.
#!/usr/local/bin/perl
# $Id: nestedloop.perl,v 1.2 2000/12/30 21:42:57 doug Exp $
# http://www.bagley.org/~doug/shootout/
use strict;
my $n = ($ARGV[0] 0) ? $ARGV[0] : 1;
my $x = 0;
my $a = $n;
while ($a--) {
my $b = $n;
while ($b--) {
my $c = $n;
while ($c--) {
my $d = $n;
while ($d--) {
my $e = $n;
while ($e--) {
my $f = $n;
while ($f--) {
$x++;
}
}
}
}
}
}
print $x\n;
--
--
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]
Re: [PHP-DEV] Re: Shootout
- 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]
Re: [PHP-DEV] Re: Shootout
August Zajonc wrote: - 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. nobody that knows what is doing will never end up writing such calculus intensive code in PHP! also i want to point you that in some tests, much more related to the usefulness of a scripting language (array hashing and string concats), php performs pretty well, better than java. The real world is also made of web servers, databases, HTML, esoteric API, people learning how to build a program: this kind of benchmark does not take in account this. If this benchmark had some significance everybody will start tomorrow to write web application in that obscure language *mercury*, so strong at nesting loops. regards, -- Roberto Biancardi -- [EMAIL PROTECTED] -- -- 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]
RE: [PHP-DEV] Re: Shootout
August Zajonc continues with ... I continue to see these stupid trivial benchmarks as useful. The benchmark code is pre-alpha and incomplete as the author states expressly. 'Useful' does not imply reliable, factual, or scientific. In my view, what I've seen and read is neither useful, nor harbours any of the other qualities, mentioned above, that reasonable people might consider important. IMHO, the benchmarks are bogus from the get go, and this discussion is moot. 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. Please ask support questions on the friendly helpful php-general list. Mike Robinson -- 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]
Re: [PHP-DEV] Re: Shootout
At 00:11 30/12/2001, August Zajonc wrote: 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. If you use caching software, chances are PHP will be faster than Perl even without the optimizer. And it does that without any hassle or special planning, unlike Perl for that matter. If you use the optimizer - it gets as quick as Perl, and that's without caching. Couple the two together - and you have a serious performance screamer. That said, in most real world situations, PHP will be faster than Perl even w/o these two. I don't agree that Web apps are just made of small snippets like this. In Web apps - database performance, output handling and caching play a big role, which these code snippets don't measure. FWIW, I agree with you that 'code in C if you need performance' is quite a pointless statement, except for very specialized cases. One of the main points in using PHP is *not* using C, because of dev-time, maintenance, reliability, etc. etc. Zeev -- 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]
Re: [PHP-DEV] Re: Shootout
Mike, I would suggest you look at the totally bogus mindcraft benchmarks of linux/apache. Those were orders of magnitude more bogus than anything here, yet ended up being useful. Further, many posters seem to confuse a discussion of PHP's performance with a dicusion of its quality as a language overall. That is a mistake. People need to realize that these benchmarks test one narrow aspect of PHP, and are not a ranking of its quality as a language. There is an important difference there. Mike Robinson: The benchmark code is pre-alpha and incomplete as the author states expressly. 'Useful' does not imply reliable, factual, or scientific. In my view, what I've seen and read is neither useful, nor harbours any of the other qualities, mentioned above, that reasonable people might consider important. IMHO, the benchmarks are bogus from the get go, and this discussion is moot.the benchmarks are bogus from the get go, and this discussion is moot. I have yet to see anything approching the care and completness of this guys benchmarks, pre-alpha and bogus or not with respect to PHP vis a vis other languages. In contrast to plenty of others they are open about their flaws, fully describe methadology and allow others to repeat them. Frankly, they seem to do a good job of testing what they set out to test, nested loops, array indexing and so on. aka they are as reliable, factual, and scientific as anything else I have seen put out. The open source community loves to critize, but I see few of these theoretical real world benchmarks floating around. I'm frankly surprised at some of the strong reactions to these benchmarks... think I'm going to get back to work :) - 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]
Re: [PHP-DEV] Re: Shootout
- Original Message - From: Zeev Suraski [EMAIL PROTECTED] If you use caching software, chances are PHP will be faster than Perl even without the optimizer. Interestingly, Perl is getting bytecode caching soon, RFC 301 I think. Probably about time. And it does that without any hassle or special planning, unlike Perl for that matter. If you use the optimizer - it gets as quick as Perl, and that's without caching. Couple the two together - and you have a serious performance screamer. Yes, we have succesfully used PHP on a site getting 6 million hits a day. Granted we wished we could have used fewer servers, but with caching and proper design things can go pretty high. Performance wise I'd bet that 60%+ of folks are not getting even some of the obvious huge performance wins (static compile, cache + optimizer, reverse proxy in front if lots of slow connections, proper configuration and on and on and on). That said, in most real world situations, PHP will be faster than Perl even w/o these two. I don't agree that Web apps are just made of small snippets like this. In Web apps - database performance, output handling and caching play a big role, which these code snippets don't measure. Couldn't agree more. But of course if one language in a similar space can get blazing speed in a little code snippet it's always nice to see if something can be tweaked to improve things in your favorite language. FWIW, I agree with you that 'code in C if you need performance' is quite a pointless statement, except for very specialized cases. One of the main points in using PHP is *not* using C, because of dev-time, maintenance, reliability, etc. etc. Yes, dev time, good docs, maintenence, reliabity outweigh performance concerns 90% of the time, and hardware is only getting cheaper. PHP's biggest wins are in some of those areas. What gets people riled up about these benchmarks is they see them as a whole picture slam against their favorite language, even if the benchmark is pretty clear about testing something pretty narrow which I think these are, they are remarkably honest for a benchmark. - 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]
Re: [PHP-DEV] Re: Shootout
At 04:07 30/12/2001, August Zajonc wrote: - Original Message - From: Zeev Suraski [EMAIL PROTECTED] If you use caching software, chances are PHP will be faster than Perl even without the optimizer. Interestingly, Perl is getting bytecode caching soon, RFC 301 I think. Probably about time. That RFC is from over a year ago, what makes you think it's going to happen soon..? It still remains to be seen if they do it in a nice, clean transparent way, or the Perl way :) Anyway, the other problems plaguing Perl still apply (having to worry about resourcesmemory). What gets people riled up about these benchmarks is they see them as a whole picture slam against their favorite language, even if the benchmark is pretty clear about testing something pretty narrow which I think these are, they are remarkably honest for a benchmark. Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. Zeev -- 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]
Re: [PHP-DEV] Re: Shootout
- Original Message - From: Sterling Hughes [EMAIL PROTECTED] Manuel, (I get all the trolls confused, one name makes it easier) These trolls happen to use PHP on a daily basis, and have for years. Always good to see the name calling start early :) Thanks! I wasn't aware of how they work, this clears everything up... Read: The Zend *Optimizer* and the Zend or APC Cache. When the scripts get larger this *does* help, especially when dealing with many requests. I was simply pointing out that the cache is unlikely to improve these benchmarks. The loading/interpretation step is short relative to a long benchmark run and this guy running them actually worked to factor out the startup time. This is not 1000 web requests where the cache makes a night and day difference, but a single request with a very long running time. The fact is benchmarking is hard, and really stupid trivial can be useful. No -- they can't. This is the whole point, benchmarks must be specific and must be applied to your current application/architecture/task. The fact is, the things this code is benchmarking are not only subject to the implementation of one person, but they are also so limited in scope, function, quality (of code), that they are flat out misleading. It seems to me that these small benchmarks are more specific then your full app benchmark. They are LESS subject to personal implementation difference since they are so simple. And I don't see where they are that misleading, they test what they say (array indexing) and are CLEAR about the limits of their scope and function, and I'm assuming folks on -dev realize that web apps are not long running highly nested for() loops. 2) He's not using the Zend Optimizer Propriatery product, not part of php default distro So? Anybody worth their salt as a programmer would consider the Zend Optimizer if they needed to speed up their production website. Not if they can't afford the (old) Zend Accelerator pricing and it didn't have a trial option and are using a free alternative which is incompatabile with the Optimizer. Anyone in the real world also has to make budget decisions, and we compared the win from the optimizer with that of the cache for OUR applications and made a decision. Does that mean I and others are not worth are salt as programmers? Hardly, that is rediculously narrow sighted. - 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]
Re: [PHP-DEV] Re: Shootout
- Original Message - From: Zeev Suraski [EMAIL PROTECTED] That RFC is from over a year ago, what makes you think it's going to happen soon..? It still remains to be seen if they do it in a nice, clean transparent way, or the Perl way :) Anyway, the other problems plaguing Perl still apply (having to worry about resourcesmemory). Since I dislike programming in perl I'm probably not the best to comment on the line noise... ^H^H code that perl generates. Nor the delay from their RFC's on bytecoding. Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. I agree. Was following up on an earlier post, had read through the benchmark carefully and he's got disclaimers everywhere, plus this is -dev, where one would imagine folks have a better grasp on the gap between performance benchmarking and the real world, much less language qualities as a whole... I've learned my lesson, this can suck up a good number of hours... - 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]
Re: [PHP-DEV] Re: Shootout
So? Anybody worth their salt as a programmer would consider the Zend Optimizer if they needed to speed up their production website. Not if they can't afford the (old) Zend Accelerator pricing and it didn't have a trial option and are using a free alternative which is incompatabile with the Optimizer. Another nasty-nasty about the optimizer is that it prevents any non-Zend zend_extensions from being loaded with it. The Zend Optimizer limits (my) options, not increases them, which I think what August is getting at. -- 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]
RE: [PHP-DEV] Re: Shootout
Zeev Suraski writes: Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. You betcha, wrong ideas I was about to activate the Omega-13. ;) Regards Mike Robinson -- 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]
RE: [PHP-DEV] Re: Shootout
I have to say that taking a look at his site again - he does have disclaimers. Even though none is as strong as 'This may have nothing to do with reality', it's not that bad... At 01:49 30/12/2001, Mike Robinson wrote: Zeev Suraski writes: Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. You betcha, wrong ideas I was about to activate the Omega-13. ;) Regards Mike Robinson -- 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]
Re: [PHP-DEV] Re: Shootout
Just to be clear I'll list a few for the record. He's got them there to avoid the flames and claims of unfair. - All artificial language performance benchmarks, mine included, *do not measure real-world performance*. One should not choose a language based only on its benchmark ranking, even if you believe the benchmark to be fair. In an ideal world, we would choose the language that makes us most productive, and which can be optimized fairly easily, when that optimization is needed. That means a good language will include a profiler tool to allow you to measure which parts of your application are slow, so you can rewrite those parts to be faster. Many scripting languages allow you to rewrite the slow parts in C, which should be just about all you need for speed. Of course, a badly designed application may be difficult to profile and speed up. But that's the fault of the programmer, not the language. And another - Some languages are not tested on their strengths, but mostly on their weaknesses. Case in point: PHP. PHP is a fine web scripting language that provides a multitude of built-in convenience functions to simplify writing code for common CGI tasks. Since this shootout is a basic language test, and I don't have or plan to have any CGI scripting tests, the fact that PHP is somewhat slower in my tests than other scripting languages is hardly an argument against its use as a web scripting language. - You should keep in mind that you may get significantly different results on a different platform. http://www.bagley.org/~doug/shootout/method.shtml#flaws for a long list, then read disclaimer then read faq I think and by then you'll have read more disclaimers then folks ranting here have thought of or had time to say. Hopefully this will avoid the Omega-13 :) - August - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: August Zajonc [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 3:51 PM Subject: RE: [PHP-DEV] Re: Shootout I have to say that taking a look at his site again - he does have disclaimers. Even though none is as strong as 'This may have nothing to do with reality', it's not that bad... At 01:49 30/12/2001, Mike Robinson wrote: Zeev Suraski writes: Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. You betcha, wrong ideas I was about to activate the Omega-13. ;) Regards Mike Robinson -- 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]
