# Design of the Zend Engine's Instruction Set
- Thread: https://externals.io/message/45269
- Original archive: https://news-web.php.net/php.internals/45269
- Started by Stefan Marr on 2009-08-13T12:42:26+00:00
- Messages: 22
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #45269 — Stefan Marr — 2009-08-13T12:42:26+00:00
URL: https://externals.io/message/45269#45269
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 stack-based interpreter for a fixed length
instruction set (76byte on a 32bit architecture),
where the instruction encoding
is much more complex then for instance for the
JVM, Python, or Smalltalk.
Even so, the source code is compiled to a linearized
instruction stream, the instruction itself contain not just opcode and
operands.
The version I looked at had some 136 opcodes encoded
in one byte, but the rest of the instruction has
many similarities with a AST representation.
Instructions encode:
- a line number
- a function pointer to the actual handler which is
used to execute it
- two operands, which encode constant values,
object references, jump addresses,
or pointer to other functions
- 64 bit for an extended operand value
- a field for results, which is use for some
operations return values.
However, its not a simple, single stack model,
but uses several purpose-specific stacks.
What I am not so sure about is especially the
semantics of the result field and the pointer
to the other function (op_array).
Would be grateful if someone could comment on that.
I am also not really sure with these complexity,
whether is not actually some kind of abstract syntax
tree instead of a instruction set like Java
bytecode. Thats not a technical problem, but merely
an academic question to categorize/characterize PHP.
All comments are welcome.
Many thanks
Stefan
--
Stefan Marr
Software Languages Lab
Former Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
Phone: +32 2 629 3956
Fax: +32 2 629 3525
---
## #45277 — Paul Biggar — 2009-08-15T09:29:34+00:00
URL: https://externals.io/message/45269#45277 · In reply to: #45269
Hi Stefan,
> 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 a presentation by Andy Wharmby at IBM:
www.zapt.info/PHPOpcodes_Sep2008.odp. It should answer a lot of your
questions.
> 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 stack-based interpreter for a fixed length
No, its a register based interpreter. There is a stack, but thats used
for calling functions only. The operands to the opcodes are pointed to
by the opcodes in the case of compiled variables, or in symbol tables
otherwise. That's as close to a register machine as we can get I
think, but its not very close to a stack machine. In a stack-based VM,
the operands to an opcode would be implicit, with add for example
using the top two stack operands, and thats not the case at all.
> instruction set (76byte on a 32bit architecture),
Andy's presentation says 96 bytes, but that might be 64 bit. I presume
this means sizeof(strict _zend_op)?
> where the instruction encoding
> is much more complex then for instance for the
> JVM, Python, or Smalltalk.
Yes, definitely.
> Even so, the source code is compiled to a linearized
> instruction stream, the instruction itself contain not just opcode and
> operands.
>
> The version I looked at had some 136 opcodes encoded
> in one byte, but the rest of the instruction has
> many similarities with a AST representation.
Are you referring to the IS_TMP_VAR type of a znode?
> Instructions encode:
> - a function pointer to the actual handler which is
> used to execute it
The type of interpreter dispatch used can be chosen at configure-time
using the --with-vm-kind flag. The call-based interpreter is the
default. I've heard the others are buggy, but I'm not certain where I
heard that.
> However, its not a simple, single stack model,
> but uses several purpose-specific stacks.
How so?
> What I am not so sure about is especially the
> semantics of the result field and the pointer
> to the other function (op_array).
>
> Would be grateful if someone could comment on that.
I'm not sure whats confusing about the result field? It points to a
zval, same as op1 and op2.
I _think_ that op_array is used to attach extra information to the
opcode by special extensions. I can't think of an example off the top
of my head.
> I am also not really sure with these complexity,
> whether is not actually some kind of abstract syntax
> tree instead of a instruction set like Java
> bytecode. Thats not a technical problem, but merely
> an academic question to categorize/characterize PHP.
I think the result field of a znode can make it seem like that, but I
would characterize it as you have before. An instruction set just like
Java bytecode. Way more complicated, obviously, but I dont think its
very close to an AST. Certainly the interpreter does not really
resemble an AST walker.
I hope I answered what you were looking for. I'm not certain about a
few of my answers, since I've really avoided the interpreter in my
work, but I think most of it is OK.
Best of luck,
Paul
--
Paul Biggar
paul.biggar@gmail.com
---
## #45278 — Stefan Marr — 2009-08-15T19:52:04+00:00
URL: https://externals.io/message/45269#45278 · In reply to: #45277
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.
> > […]
>
> No, its a register based interpreter. There is a stack, but thats used
> for calling functions only. The operands to the opcodes are pointed to
> by the opcodes in the case of compiled variables, or in symbol tables
> otherwise.
> That's as close to a register machine as we can get I
> think, but its not very close to a stack machine. In a stack-based VM,
> the operands to an opcode would be implicit, with add for example
> using the top two stack operands, and thats not the case at all.
The encoding of constants or addresses in symbol tables alone does not
disqualify it as a stack-based machine model per se.
However, since there seem to be no traditional instructions which rely
on
a stack, I agree that its not a stack machine.
struct _zend_execute_data makes it also look a bit like a stack,
especially
with its struct _zend_execute_data *prev_execute_data.
But knowing that union _temp_variable *Ts; is addressed directly,
it looks more lake a CISC-like register-memory model with an
"infinite" number
of registers.
> > […]
>
> Andy's presentation says 96 bytes, but that might be 64 bit. I presume
> this means sizeof(strict _zend_op)?
Yes, gives 76 byte on my OS X, but thats a detail which just illustrates
the significants of the different approaches. As an other example,
Self has a
real bytecode set. Each instruction is encoded in just 8bit, but
that encoding is not optimized for interpretation.
> > […]
>
> Are you referring to the IS_TMP_VAR type of a znode?
Actually, I was more concerned about the op_array,
and whether there is any place in the interpreter where it is used
directly, i.e., by using it in a C function call as an argument and
thus using the implicit C stack. If this would be used to initiate
interpretation of the op_array, I think it would resemble a
tree walker. But have not found anything hinting at that, especially
the global data structures do not support such a thing, from what I can
tell by reading the code.
I am just cautious, for instance the Lua implementation provides
some interesting mechanisms in this direction.
> > […]
>
> How so?
Ah, thanks, you are right, was looking at the wrong struct definition
(_zend_compiler_globals), indeed _zend_executor_globals defines only
an argument stack, an argument type stack, and struct
_zend_execute_data *current_execute_data (which also is a stack).
> > […]
>
> I'm not sure whats confusing about the result field? It points to a
> zval, same as op1 and op2.
Ah, well, ok, now I see how it is meant. In the assumption of a stack
model, it
does not make much sense, but in a register-memory model, it is just
specifying
the location for the result, sure.
> I _think_ that op_array is used to attach extra information to the
> opcode by special extensions. I can't think of an example off the top
> of my head.
Well, was a bit imprecise here, its part of _znode i.e. operands and
result,
but that does not pose any misunderstandings for me anymore.
> > […]
>
> I think the result field of a znode can make it seem like that, but I
> would characterize it as you have before. An instruction set just like
> Java bytecode. Way more complicated, obviously, but I dont think its
> very close to an AST. Certainly the interpreter does not really
> resemble an AST walker.
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 remind me of CISC
instruction
sets... 3-address form, register-memory model...
> I hope I answered what you were looking for. I'm not certain about a
> few of my answers, since I've really avoided the interpreter in my
> work, but I think most of it is OK.
Your answers were really helpful, guiding the code reading.
Thanks a lot
Stefan
---
## #45279 — Lothar Scholz — 2009-08-16T08:58:04+00:00
URL: https://externals.io/message/45269#45279
> > […]
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 discussion. I'm planning to start a new
book project in a few month were i analyse the implementation
of a few famous script language interpreters in great detail.
--
Best regards,
Lothar Scholz mailto:scholz@scriptolutions.com
---
## #45280 — Paul Biggar — 2009-08-16T16:24:53+00:00
URL: https://externals.io/message/45269#45280 · In reply to: #45278
Hi Stefan,
> 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 remind me of CISC
> instruction
> sets... 3-address form, register-memory model...
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 rearchitecture since the addition of a
bytecode based interpreter in PHP 4. I do not know how that was
designed though, maybe others do?
One thing I do find interesting is that the register machine nature of
PHP comes from an optimization called "compiled variables". CVs point
to symbol-table entries, but without them, I'm not sure whether we
would still call PHP a register machine. Any thoughts?
Thanks,
Paul
--
Paul Biggar
paul.biggar@gmail.com
---
## #45281 — Paul Biggar — 2009-08-16T16:33:30+00:00
URL: https://externals.io/message/45269#45281 · In reply to: #45279
>
> > […]
>
> 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.
Yes, by many times. Part of that might be the expense of PHP's weak
typing and references. They cause most operations to be more
expensive, even if they are not used in that particular operation.
I did a performance analysis of PHP in a paper I have in submission.
You might find it interesting (comment welcome):
https://www.cs.tcd.ie/~pbiggar/wip-sac-journal.pdf. There was a POPL
paper this year on Copy-on-write in PHP, which might be interesting to
you. There was also a PLDI paper on the performance effects of PHP's
memory allocator, which might also interest you.
Thanks,
Paul
--
Paul Biggar
paul.biggar@gmail.com
---
## #45282 — Sebastian Bergmann — 2009-08-16T17:38:59+00:00
URL: https://externals.io/message/45269#45282 · In reply to: #45281
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 Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
---
## #45283 — Lothar Scholz — 2009-08-16T17:53:51+00:00
URL: https://externals.io/message/45269#45283 · In reply to: #45281
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.
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.
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:scholz@scriptolutions.com
---
## #45284 — Lothar Scholz — 2009-08-16T17:56:35+00:00
URL: https://externals.io/message/45269#45284 · In reply to: #45282
Hello Sebastian,
Monday, August 17, 2009, 12:38:59 AM, you wrote:
SB> Paul Biggar schrieb:
> > […]
SB> http://doi.acm.org/10.1145/1480881.1480908
> > […]
SB> http://doi.acm.org/10.1145/1542476.1542520
Sounds interesting. Unfortunately i don't have a ACM account and
can't afford to open one just to read two articles.
Does anyone have a direct PDF link?
--
Best regards,
Lothar Scholz mailto:scholz@scriptolutions.com
---
## #45285 — Tom Boutell — 2009-08-16T18:16:48+00:00
URL: https://externals.io/message/45269#45285 · In reply to: #45283
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.
> 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.
>
>
> 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.
>
>
> 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:scholz@scriptolutions.com
>
>
> --
>
>
>
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
---
## #45286 — Stefan Marr — 2009-08-16T18:17:20+00:00
URL: https://externals.io/message/45269#45286 · In reply to: #45284
> Hello Sebastian,
>
> Monday, August 17, 2009, 12:38:59 AM, you wrote:
>
> SB> Paul Biggar schrieb:
> > […]
>
> SB> http://doi.acm.org/10.1145/1480881.1480908
http://www.trl.ibm.com/people/mich/pub/200901_popl2009phpsem.pdf
> > […]
>
> SB> http://doi.acm.org/10.1145/1542476.1542520
http://www.trl.ibm.com/people/inouehrs/pdf/PLDI2009_DDmalloc.pdf
>
> Sounds interesting. Unfortunately i don't have a ACM account and
> can't afford to open one just to read two articles.
>
> Does anyone have a direct PDF link?
Most authors do publish special author versions of the papers on their
webpages.
Googling for the title usually yields good results.
Best regards
Stefan
---
## #45287 — Stefan Marr — 2009-08-16T19:18:51+00:00
URL: https://externals.io/message/45269#45287 · In reply to: #45280
> 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 rearchitecture since the addition of a
> bytecode based interpreter in PHP 4.
Well, sure, but thats usual evolution. Not a problem specific to PHP.
Was more curious about the first design.
> One thing I do find interesting is that the register machine nature of
> PHP comes from an optimization called "compiled variables". CVs point
> to symbol-table entries, but without them, I'm not sure whether we
> would still call PHP a register machine. Any thoughts?
Well, actually, I would include the temp vars also as a reason to name
it a
register-memory machine model. They are accessed by using an explicit
name i.e. an index into the "Ts" array. Thus, it is definitely not an
implicit stack.
The question would be only, is it useful to go further and interpret
this structure
as an infinite number of registers which would be equivalent with
memory.
Then it could be considered to be a memory-to-memory architecture.
But usually these kind of architectures have the property of only one
type of
addresses, which does not hold for PHP.
Best regards
Stefan
---
## #45288 — Paul Biggar — 2009-08-16T21:04:57+00:00
URL: https://externals.io/message/45269#45288 · In reply to: #45285
Hi Tom,
> 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.biggar@gmail.com
---
## #45289 — Paul Biggar — 2009-08-16T21:25:06+00:00
URL: https://externals.io/message/45269#45289 · In reply to: #45283
Hi Lothar,
> 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.
>
> 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.biggar@gmail.com
---
## #45290 — Stanislav Malyshev — 2009-08-17T02:46:19+00:00
URL: https://externals.io/message/45269#45290 · In reply to: #45283
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!
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
---
## #45291 — Stanislav Malyshev — 2009-08-17T04:36:14+00:00
URL: https://externals.io/message/45269#45291 · In reply to: #45269
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.
> Instructions encode:
> - a line number
> - a function pointer to the actual handler which is
> used to execute it
> - two operands, which encode constant values,
> object references, jump addresses,
> or pointer to other functions
> - 64 bit for an extended operand value
> - a field for results, which is use for some
> operations return values.
The basic model is that each operation works on 2 operands and
(optionally) returns result. Operands can be either constants, temp
variables or in-memory variables, or sometimes a number which is used as
jump point, etc.
This model can be extended for some opcodes by using either extended
operand or additional opcode, if operation semantics does not fit in one
opcode (e.g. opcode generated by $a->b["x"] would have 4 operands - $a,
"b", "x" and how the expression is used - read/write/test, etc.)
> However, its not a simple, single stack model,
> but uses several purpose-specific stacks.
Stacks indeed are used for function calls, but this is just an
implementation detail.
> What I am not so sure about is especially the
> semantics of the result field and the pointer
> to the other function (op_array).
result field is a result of an operation, so if you have $a = $b + $c,
then ADD opcode which would add content of $b and $c would use "result"
field to store the value, which will then be used by ASSIGN opcode to
assign the result to $a.
As for op_array, I assume you are referring to op_array field in znode
union. I don't think this one is used by the engine at runtime, it's a
compiler utility field.
> I am also not really sure with these complexity,
> whether is not actually some kind of abstract syntax
> tree instead of a instruction set like Java
> bytecode. Thats not a technical problem, but merely
> an academic question to categorize/characterize PHP.
I think it's more like bytecode, indeed. Even though the instructions
are pretty high-level so with some effort you probably could build a
syntax tree out of it.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
---
## #45292 — Stanislav Malyshev — 2009-08-17T04:40:19+00:00
URL: https://externals.io/message/45269#45292 · In reply to: #45283
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 since it depends on training I'm not sure it would be the
same for all apps - that actually depends on what VC optimizes and if
it's generic enough.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
---
## #45293 — Sebastian Bergmann — 2009-08-17T05:07:18+00:00
URL: https://externals.io/message/45269#45293 · In reply to: #45283
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 Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
---
## #45306 — Richard Lynch — 2009-08-17T19:00:39+00:00
URL: https://externals.io/message/45269#45306 · In reply to: #45280
> Hi Stefan,
>
> On Sat, Aug 15, 2009 at 8:52 PM, Stefan Marr
> wrote:
> > […]
>
> I think they are pulled out of thin air.
At some point, it was asked what was the "original" of this model.
I'd have to hazard the guess that it was Ze'ev and Andi's model in PHP
3 and then re-worked (possibly completely) in PHP 4 that supplanted
Rasmus' hack-y version.
Considering they did it for a college project and had no intention of
it actually replacing the PHP engine at the time, it has held up
pretty well :-)
--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch
---
## #45327 — Basant Kukreja — 2009-08-21T17:03:38+00:00
URL: https://externals.io/message/45269#45327 · In reply to: #45285
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.
> 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 Scholz > […]
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
---
## #45328 — Basant Kukreja — 2009-08-21T17:06:36+00:00
URL: https://externals.io/message/45269#45328 · In reply to: #45289
>
> > […]
>
> 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.
---
## #45342 — jackywdx — 2009-08-24T05:04:20+00:00
URL: https://externals.io/message/45269#45342