Re: [PHP-DEV] Re: About optimization for compiler
On Mon, Mar 2, 2015 at 9:47 PM, Anthony Ferrara ircmax...@gmail.com wrote: Julien, Bob's code optimizes things by adding a new OPCode. This is different from compiler optimizations. Compiler optimizations are about changing native, supported OPCode structures to other native supported OPCode structure, but that will run faster at runtime. I agree with dmitry that if we separate the optimizer from the OPCode cache (both in OPCache actually), then the one who will use the optimizer but not the cache, will suffer from a drop in performance. This is silly and should be prevented. We should keep both the optimizer and the cache together IMO, or, we should forbid the optimizer to fire up if no OPCode cache is done after (as the optimizer will eat some performances for nothing). I disagree. All compilation happens interactively (meaning during a request), we can't afford REALLY complex optimizations (a request taking 5 minutes would be out of the question) even if we had an opcode cache. Therefore the optimizations that we include can't be THAT expensive anyway. Yes, it may double or quadruple compilation time. But we're talking 10's of milliseconds, not minutes. And at that point, why should a CLI script like Composer be forbidden to benefit from those optimizations? Yes, it make take slightly longer to compile the script, but the potential benefit of the optimizations could outweigh any additional compilation cost. Makes sense, as soon as the documentation reflects that. Someone seeing a setting called optimization something may think about enabling it, and it will speed up his code. Which is not always true, depending on script usage. We discussed some time ago to merge OPCache into PHPCore (back to PHP 5.5 dev) I'm all +1 with that, and for doing that for PHP7.0 When PHP 7.0 will be released, we will not support any new feature in OPCache for PHP5 branches anyway. As OPCache is nowadays not compatible at all with PHP7 (development has not started yet, or I'm not aware of it) , why not merge OPCache to PHP7 source tree (when the time for this will come), still as an extension at first time, and keep developing optimizer passes into this (aka : not in Zend/) ? I'm also +1 to keep our optimizations into OPCache (into an extension), and allow them to be disabled (like its the case actually), because this subject is very hot and sensible. We should keep a PHP compiler as-is, and move optimization passes away from it. zend_extension_op_array_handler() callback is designed for that purpose. -1 I think that the optimizations should be separated out. Have them go into a separate extension. Then merge opcache into the engine. I don't mean copy it, but actually implement it internally. Right now, there's a fair bit of duplication and abstraction in the engine just to enable opcache. A great example is that there are two separate string interning systems that only share a common API between Zend and OpCache. There are other areas of opcache where datastructures are duplicated (or more precisely, information about them is duplicated). So if we merge in the cache to the engine, we can make a far more streamlined and cohesive compiler. Then, the optimizations can be enabled by another extension (or perhaps multiple). We can even make the optimizations pluggable to enable other block-level passes to occur (in CFG form, as block_pass.c uses) rather than require every extension re-implement a lot of logic... Overall, I'd prefer to keep the optimizations separate in one or more clear extensions rather than deeply integrated with temporally-related code. Then the extensions can decide whether to optimize or not (based on ini setting perhaps, based on SAPI, cache setting, etc). Besides, there are more places to optimize than just the oparray (for example, you can do some optimizations on top of the AST). So having one place for all of them to go will simply get unwieldy over time. Yep I see, that makes sense too. This would effectively prevent some code duplications that exists in OPCache, the string interning example is nice of course. Also, you are right saying that now in PHP7 we have an AST, which could considerably ease the optimizations as well. So one extension (or more) for optimizations, and a merge of OPCache into PHP7. I think I can lead that in the next few months, that will be a nice way for me to finally play with ZendEngine 3 ;-) Julien.P
Re: [PHP-DEV] Re: About optimization for compiler
Zeev, I agree with that as well, just Anthony gave a different opinion which seems right as well. I think that if we ever have optimization passes that are prohibitively expensive to run interactively (most probably around JIT) we'll definitely need new strategies for them. But as long as we're talking about relatively optimization passes that take milliseconds to run and not minutes, I think this approach holds true. How is a JIT prohibitively expensive to run interactively? Or was that not your implication? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: About optimization for compiler
-Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Tuesday, March 03, 2015 5:50 PM To: Zeev Suraski Cc: Julien Pauli; PHP internals Subject: Re: [PHP-DEV] Re: About optimization for compiler Zeev, I agree with that as well, just Anthony gave a different opinion which seems right as well. I think that if we ever have optimization passes that are prohibitively expensive to run interactively (most probably around JIT) we'll definitely need new strategies for them. But as long as we're talking about relatively optimization passes that take milliseconds to run and not minutes, I think this approach holds true. How is a JIT prohibitively expensive to run interactively? Or was that not your implication? It wasn't - the implication is that out of all the optimizations the exist in the world, it's likely that if we ever have ones that are prohibitively expensive to run interactive - they'd most probably be around JIT or other types of native compilation strategies. What you said is the reverse - that JIT optimizations are inherently prohibitively expensive to run interactively, which we obviously all agree on isn't the case and not what I meant. X - Y doesn't mean Y - X... Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: About optimization for compiler
-Original Message- From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of Julien Pauli Sent: Monday, March 02, 2015 9:07 PM To: Dmitry Stogov Cc: Bob Weinand; Xinchen Hui; PHP Internals Subject: Re: [PHP-DEV] Re: About optimization for compiler As OPCache is nowadays not compatible at all with PHP7 (development has not started yet, or I'm not aware of it) , why not merge OPCache to PHP7 source tree (when the time for this will come), still as an extension at first time, and keep developing optimizer passes into this (aka : not in Zend/) ? It's a bit OT, but can you explain what you mean here? OPcache works with the current master (PHP 7), and actually, OPcache worked with phpng all along and definitely since it was merged into master... It's been integrated to the php-src tree since it became standard in 5.5. Do you mean the standalone github repos for older versions? I'm also +1 to keep our optimizations into OPCache (into an extension), I'm slightly confused - you mean keep it in (or move optimization over to) the OPcache extension, or move it into its own extension? If it's the former, then I agree. Optimization passes and opcode caching are very much linked, as performing optimizations without having an opcode cache rarely makes sense. and allow them to be disabled (like its the case actually), because this subject is very hot and sensible. We should keep a PHP compiler as-is, and move optimization passes away from it. zend_extension_op_array_handler() callback is designed for that purpose. Agreed. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: About optimization for compiler
On Tue, Mar 3, 2015 at 2:52 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of Julien Pauli Sent: Monday, March 02, 2015 9:07 PM To: Dmitry Stogov Cc: Bob Weinand; Xinchen Hui; PHP Internals Subject: Re: [PHP-DEV] Re: About optimization for compiler As OPCache is nowadays not compatible at all with PHP7 (development has not started yet, or I'm not aware of it) , why not merge OPCache to PHP7 source tree (when the time for this will come), still as an extension at first time, and keep developing optimizer passes into this (aka : not in Zend/) ? It's a bit OT, but can you explain what you mean here? OPcache works with the current master (PHP 7), and actually, OPcache worked with phpng all along and definitely since it was merged into master... It's been integrated to the php-src tree since it became standard in 5.5. Do you mean the standalone github repos for older versions? I'm looking at https://github.com/zendtech/ZendOptimizerPlus , I cant find anything related to PHP7 for OPCache. So I was thinking OPCache was not compatible yet with PHP7. I'm also +1 to keep our optimizations into OPCache (into an extension), I'm slightly confused - you mean keep it in (or move optimization over to) the OPcache extension, or move it into its own extension? If it's the former, then I agree. Optimization passes and opcode caching are very much linked, as performing optimizations without having an opcode cache rarely makes sense. I agree with that as well, just Anthony gave a different opinion which seems right as well. Julien.P
Re: [PHP-DEV] Re: About optimization for compiler
Julien Pauli wrote on 03/03/2015 14:43: It's a bit OT, but can you explain what you mean here? OPcache works with the current master (PHP 7), and actually, OPcache worked with phpng all along and definitely since it was merged into master... It's been integrated to the php-src tree since it became standard in 5.5. Do you mean the standalone github repos for older versions? I'm looking athttps://github.com/zendtech/ZendOptimizerPlus , I cant find anything related to PHP7 for OPCache. So I was thinking OPCache was not compatible yet with PHP7. It's in the main repo along with all the other bundled extensions: http://lxr.php.net/xref/PHP_TRUNK/ext/opcache/ It's been bundled since 5.5: https://wiki.php.net/rfc/optimizerplus Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: About optimization for compiler
-Original Message- From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of Julien Pauli Sent: Tuesday, March 03, 2015 4:44 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] Re: About optimization for compiler I'm looking at https://github.com/zendtech/ZendOptimizerPlus , I cant find anything related to PHP7 for OPCache. So I was thinking OPCache was not compatible yet with PHP7. That's the repository for users of old versions (5.5 and earlier). For 7/5.6 it's here: github.com/php/php-src/tree/master/ext/opcache I'm also +1 to keep our optimizations into OPCache (into an extension), I'm slightly confused - you mean keep it in (or move optimization over to) the OPcache extension, or move it into its own extension? If it's the former, then I agree. Optimization passes and opcode caching are very much linked, as performing optimizations without having an opcode cache rarely makes sense. I agree with that as well, just Anthony gave a different opinion which seems right as well. I think that if we ever have optimization passes that are prohibitively expensive to run interactively (most probably around JIT) we'll definitely need new strategies for them. But as long as we're talking about relatively optimization passes that take milliseconds to run and not minutes, I think this approach holds true. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: About optimization for compiler
Julien, Bob's code optimizes things by adding a new OPCode. This is different from compiler optimizations. Compiler optimizations are about changing native, supported OPCode structures to other native supported OPCode structure, but that will run faster at runtime. I agree with dmitry that if we separate the optimizer from the OPCode cache (both in OPCache actually), then the one who will use the optimizer but not the cache, will suffer from a drop in performance. This is silly and should be prevented. We should keep both the optimizer and the cache together IMO, or, we should forbid the optimizer to fire up if no OPCode cache is done after (as the optimizer will eat some performances for nothing). I disagree. All compilation happens interactively (meaning during a request), we can't afford REALLY complex optimizations (a request taking 5 minutes would be out of the question) even if we had an opcode cache. Therefore the optimizations that we include can't be THAT expensive anyway. Yes, it may double or quadruple compilation time. But we're talking 10's of milliseconds, not minutes. And at that point, why should a CLI script like Composer be forbidden to benefit from those optimizations? Yes, it make take slightly longer to compile the script, but the potential benefit of the optimizations could outweigh any additional compilation cost. We discussed some time ago to merge OPCache into PHPCore (back to PHP 5.5 dev) I'm all +1 with that, and for doing that for PHP7.0 When PHP 7.0 will be released, we will not support any new feature in OPCache for PHP5 branches anyway. As OPCache is nowadays not compatible at all with PHP7 (development has not started yet, or I'm not aware of it) , why not merge OPCache to PHP7 source tree (when the time for this will come), still as an extension at first time, and keep developing optimizer passes into this (aka : not in Zend/) ? I'm also +1 to keep our optimizations into OPCache (into an extension), and allow them to be disabled (like its the case actually), because this subject is very hot and sensible. We should keep a PHP compiler as-is, and move optimization passes away from it. zend_extension_op_array_handler() callback is designed for that purpose. -1 I think that the optimizations should be separated out. Have them go into a separate extension. Then merge opcache into the engine. I don't mean copy it, but actually implement it internally. Right now, there's a fair bit of duplication and abstraction in the engine just to enable opcache. A great example is that there are two separate string interning systems that only share a common API between Zend and OpCache. There are other areas of opcache where datastructures are duplicated (or more precisely, information about them is duplicated). So if we merge in the cache to the engine, we can make a far more streamlined and cohesive compiler. Then, the optimizations can be enabled by another extension (or perhaps multiple). We can even make the optimizations pluggable to enable other block-level passes to occur (in CFG form, as block_pass.c uses) rather than require every extension re-implement a lot of logic... Overall, I'd prefer to keep the optimizations separate in one or more clear extensions rather than deeply integrated with temporally-related code. Then the extensions can decide whether to optimize or not (based on ini setting perhaps, based on SAPI, cache setting, etc). Besides, there are more places to optimize than just the oparray (for example, you can do some optimizations on top of the AST). So having one place for all of them to go will simply get unwieldy over time. Anthony On Mon, Mar 2, 2015 at 2:06 PM, Julien Pauli jpa...@php.net wrote: On Fri, Feb 27, 2015 at 4:30 PM, Dmitry Stogov dmi...@zend.com wrote: On Fri, Feb 27, 2015 at 6:22 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 16:12 schrieb Xinchen Hui larue...@gmail.com: On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things
Re: [PHP-DEV] Re: About optimization for compiler
On Fri, Feb 27, 2015 at 4:30 PM, Dmitry Stogov dmi...@zend.com wrote: On Fri, Feb 27, 2015 at 6:22 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 16:12 schrieb Xinchen Hui larue...@gmail.com: On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of Actually, it was called ZendOptimizerPlus... I know, but still, it's better when an extension only does one thing and not two. caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) as I said, I am not against this change... I just want to setup a rule, for where thoese optimization, which could also be done in opcache. Doing it in opcache would currently need to play with extension-defined opcodes etc. I'd rather not be so invasive in opcache that after the optimizations it cannot run in a normal Zend VM anymore. (also a reason why integrating into Zend would be a good idea) or, maybe, we could embed opcache(Optimizer) into Zend later... but of course, it only can happen in next major version... Do we really need a major version for this? It doesn't involve major ABI/API breaks. The compiler step is usually also rather left untouched by most extensions. If we want to do this, we could target 7.1 without major issues. I think so. This may affect some binary interface but should be completely transparent for users. Thanks. Dmitry. thanks Bob -- Xinchen Hui @Laruence http://www.laruence.com/ Bob Bob's code optimizes things by adding a new OPCode. This is different from compiler optimizations. Compiler optimizations are about changing native, supported OPCode structures to other native supported OPCode structure, but that will run faster at runtime. I agree with dmitry that if we separate the optimizer from the OPCode cache (both in OPCache actually), then the one who will use the optimizer but not the cache, will suffer from a drop in performance. This is silly and should be prevented. We should keep both the optimizer and the cache together IMO, or, we should forbid the optimizer to fire up if no OPCode cache is done after (as the optimizer will eat some performances for nothing). We discussed some time ago to merge OPCache into PHPCore (back to PHP 5.5 dev) I'm all +1 with that, and for doing that for PHP7.0 When PHP 7.0 will be released, we will not support any new feature in OPCache for PHP5 branches anyway. As OPCache is nowadays not compatible at all with PHP7 (development has not started yet, or I'm not aware of it) , why not merge OPCache to PHP7 source tree (when the time for this will come), still as an extension at first time, and keep developing optimizer passes into this (aka : not in Zend/) ? I'm also +1 to keep our optimizations into OPCache (into an extension),
[PHP-DEV] Re: About optimization for compiler
On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of Actually, it was called ZendOptimizerPlus... caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) as I said, I am not against this change... I just want to setup a rule, for where thoese optimization, which could also be done in opcache. or, maybe, we could embed opcache(Optimizer) into Zend later... but of course, it only can happen in next major version... thanks Bob -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: About optimization for compiler
Am 27.02.2015 um 16:12 schrieb Xinchen Hui larue...@gmail.com: On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of Actually, it was called ZendOptimizerPlus... I know, but still, it's better when an extension only does one thing and not two. caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) as I said, I am not against this change... I just want to setup a rule, for where thoese optimization, which could also be done in opcache. Doing it in opcache would currently need to play with extension-defined opcodes etc. I'd rather not be so invasive in opcache that after the optimizations it cannot run in a normal Zend VM anymore. (also a reason why integrating into Zend would be a good idea) or, maybe, we could embed opcache(Optimizer) into Zend later... but of course, it only can happen in next major version... Do we really need a major version for this? It doesn't involve major ABI/API breaks. The compiler step is usually also rather left untouched by most extensions. If we want to do this, we could target 7.1 without major issues. thanks Bob -- Xinchen Hui @Laruence http://www.laruence.com/ Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: About optimization for compiler
Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com mailto:larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) Bob
Re: [PHP-DEV] Re: About optimization for compiler
On Fri, Feb 27, 2015 at 6:22 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 16:12 schrieb Xinchen Hui larue...@gmail.com: On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of Actually, it was called ZendOptimizerPlus... I know, but still, it's better when an extension only does one thing and not two. caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) as I said, I am not against this change... I just want to setup a rule, for where thoese optimization, which could also be done in opcache. Doing it in opcache would currently need to play with extension-defined opcodes etc. I'd rather not be so invasive in opcache that after the optimizations it cannot run in a normal Zend VM anymore. (also a reason why integrating into Zend would be a good idea) or, maybe, we could embed opcache(Optimizer) into Zend later... but of course, it only can happen in next major version... Do we really need a major version for this? It doesn't involve major ABI/API breaks. The compiler step is usually also rather left untouched by most extensions. If we want to do this, we could target 7.1 without major issues. I think so. This may affect some binary interface but should be completely transparent for users. Thanks. Dmitry. thanks Bob -- Xinchen Hui @Laruence http://www.laruence.com/ Bob
[PHP-DEV] Re: About optimization for compiler
On Fri, Feb 27, 2015 at 6:08 PM, Bob Weinand bobw...@hotmail.com wrote: Am 27.02.2015 um 07:53 schrieb Xinchen Hui larue...@gmail.com: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ Hmm. I'm not sure, but do we really want to have the optimizations depending on opcache? The big practical problem. That without opcache optimizations are executed on each request. This means that they may require more time to work, than the gain from bytecode improvement. I'd rather shift to slowly adding the optimizations into Zend/, in separate compiler steps you can (like in opcache too) enable and disable. It's actually a bit weird to have to include opcache just for its optimizations. Opcache should do what its name says: the sole task of caching the op_arrays. We need to change an extension for nearly every little change in Zend/. That shouldn't be the case either. Yes. Opcache is extremely depends on engine. Moving optimizer from opcache to ZE may be a good idea. Technically it's possible, but I'm not sure when and how it should be done. I think optimizer need to be refactored as well, but this is only for 7.1 probably. But just to say, it's not only a minor optimization, in a real world stateful parser it makes a difference of a few percent. And also, this optimization only adds a ZEND_SWITCH opcode, nothing more. (except in case we can determine at compile-time where the switch land, then it will be optimized out to a simple JMP) Your ZEND_SWITCH optimization makes sense. Unfortunately, implementation is a bit messy (not intuitive). The biggest problem that it doesn't fit with existing Optimizer. For now I don't know how to change Control Flow Graph representation and corresponding pass to support ZEND_SWITCH. Thanks. Dmitry. Bob
Re: [PHP-DEV] Re: About optimization for compiler
Hi, On 27 February 2015 at 14:26, Xinchen Hui larue...@gmail.com wrote: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep or maybe big optimization? but I don't know how to define big or small optimizations now.. (small is the optimizations, we are sure it is safe, maybe) thanks Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? We may need to clarify which kind of optimizations we want to set a principle. There are different level's optimizations. Opcache is a opcode to opcode optimizer, but some optimizations might need lower level optimizations like Bob's, some might need to change base data structure. We have AST intermediate represent structure, there might be some AST level optimizations, this not opcache's job too. thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Reeze Xia http://reeze.cn
Re: [PHP-DEV] Re: About optimization for compiler
Hey: On Fri, Feb 27, 2015 at 2:41 PM, reeze re...@php.net wrote: Hi, On 27 February 2015 at 14:26, Xinchen Hui larue...@gmail.com wrote: Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep or maybe big optimization? but I don't know how to define big or small optimizations now.. (small is the optimizations, we are sure it is safe, maybe) thanks Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? We may need to clarify which kind of optimizations we want to set a principle. There are different level's optimizations. Opcache is a opcode to opcode optimizer, but some optimizations might need lower level optimizations like Bob's, some might need to change base data structure. We have AST intermediate represent structure, there might be some AST level optimizations, this not opcache's job too. maybe you misunderstand , but let me declare it again. that's what I proposed.. keep opcodes honestly represents what php codes is... (stop doing optimization for compiler for now, and introduces APIs for optimizations, then do them outside of Zend) thanks thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Reeze Xia http://reeze.cn -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: About optimization for compiler
Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep or maybe big optimization? but I don't know how to define big or small optimizations now.. (small is the optimizations, we are sure it is safe, maybe) thanks Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: About optimization for compiler
Hey: On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui larue...@gmail.com wrote: Hey Internals: I was looking Bob's switch optimization.. And, I am not against this switch optimization.. I referring it to show where is my concerns came from thanks then I start to worry about where is the place optimization should goes.. in generally, PHP is a interpreted language. IMO, it should compiler the PHP codes to opcode without any optimization(of course, we did some, but they won't change a lots of opcodes which should be generated).. and, since 5.5, we already have opcache bundled in.. thus, I am proposing a principle, that is: in the future, we only do optimization in opcache side, and keep Zend Compiler without any optimization... considering Zend Compiler do things in -O0. since, optimization always are dangerous.. if we only do them in opcache, user can still run them codes with disable opcache, or at least disable some optimization level which cause that.. what do you think? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
