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
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, should
On Sun, August 16, 2009 11:24 am, Paul Biggar wrote:
> Hi Stefan,
>
> On Sat, Aug 15, 2009 at 8:52 PM, Stefan Marr
> wrote:
>> Sometimes, it would be really interesting to know
>> where some of the used ideas are coming from
>> and what the reasoning was. I tend to think that its rather unlikely
>>
Lothar Scholz wrote:
> Hello Stanislav,
>
> Monday, August 17, 2009, 9:46:19 AM, you wrote:
>
> SM> Hi!
>
>>> A buggy implementation should solve as reference? Damn'd fucking
>>> college boys. This was an acceptable development method for PHP3.
>
> SM> So, you came to PHP developers list to cal
Pierre Joye wrote:
On Mon, Aug 17, 2009 at 7:40 AM, Lothar Scholz wrote:
Hello Stanislav,
Monday, August 17, 2009, 9:46:19 AM, you wrote:
SM> Hi!
A buggy implementation should solve as reference? Damn'd fucking
college boys. This was an acceptable development method for PHP3.
SM> So, you ca
On Mon, Aug 17, 2009 at 12:40:54PM +0700, Lothar Scholz wrote:
> Hello Stanislav,
>
> Monday, August 17, 2009, 9:46:19 AM, you wrote:
>
> SM> Hi!
>
> >> A buggy implementation should solve as reference? Damn'd fucking
> >> college boys. This was an acceptable development method for PHP3.
Langua
On Mon, Aug 17, 2009 at 7:40 AM, Lothar Scholz wrote:
> Hello Stanislav,
>
> Monday, August 17, 2009, 9:46:19 AM, you wrote:
>
> SM> Hi!
>
>>> A buggy implementation should solve as reference? Damn'd fucking
>>> college boys. This was an acceptable development method for PHP3.
>
> SM> So, you came
On Sun, Aug 16, 2009 at 10:40 PM, Lothar Scholz
wrote:
> If they are doing bad - yes i do. I have to say i give a fuck about
> volunteers - most of them should go to hell because most of them are
> worse to projects and they should/would go better without them and
> with a strict core team. If you
Lothar Scholz schrieb:
> Did you ever tried to compile the original PHP with different
> compilers, for example from intel or sun studio?
I tried ICC a couple of years ago, the results are at
http://sebastian-bergmann.de/archives/634-PHP-GCC-ICC-Benchmark.html
--
Sebastian Bergmann
Hi!
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
We tried it with Visual PGO and there's some small improvement (around
10% IIRC) but
Hi!
So, the basic design of the Zend Engine is a
a stack-based interpreter for a fixed length
instruction set (76byte on a 32bit architecture),
Not exactly stack-based, it's more register-based. Number of registers
is not limited, even though most of them aren't used simultaneously.
Instru
Hi!
A buggy implementation should solve as reference? Damn'd fucking
college boys. This was an acceptable development method for PHP3.
So, you came to PHP developers list to call people names and whine about
how the thing mostly done by volunteers and used by millions sucks? Good
job!
--
St
Hi Lothar,
On Sun, Aug 16, 2009 at 6:53 PM, Lothar Scholz 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
Hi Tom,
On Sun, Aug 16, 2009 at 7:16 PM, 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
I think they are pulled out of thin air. More specifically, I think
there are optimizations heaped upon optimizations heaped upon an
initial implementation. It seems that each new release of PHP has a
small speed improvement based on some optimization performed, but that
there has been no major re
On 16 Aug 2009, at 19:56, Lothar Scholz wrote:
Hello Sebastian,
Monday, August 17, 2009, 12:38:59 AM, you wrote:
SB> Paul Biggar schrieb:
There was a POPL paper this year on Copy-on-write in PHP
SB> http://doi.acm.org/10.1145/1480881.1480908
http://www.trl.ibm.com/people/mich/pub/200901_
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.cauc
Hello Sebastian,
Monday, August 17, 2009, 12:38:59 AM, you wrote:
SB> Paul Biggar schrieb:
>> There was a POPL paper this year on Copy-on-write in PHP
SB> http://doi.acm.org/10.1145/1480881.1480908
>> There was also a PLDI paper on the performance effects of PHP's
>> memory allocator
SB> htt
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
Paul Biggar schrieb:
> There was a POPL paper this year on Copy-on-write in PHP
http://doi.acm.org/10.1145/1480881.1480908
> There was also a PLDI paper on the performance effects of PHP's
> memory allocator
http://doi.acm.org/10.1145/1542476.1542520
--
Sebastian Bergmann
On Sun, Aug 16, 2009 at 9:58 AM, Lothar Scholz wrote:
>
where the instruction encoding
is much more complex then for instance for the
JVM, Python, or Smalltalk.
>
> PB>> Yes, definitely.
>
> And again we see that complexity is just that complex but not
> necessarily good. As all othe
Hi Stefan,
On Sat, Aug 15, 2009 at 8:52 PM, Stefan Marr wrote:
> Sometimes, it would be really interesting to know
> where some of the used ideas are coming from
> and what the reasoning was. I tend to think that its rather unlikely that
> they
> are pulled out of thin air. Some parts of the model
>>> where the instruction encoding
>>> is much more complex then for instance for the
>>> JVM, Python, or Smalltalk.
PB>> Yes, definitely.
And again we see that complexity is just that complex but not
necessarily good. As all others outperform PHP in all basic
operations.
But thanks for the dis
Hi Paul:
To start with, the best reference about the Zend engine that I know of
is a presentation by Andy Wharmby at IBM:
www.zapt.info/PHPOpcodes_Sep2008.odp. It should answer a lot of your
questions.
Thanks a lot, was not aware of that one. And, well it helps to read
and understand
the code
Hi Stefan,
On Thu, Aug 13, 2009 at 1:42 PM, Stefan Marr wrote:
> Hello internals:
>
> I had a look at the Zend Engine to understand some
> details about its internal design with respect
> to its opcodes and machine model.
To start with, the best reference about the Zend engine that I know of
is
Hello internals:
I had a look at the Zend Engine to understand some
details about its internal design with respect
to its opcodes and machine model.
Would like to ask you for some comments if the
following sounds wrong or misinterpreted to you:
So, the basic design of the Zend Engine is a
a st
26 matches
Mail list logo
