efully 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
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 o
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 activa
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
> incom
- 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
> P
- 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
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.
>Pro
- 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 h
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
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 th
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 ha
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
- 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
> p
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 somethin
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 plat
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
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 pla
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
For that particular case, btw, you should try adding in the Zend
Optimizer. For this type of somewhat braindead code (no insult intended,
it's just not very real-world), it would give you a very serious
performance boost.
Zeev
On Sat, 29 Dec 2001, August Zajonc wrote:
> > This is not real
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/
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
> 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 m
> 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 m
> 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 m
24 matches
Mail list logo
