Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
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, 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 Scholzsch...@scriptolutions.com wrote: 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. Strong Language Warning 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. /Strong Language Warning 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 Scholzmailto:sch...@scriptolutions.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 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. 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP-DEV] Design of the Zend Engine's Instruction Set
On Sun, Aug 16, 2009 at 10:40 PM, Lothar Scholz sch...@scriptolutions.comwrote: 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 base a project only on volunteers its just digital environment pollution - and you should be punished for putting it out. Congratulations on destroying your career. *nix was built by volunteers. email was built by volunteers. gopherspace was built by volunteers. The web (http sites, which really took off) was built by volunteers. ..and you have just given the finger to everybody who built it. Good luck!
Re: Re[2]: [PHP-DEV] Design of the Zend Engine's Instruction Set
On Mon, Aug 17, 2009 at 7:40 AM, Lothar Scholzsch...@scriptolutions.com 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 call people names and whine about SM how the thing mostly done by volunteers and used by millions sucks? 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 base a project only on volunteers its just digital environment pollution - and you should be punished for putting it out. I would suggest to fix your language too. You may also read about open source software developments, how it works, where it came from, etc. It could help you to do not pollute our list with pointless (and respectless) mails. Thanks. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
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. Language like that is really going to get your comments listened to -- not! SM So, you came to PHP developers list to call people names and whine about SM how the thing mostly done by volunteers and used by millions sucks? 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 base a project only on volunteers its just digital environment pollution - and you should be punished for putting it out. If your company is not able to finance a solid - even pretty small team - of a skilled persons who work on the core it's a huge problem for PHP. If you don't like it you can: a) either walk away from PHP go to use Java/.Net/... b) try to fix the problems. 1) work with the existing PHP team, fix what you see as issues 2) fork the project, attract a bunch of good developers on the basis of the strength of your ideas and your charisma Yes: PHP has got problems, but it does seem to have much more that is right than is wrong. PHP documentation is good when compared to many FLOSS projects; I do agree that some parts of the language description/definition are a bit fuzzy. The language has inconsistencies: everyone agrees that, but it has evolved into something that Rasmus would not have believed when he first started. Oh: which of the actions above is more likely to produce good results for everyone: b1. Well i'm not a fan of all this free open source as it shows that it is a total enemy against progress in the IT and slows down development enourmously I don't have a problem in you believing that. Now: off you go and pay all your MS license fees and marvel as to how secure it is and how quickly and openly they address bugs. We will still accept you back when you become disillusioned. Regards -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Past chairman of UKUUG: http://www.ukuug.org/ #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
Pierre Joye wrote: On Mon, Aug 17, 2009 at 7:40 AM, Lothar Scholzsch...@scriptolutions.com 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 call people names and whine about SM how the thing mostly done by volunteers and used by millions sucks? 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 base a project only on volunteers its just digital environment pollution - and you should be punished for putting it out. I would suggest to fix your language too. You may also read about open source software developments, how it works, where it came from, etc. It could help you to do not pollute our list with pointless (and respectless) mails. Something that we can agree on Pierre! I much prefer working with 'volunteers' that '9to5 clock watchers' ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 call people names and whine about SM how the thing mostly done by volunteers and used by millions sucks? If they are doing bad - yes i do. I have to say i give a fuck about volunteers trolldon't feed it -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
On Sun, August 16, 2009 11:24 am, Paul Biggar wrote: Hi Stefan, On Sat, Aug 15, 2009 at 8:52 PM, Stefan Marrp...@stefan-marr.de 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 remind me of CISC instruction sets... 3-address form, register-memory model... 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[3]: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 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 Scholzmailto:sch...@scriptolutions.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
Hi Stefan, On Sat, Aug 15, 2009 at 8:52 PM, Stefan Marrp...@stefan-marr.de 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 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.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[3]: [PHP-DEV] Design of the Zend Engine's Instruction Set
On Sun, Aug 16, 2009 at 9:58 AM, Lothar Scholzsch...@scriptolutions.com 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 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.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
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. Strong Language Warning 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. /Strong Language Warning 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 Scholzmailto:sch...@scriptolutions.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 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 Scholzmailto:sch...@scriptolutions.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 Scholzsch...@scriptolutions.com wrote: 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. Strong Language Warning 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. /Strong Language Warning 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:sch...@scriptolutions.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP-DEV] Design of the Zend Engine's Instruction Set
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_popl2009phpsem.pdf There was also a PLDI paper on the performance effects of PHP's memory allocator 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
Hi Tom, On Sun, Aug 16, 2009 at 7:16 PM, Tom Boutellt...@punkave.com 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 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.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[5]: [PHP-DEV] Design of the Zend Engine's Instruction Set
Hi Lothar, On Sun, Aug 16, 2009 at 6:53 PM, Lothar Scholzsch...@scriptolutions.com 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 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. Strong Language Warning 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.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
Hi Stefan, On Thu, Aug 13, 2009 at 1:42 PM, Stefan Marrp...@stefan-marr.de 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 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.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Design of the Zend Engine's Instruction Set
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. 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. 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. 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)? 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. the rest of the instruction has many similarities with a AST representation. 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. However, its not a simple, single stack model, but uses several purpose-specific stacks. 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). 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. 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 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Design of the Zend Engine's Instruction Set
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
