Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Hey Dmitry, I noticed today that ZO+ doesn't make use of sapi_get_stat()
to get the initial stat struct from the sapi if available. So, if you
have top-level a.php that includes b.php and c.php you end up with:
stat(/var/www/a.php, {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
stat(/var/www/a.php, {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
stat(/var/www/b.php, {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
stat(/var/www/c.php, {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
whereas with APC you have:
stat(/var/www/a.php, {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
stat(/var/www/b.php, {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
stat(/var/www/c.php, {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
That initial stat on a.php is done by Apache and because ZO doesn't grab
that existing stat struct from the sapi it has to re-stat the top-level
script.
Was this an intentional thing to leave out or just an oversight?
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/22/2013 07:57 PM, Rasmus Lerdorf wrote:
Hey Dmitry, I noticed today that ZO+ doesn't make use of sapi_get_stat()
to get the initial stat struct from the sapi if available. So, if you
have top-level a.php that includes b.php and c.php you end up with:
stat(/var/www/a.php, {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
stat(/var/www/a.php, {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
stat(/var/www/b.php, {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
stat(/var/www/c.php, {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
whereas with APC you have:
stat(/var/www/a.php, {st_mode=S_IFREG|0664, st_size=49, ...}) = 0
stat(/var/www/b.php, {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
stat(/var/www/c.php, {st_mode=S_IFREG|0664, st_size=10, ...}) = 0
That initial stat on a.php is done by Apache and because ZO doesn't grab
that existing stat struct from the sapi it has to re-stat the top-level
script.
Was this an intentional thing to leave out or just an oversight?
A very quick a lightly-tested implementation:
https://github.com/zend-dev/ZendOptimizerPlus/pull/40
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/16/2013 01:10 PM, Rasmus Lerdorf wrote: On 02/16/2013 11:16 AM, Zeev Suraski wrote: - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Interesting names, I'm curious about pronunciation :) I (mostly) pronounce cache the non-American way as kaysh. Cachze would be like that with a bit of Z sound. I don't think I would ever get neither the spelling nor the pronunciation of Cachze right. I like the much simpler opcache name. I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, opcache is best. Chris -Rasmus -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/18/2013 10:52 AM, Christopher Jones wrote: I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, opcache is best. In the so bad I can't resist sending it category is today's semi-humorous name suggestion: Cajun. It sounds roughly like the English pronunciation of caching Sadly it's not as nicely self-documenting as opcache. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Feb 18, 2013, at 23:03 , Christopher Jones christopher.jo...@oracle.com wrote: On 02/18/2013 10:52 AM, Christopher Jones wrote: I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, opcache is best. In the so bad I can't resist sending it category is today's semi-humorous name suggestion: Cajun. It sounds roughly like the English pronunciation of caching Sadly it's not as nicely self-documenting as opcache. opcache is fine, its better that it's self describing then exiting. not:to-be-taken-seriusly Cause then you don't have to google it to figure out what it is every time, like T_PAAMAYIM_NEKUDOTAYIM :P So if you really have to make a name for it, keep it self describing, like: OpsiCache Other then already being a used name, ops(i) is the word you would say in some languages when you realize you have done a mistake :) /not:to-be-taken-seriusly -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Zend Optimizer+ Source Code now available
-Original Message- From: Christopher Jones [mailto:christopher.jo...@oracle.com] Sent: Saturday, February 16, 2013 12:54 AM To: Zeev Suraski Cc: PHP internals Subject: RE: [PHP-DEV] Zend Optimizer+ Source Code now available Hi Zeev, I think people are keen to see Optimizer+ merged. Hopefully the RFC can set expectations clear on what the short-term steps will be, and what the bigger picture might look like. The middle-term tasks will then work themselves out as we get to them (in true PHP fashion) - What does Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for it mean? Does it mean: * Work really had to get it into PHP 5.5.0 with no delay to 5.5? * Include it in /ext as-is, i.e. perhaps no ZTS support, or marked EXPERIMENTAL? * Include it in PHP 5.5.x where x 0, when Optimizer+ is complete? The slippage of 5.5 is an issue to some people, so clarity here would be good. It's in the context of this, one paragraph above it: The question on the table is whether most users would prefer a slightly later release with an out-of-the-box working opcode cache, or a slightly earlier release without a compatible opcode cache available for several additional months. In other words, this option mean that if we can't integrate it without delaying 5.5.0, we don't integrate it. By integration I refer to including something that is production quality, potentially enabled-by-default (TBD), that everyone should feel comfortable using. I believe the wider community is expecting the op-code cache to just work, so if that's not the case, the RFC should communicate this clearly. There's also the potential to damage Zend's reputation if what is released doesn't work well. I agree, although an opcode cache does add an extra layer of complexity, so it does stand the chance to break otherwise working setups (the same can happen with other opcode caches). It should be a rare occurrence, with the performance advantage far outweighing it. - What are your general thoughts about its integration architecture and the potential for alternative op-code caches to be used? I know code can always be changed, but what (if any) design will happen from the start to make this easy? I'm not sure. The level of integration we're talking about for 5.5.0, due to the haste, is not going to be beyond a mostly soft-bundle, at most something that gets enabled by default - but can still be disabled or outright removed. That means that you should be able to replace it with any other opcode cache you might want. However, for the future, there *might* be potential for further gains we might be able to get from tighter integration between the different layers. At this point I don't have any concrete ideas, though, so it's possible it's only theoretical. Regardless, such tighter integration - that would preclude other opcode caches from being used - will have to be the subject of a separate RFC vote. I'll clarify that point too in the RFC. - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Interesting names, I'm curious about pronunciation :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/16/2013 11:16 AM, Zeev Suraski wrote: - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Interesting names, I'm curious about pronunciation :) I don't think I would ever get neither the spelling nor the pronunciation of Cachze right. I like the much simpler opcache name. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 15/02/13 01:59, Stas Malyshev wrote: (A) The op-code optimization should be integrated into the core compiler and enabled through a GC(compiler_option) to be available to *any* opcode cache -- or to the application designer (by exposing these options through an INI directive. Most optimizations would not give perceivable benefit unless the optimized code is run many times. So enabling it without opcode cache would not produce very big benefit. But yes, in theory these code parts can live separately and they don't actually need each other. My point here is that APC and the other opcode caches would also benefit from these optimizations; they really belong to the compiler and not to an opcode accelerator. Also yes, this type of optimisation usually has no net benefit unless #runs / compile is much greater than one, however there are scenarios (e.g. some nasty iteration intensive batch process) where taking the hit on optimisation still produces a net runtime saving. that support it). A Zend opcode cache belongs firmly in the Zend world and shouldn't be a PHP extension. I must say I don't understand this conclusion. Put simply PHP extensions should only reference the APIs exposed in the php headers. Zend has its own interface and extensions and since a Zend Opcode cache is SO intimately coupled with the Zend environment it makes sense to use a Zend extension to implement this. The whole idea of opcode caching just isn't relevant to a Hiphop environment or even for that matter a CLR or Java one since this do their own internal caching anyway. I also note some interesting difference in approaches between O+ and APC, say for example: 1) in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC patches the op handler and O+ does peephole opcode examination. Both these workarounds could be avoided by tidying up the scope of work in the instruction code. Could you explain this a bit more? As I posted in a separate not to this list, I've am developing my own LPC extension, a fork of APC optimized for CLI and GCI use. The dogma here is that there is no point in opcode caching because performance isn't a driver. Well my experience is that performance is always a driver For example, just because your application is running on a shared service where UID enforced security must be applied and therefore some form of scalable per-UID execution environment must be used doesn't mean that you don't care about performance. LPC still give a ~ 2x throughput improvement on MediaWiki for example. I forked and rewrote this cache extension because I couldn't stretch the APC code to do what I want in a performant manner without breaking it. It's a demonstrator to help me understand the real issues here and to get to grips with the minutiae of PHP caching technologies. I just don't see this ever getting to production, but I must admit that regressing some of this technologies onto O+ is an option that interests me because this does hold out the potential of a standard optimiser extension that supports all mainstream SAPIs. Now to ZEND_INCLUDE_OR_EVAL. My rationale here is that if the admin has specified a stat=0 (or equiv) option then this is a statement that the caches content and metadata can be trusted so there is no point in examining or reading source files. However, in the case of the xxx_once variants of this instruction, the ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() does path resolution and in the case of first load opens the source stream. Why? Why not just leave examination of the source stream to the compile function? LPC (like APC though for different reasons) has to rehook the ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLE() handler with a wrapper that does dynamic code modification to prevent this access occurring. O+ adopts a different strategy. LPC or APC having to walk through and essential patch over (private) static constant op_handler vectors is just plain horrible. No, IMO the Zend architecture should be designed to support caching; it should present a proper clean interface that extensions such as O+ and APC implement; and the entire PHP test suite should be capable of being executed with a cache extension in place and a good cache should not introduce any test failures. Sorry for the rant and I hope that I answered your Q :)
RE: [PHP-DEV] Zend Optimizer+ Source Code now available
-Original Message- From: Christopher Jones [mailto:christopher.jo...@oracle.com] Sent: Thursday, February 14, 2013 9:25 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available On 02/14/2013 07:21 AM, Zeev Suraski wrote: Great to see. The README covers much of the content (and in more detail) that I previously wanted to see in the RFC. Excellent! There are some things still missing from the RFC, though: - do you see Optimizer+ being enabled (if not in PECL) or disabled by default, etc. I *think* we should strive to have it enabled by default, but it should definitely be possible to turn it off too. I guess that can be another voting possibility - bundle turn on by default (vs. just bundle). To avoid too many voting choices, I think this can be decided outside the RFC process. That depends on whether there'll be apparent consensus about it; But it can wait until after that RFC is approved, as a separate discussion and if needed a separate vote. We don't want to create any special cases in O+; We would either take care of integrating it by having slightly patching our O+ build, or we'd add generalized facilities to O+ that will allow the loader to interact with it directly (that would not be unique to the Zend loader but could be used by any extension). From my point of view, it's nice-to-have to solve it before 5.5.0, not a must-have. This should still be stated in the RFC. (The PHP community suffers from poor RFCs. Since you are a leader in the PHP community, your RFC should set a good example.) I think it goes beyond of the scope of the RFC but I'll add a bit of blurb there. - There are still open questions in the RFC; these need to be closed before voting. I think the only open question is integration with other modules, most notably debuggers. This is something we'd like to tackle sooner rather than later, and I think it'll be easier to just go ahead and do that now that the source code is available. Any other open questions that need answering? I think this should be reworded before the vote occurs. I'm fine with leaving it under a heading for future investigation, i.e. stating it won't happen in an initial release. OK. Comments: - The README gives recommended parameters. Taking that advice at face value, I think these should be default settings. The default settings are designed to minimize the chance that an app or a workflow - which worked fine w/o O+ - will suddenly fail after O+ is installed. The 'recommended' settings are for max-performance. You can view it like 'Safe' vs. 'Extreme' settings. Personally I think the default settings should be closer to the Safe ones... We can probably meet in the middle: leave the hard coded defaults as they currently are, and use those values in the php.ini-development examples. Php.ini-production can have the values recommended in the README. (Giving the proposed php.ini settings is another thing the RFC should have...) I actually think that the differences between the 'safe' and 'extreme' settings don't correspond too well to development vs. production. They depend on the nature of the code/app you're running, and not on whether you're developing the code or running it in production. In my opinion, the defaults should be more or less the defaults we have today, perhaps with minor tweaks - but with the guiding principle being that they need to be *safe*, and minimize the chance that semantics would change if you enable/disable O+. The 'recommended' settings, which should really read 'extreme performance settings', should end up in a documentation section, with nice clear warnings about each and every setting and its potential impact on how apps will perform. I'll clarify that in the RFC. - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a O+ pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) It seems a good time to disambiguate its relationship to any current or future Zend product. Agreed. Rasmus and I ping ponged some names and we may want to go with something more generic along the lines of 'OpCache'. It's shorter than the zend_optimizerplus. prefix we currently have for INI directives
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Hi! Put simply PHP extensions should only reference the APIs exposed in the php headers. Zend has its own interface and extensions and since a Zend Opcode cache is SO intimately coupled with the Zend environment it makes sense to use a Zend extension to implement this. The whole idea of OK, I see. Well, the difference between Zend ext and PHP ext is not that big, it's mostly just loading order and couple of hooks, of which I think O+ really uses only op_array_handler, and this for optimization's benefit - so if you separate optimization, I think O+ can live as PHP extension, maybe. Not sure if it's worth the trouble though. Now to ZEND_INCLUDE_OR_EVAL. My rationale here is that if the admin has specified a stat=0 (or equiv) option then this is a statement that the caches content and metadata can be trusted so there is no point in examining or reading source files. However, in the case of the xxx_once variants of this instruction, the ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() does path resolution and in the case of first load opens the source stream. Why? Why not just I see what you mean. I can't think of a reason why they are combined now. Before realpath cache and separate path resolution functions that was the only way to handle paths properly - since path can be resolved differently by different streams, etc. I think giving a fresh look to this API and seeing if we can improve it for 5.6, etc. would probably be a good idea. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Zend Optimizer+ Source Code now available
Hi Zeev, I think people are keen to see Optimizer+ merged. Hopefully the RFC can set expectations clear on what the short-term steps will be, and what the bigger picture might look like. The middle-term tasks will then work themselves out as we get to them (in true PHP fashion) - What does Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for it mean? Does it mean: * Work really had to get it into PHP 5.5.0 with no delay to 5.5? * Include it in /ext as-is, i.e. perhaps no ZTS support, or marked EXPERIMENTAL? * Include it in PHP 5.5.x where x 0, when Optimizer+ is complete? The slippage of 5.5 is an issue to some people, so clarity here would be good. I believe the wider community is expecting the op-code cache to just work, so if that's not the case, the RFC should communicate this clearly. There's also the potential to damage Zend's reputation if what is released doesn't work well. - What are your general thoughts about its integration architecture and the potential for alternative op-code caches to be used? I know code can always be changed, but what (if any) design will happen from the start to make this easy? - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Zend Optimizer+ Source Code now available
Great to see. The README covers much of the content (and in more detail) that I previously wanted to see in the RFC. Excellent! There are some things still missing from the RFC, though: - do you see Optimizer+ being enabled (if not in PECL) or disabled by default, etc. I *think* we should strive to have it enabled by default, but it should definitely be possible to turn it off too. I guess that can be another voting possibility - bundle turn on by default (vs. just bundle). - your email comment to John Carter about Zend Guard decoder We don't want to create any special cases in O+; We would either take care of integrating it by having slightly patching our O+ build, or we'd add generalized facilities to O+ that will allow the loader to interact with it directly (that would not be unique to the Zend loader but could be used by any extension). From my point of view, it's nice-to-have to solve it before 5.5.0, not a must-have. - There are still open questions in the RFC; these need to be closed before voting. I think the only open question is integration with other modules, most notably debuggers. This is something we'd like to tackle sooner rather than later, and I think it'll be easier to just go ahead and do that now that the source code is available. Any other open questions that need answering? Comments: - The README gives recommended parameters. Taking that advice at face value, I think these should be default settings. The default settings are designed to minimize the chance that an app or a workflow - which worked fine w/o O+ - will suddenly fail after O+ is installed. The 'recommended' settings are for max-performance. You can view it like 'Safe' vs. 'Extreme' settings. Personally I think the default settings should be closer to the Safe ones... - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) Questions (I haven't dug through the code): - What do CLI processes share? IIRC nothing, presently it's not very useful for CLI except for testing (it'll only apply to a single run). I could be wrong though, Dmitry? - Is there an architectural reason why the 'embed' embedded SAPI couldn't be supported? (Lack of parent forking??) As long as we can map the shared memory piece to the same base address, there's no inherent reason why we couldn't make it work with SAPI/embed. That's how we work on Windows where there's no concept of fork(); We could apply a similar concept on Linux - although note that it's not 100% reliable, a base address that's free in one process may not be available in another... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 7:21 PM, Zeev Suraski z...@zend.com wrote: O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) Questions (I haven't dug through the code): - What do CLI processes share? IIRC nothing, presently it's not very useful for CLI except for testing (it'll only apply to a single run). I could be wrong though, Dmitry? Well, if it does block-level optimizations, that is already enough to make it useful for CLI-scripts, as even though caching is not relevant for long-running processes, optimizations should make things faster. Are optimizations documented? -- Alexey Zakhlestin, http://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. As far as I know there is no php_xdebug.dll yet for PHP 5.5. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski z...@zend.com wrote: - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) If this will go into PECL first then I see no reason to change the name from Optimizer+. If this will go into PHP then it shouldn't need a name at all, should it? It could just be opcode cache (--enable-opcode-cache / --disable-opcode-cache). That seems more descriptive to me then some fancy name like Optimizer+. Regarding the optimizations it contains, imho those are a separate concern and if Optimizer+ goes into core both aspects should be cleanly separated (and you should be able to enable/disable them separately). The optimizations are not directly related to caching. Caching makes them more viable for web requests, but as someone already pointed out the optimizations are also useful on CLI, where compile times just aren't a concern anyway (but run times can be). Btw, I was quite surprised to see the block optimizations in O+ :) Really cool! Nikita
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 9:02 AM, Nikita Popov nikita@gmail.com wrote: On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski z...@zend.com wrote: - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) If this will go into PECL first then I see no reason to change the name from Optimizer+. If this will go into PHP then it shouldn't need a name at all, should it? It could just be opcode cache (--enable-opcode-cache / --disable-opcode-cache). That seems more descriptive to me then some fancy name like Optimizer+. Regarding the optimizations it contains, imho those are a separate concern and if Optimizer+ goes into core both aspects should be cleanly separated (and you should be able to enable/disable them separately). The optimizations are not directly related to caching. Caching makes them more viable for web requests, but as someone already pointed out the optimizations are also useful on CLI, where compile times just aren't a concern anyway (but run times can be). I usually don't chime in with 'me too' comments, but I think Nikita summed it up nicely. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 10:55 AM, Jan Ehrhardt wrote: Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500): On 02/14/2013 10:55 AM, Jan Ehrhardt wrote: Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. Hmm. I was loading them the other way around, but did not encounter any interesting problems yet... Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 11:21 AM, Jan Ehrhardt wrote: Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500): On 02/14/2013 10:55 AM, Jan Ehrhardt wrote: Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. Hmm. I was loading them the other way around, but did not encounter any interesting problems yet... Most things work fine, but I hit a weird segfault in some complicated code which I fixed by flipping the order. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:32:55 -0500): Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. Most things work fine, but I hit a weird segfault in some complicated code which I fixed by flipping the order. Was that on Windows or on Linux? Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 5:32 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/14/2013 11:21 AM, Jan Ehrhardt wrote: Rasmus Lerdorf in php.internals (Thu, 14 Feb 2013 11:14:20 -0500): On 02/14/2013 10:55 AM, Jan Ehrhardt wrote: Zeev Suraski in php.internals (Thu, 14 Feb 2013 17:21:48 +0200): I think the only open question is integration with other modules, most notably debuggers. php_ZendOptimizerPlus.dll and php_xdebug.dll loaded both together in PHP 5.3 and PHP 5.4 (x86, TS and NTS). I do not know yet if there are any issues. Make sure you load ZO before xdebug and it seems to work ok. If you load xdebug first you will run into interesting problems. Hmm. I was loading them the other way around, but did not encounter any interesting problems yet... Most things work fine, but I hit a weird segfault in some complicated code which I fixed by flipping the order. Shouldn't we document that, or add some notice at extension loading by detecting Xdebug ? Julien.Pauli
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 08:02 AM, Nikita Popov wrote: On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski z...@zend.com mailto:z...@zend.com wrote: - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) If this will go into PECL first then I see no reason to change the name from Optimizer+. If this will go into PHP then it shouldn't need a name at all, should it? It could just be opcode cache (--enable-opcode-cache / --disable-opcode-cache). That seems more descriptive to me then some fancy name like Optimizer+. Regarding the optimizations it contains, imho those are a separate concern and if Optimizer+ goes into core both aspects should be cleanly separated (and you should be able to enable/disable them separately). The optimizations are not directly related to caching. Caching makes them more viable for web requests, but as someone already pointed out the optimizations are also useful on CLI, where compile times just aren't a concern anyway (but run times can be). This raises questions for Zeev to address. Btw, I was quite surprised to see the block optimizations in O+ :) Really cool! Nikita The php.ini parameters will likely need a name (or two - if the optimizer is distinct from the op-code cache) as a prefix. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Hi! Well, if it does block-level optimizations, that is already enough to make it useful for CLI-scripts, as even though caching is not relevant for long-running processes, optimizations should make things faster. For most scripts, optimizations are not really worth it unless you run the same code over and over, so for CLI it would be noticeable only if you run long-running CPU-intensive server. Are optimizations documented? Not yet AFAIK. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thursday 14 February 2013 10:24:22 Stas Malyshev wrote: For most scripts, optimizations are not really worth it unless you run the same code over and over, so for CLI it would be noticeable only if you run long-running CPU-intensive server. Apart from the long-running servers, there is also cronjobs. I have quite a number of them running on some of my servers, some of them once per minute, and they all share a certain number of classes between them. I imagine their startup and execution could profit a bit from an opcode cache. What keeps an opcode cache from using a persistent memory mapped file, maybe one per UID for security reasons, to cache opcodes from separate CLI invocations? best regards Patrick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 07:21 AM, Zeev Suraski wrote: Great to see. The README covers much of the content (and in more detail) that I previously wanted to see in the RFC. Excellent! There are some things still missing from the RFC, though: - do you see Optimizer+ being enabled (if not in PECL) or disabled by default, etc. I *think* we should strive to have it enabled by default, but it should definitely be possible to turn it off too. I guess that can be another voting possibility - bundle turn on by default (vs. just bundle). To avoid too many voting choices, I think this can be decided outside the RFC process. - your email comment to John Carter about Zend Guard decoder We don't want to create any special cases in O+; We would either take care of integrating it by having slightly patching our O+ build, or we'd add generalized facilities to O+ that will allow the loader to interact with it directly (that would not be unique to the Zend loader but could be used by any extension). From my point of view, it's nice-to-have to solve it before 5.5.0, not a must-have. This should still be stated in the RFC. (The PHP community suffers from poor RFCs. Since you are a leader in the PHP community, your RFC should set a good example.) - There are still open questions in the RFC; these need to be closed before voting. I think the only open question is integration with other modules, most notably debuggers. This is something we'd like to tackle sooner rather than later, and I think it'll be easier to just go ahead and do that now that the source code is available. Any other open questions that need answering? I think this should be reworded before the vote occurs. I'm fine with leaving it under a heading for future investigation, i.e. stating it won't happen in an initial release. Comments: - The README gives recommended parameters. Taking that advice at face value, I think these should be default settings. The default settings are designed to minimize the chance that an app or a workflow - which worked fine w/o O+ - will suddenly fail after O+ is installed. The 'recommended' settings are for max-performance. You can view it like 'Safe' vs. 'Extreme' settings. Personally I think the default settings should be closer to the Safe ones... We can probably meet in the middle: leave the hard coded defaults as they currently are, and use those values in the php.ini-development examples. Php.ini-production can have the values recommended in the README. (Giving the proposed php.ini settings is another thing the RFC should have...) - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) It seems a good time to disambiguate its relationship to any current or future Zend product. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 14/02/13 18:24, Stas Malyshev wrote: Are optimizations documented? Not yet AFAIK. No, but they are pretty self-explanatory. O+ is a _Zend_ extension rather than a _PHP_ extension and this enables it to exploit extra hooks (see the tail of ZendAccelerator.c) and specifically follow through accel_op_array_handler() and the routines in the Optimizer subdirectory. Essentially this hook is invoked as an epilogue to the generating of any op_array. What this does is a number of peephole optimizisations to simplify and NOP out instruction sequences, and the last pass compresses the code removing dead NOPs to shrink the op_array -- this is typical of the sorts of things that the optimization passes of a compiler would do. And this is a segue into one architectural issue the immediately struck me on scanning the code: surely there is a natural domain separation between compilation, image startup/rundown, and execution. (i) is optimally done once per S/W version, (ii) per request, (iii) per instruction executed. Surely O+ is currently a hybrid of (i) and (ii) and whilst this might have occurred for understandable historical reasons, I question this rationale going forward. (A) The op-code optimization should be integrated into the core compiler and enabled through a GC(compiler_option) to be available to *any* opcode cache -- or to the application designer (by exposing these options through an INI directive. (B) The O+ opcode cache itself is logically quite separate. It makes great sense to keep ithis as a Zend extension (given the desire from some of the dev team to maintain a clear logical separation between the upper PHP environment and the Zend, Hippop, ... execution environments that support it). A Zend opcode cache belongs firmly in the Zend world and shouldn't be a PHP extension. I also note some interesting difference in approaches between O+ and APC, say for example: 1) in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC patches the op handler and O+ does peephole opcode examination. Both these workarounds could be avoided by tidying up the scope of work in the instruction code. 2) in the treatment of early binding class inheritence: APC include some reasonably complex logic to back this out; O+ sets a compiler option to disable this inheritance occurring in the first place, an approach that APC might want to copy.
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Hi! (A) The op-code optimization should be integrated into the core compiler and enabled through a GC(compiler_option) to be available to *any* opcode cache -- or to the application designer (by exposing these options through an INI directive. Most optimizations would not give perceivable benefit unless the optimized code is run many times. So enabling it without opcode cache would not produce very big benefit. But yes, in theory these code parts can live separately and they don't actually need each other. that support it). A Zend opcode cache belongs firmly in the Zend world and shouldn't be a PHP extension. I must say I don't understand this conclusion. I also note some interesting difference in approaches between O+ and APC, say for example: 1) in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC patches the op handler and O+ does peephole opcode examination. Both these workarounds could be avoided by tidying up the scope of work in the instruction code. Could you explain this a bit more? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
That's a good idea :) I'm also in On 13 February 2013 09:51, Zeev Suraski z...@zend.com wrote: As per Derick’s idea, we can arrange a webinar for those interested in better understanding how it works.
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Wed, Feb 13, 2013 at 9:51 AM, Zeev Suraski z...@zend.com wrote: As per Derick’s idea, we can arrange a webinar for those interested in better understanding how it works. Note that this will not be a webinar for the faint of heart – opcode caches are complicated pieces of software; Attendees should have very good engine-development knowledge to have a good chance of understanding what’s going on… Stas – your help in that webinar would be very welcome J I'm interested in attending the webinar, as well, Zeev. Any general idea when it would be (e.g. - next week, March, sometime during the summer)? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Le 13/02/2013 15:51, Zeev Suraski a écrit : https://github.com/zend-dev/ZendOptimizerPlus/ Great News ! Do you know if any control panel (like the one provided with APC) already exists ? I notice accelerator_reset, accelerator_get_configuration and accelerator_get_status functions, so should be possible. Regards, Remi. P.S. RPM already available in my repo for Fedora / RHEL / CentOS users of php 5.4 and Fedora users of php 5.5. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Hi, I tried to install the ZendOptimizer+ provided earlier today but wasn't able to make it work. I compiled it with success but when I looked at the phpinfo(); I had this : Opcode Caching Disabled Optimization Enabled Startup Failed no value I'm using the apache2handler (MPM Worker - multi-threaded), PHP Version 5.4.13-dev. Here's my configure : './configure' '--enable-debug' '--enable-bcmath' '--enable-calendar' '--enable-gd-native-ttf' '--enable-maintainer-zts' '--enable-mbstring' '--enable-soap' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-zip' '--with-apxs2=/usr/bin/apxs2' '--with-config-file-path=/etc/php5/PHP-5.4' '--with-config-file-scan-dir=/etc/php5/PHP-5.4/conf.d' '--with-curl' '--with-freetype-dir=/usr/lib' '--with-gd' '--with-jpeg-dir' '--with-kerberos' '--with-mcrypt' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-openssl' '--with-pdo-mysql=mysqlnd' '--with-png-dir' '--with-readline' '--with-xsl' '--with-zlib-dir' I only added the zend_extension line in my php.ini file. I tried to look at the log but did not found anything that could explain why the Startup Failed. I looked a little bit at the code and the accel_startup worked as expected at the apache start and ZCG(startup_ok) was equal to 1 at the end of it. I'm suspecting that my problem is related to the fact that I'm using a multi-threaded environment. Could it be because the startup_ok variable is in the zend_accel_globals structure and not in the zend_accel_shared_globals ? And that a new zend_accel_globals is created for my request where the startup_ok is not 1 ? If you have any idea of anything I could have done wrong please let me know. Also if you need more informations just ask and I'll try to provide them to you. Thanks for the help ! Pierrick On 13 February 2013 09:51, Zeev Suraski z...@zend.com wrote: For your browsing pleasure: https://github.com/zend-dev/ZendOptimizerPlus/ An initial README with some instructions is available at http://bit.ly/VSs5KC We’ve put it under the PHP license, with the same PHP Group copyright header as all files in PHP. As per Derick’s idea, we can arrange a webinar for those interested in better understanding how it works. Note that this will not be a webinar for the faint of heart – opcode caches are complicated pieces of software; Attendees should have very good engine-development knowledge to have a good chance of understanding what’s going on… Stas – your help in that webinar would be very welcome J Zeev
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
hi, On Wed, Feb 13, 2013 at 3:51 PM, Zeev Suraski z...@zend.com wrote: For those willing to play with it on Windows, here are the bins for 5.5/VC11 https://twitter.com/PierreJoye/status/301946818835652608 5.3/5.4/5.5 VC9 are coming. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
Hi Pierrick, We didn't use ZTS in Zend commercial products, so it wasn't tested for a long time. O+ may definitely have some ZTS related problems. Please, report an issue at https://github.com/zend-dev/ZendOptimizerPlus/issues I'll look into it later Thanks. Dmitry. On Thu, Feb 14, 2013 at 1:42 AM, Pierrick Charron pierr...@webstart.frwrote: Hi, I tried to install the ZendOptimizer+ provided earlier today but wasn't able to make it work. I compiled it with success but when I looked at the phpinfo(); I had this : Opcode Caching Disabled Optimization Enabled Startup Failed no value I'm using the apache2handler (MPM Worker - multi-threaded), PHP Version 5.4.13-dev. Here's my configure : './configure' '--enable-debug' '--enable-bcmath' '--enable-calendar' '--enable-gd-native-ttf' '--enable-maintainer-zts' '--enable-mbstring' '--enable-soap' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-zip' '--with-apxs2=/usr/bin/apxs2' '--with-config-file-path=/etc/php5/PHP-5.4' '--with-config-file-scan-dir=/etc/php5/PHP-5.4/conf.d' '--with-curl' '--with-freetype-dir=/usr/lib' '--with-gd' '--with-jpeg-dir' '--with-kerberos' '--with-mcrypt' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-openssl' '--with-pdo-mysql=mysqlnd' '--with-png-dir' '--with-readline' '--with-xsl' '--with-zlib-dir' I only added the zend_extension line in my php.ini file. I tried to look at the log but did not found anything that could explain why the Startup Failed. I looked a little bit at the code and the accel_startup worked as expected at the apache start and ZCG(startup_ok) was equal to 1 at the end of it. I'm suspecting that my problem is related to the fact that I'm using a multi-threaded environment. Could it be because the startup_ok variable is in the zend_accel_globals structure and not in the zend_accel_shared_globals ? And that a new zend_accel_globals is created for my request where the startup_ok is not 1 ? If you have any idea of anything I could have done wrong please let me know. Also if you need more informations just ask and I'll try to provide them to you. Thanks for the help ! Pierrick On 13 February 2013 09:51, Zeev Suraski z...@zend.com wrote: For your browsing pleasure: https://github.com/zend-dev/ZendOptimizerPlus/ An initial README with some instructions is available at http://bit.ly/VSs5KC We’ve put it under the PHP license, with the same PHP Group copyright header as all files in PHP. As per Derick’s idea, we can arrange a webinar for those interested in better understanding how it works. Note that this will not be a webinar for the faint of heart – opcode caches are complicated pieces of software; Attendees should have very good engine-development knowledge to have a good chance of understanding what’s going on… Stas – your help in that webinar would be very welcome J Zeev
