# About optimization for compiler - Thread: https://externals.io/message/83958 - Original archive: https://news-web.php.net/php.internals/83958 - Started by Xinchen Hui on 2015-02-27T06:22:42+00:00 - Messages: 24 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #83958 — Xinchen Hui — 2015-02-27T06:22:42+00:00 URL: https://externals.io/message/83958#83958 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 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/ --- ## #83959 — Xinchen Hui — 2015-02-27T06:26:40+00:00 URL: https://externals.io/message/83958#83959 · In reply to: #83958 Hey: > 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/ --- ## #83960 — reeze — 2015-02-27T06:41:25+00:00 URL: https://externals.io/message/83958#83960 · In reply to: #83959 Hi, > Hey: > > > > […] > goes.. > > […] > 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 > > […] > 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. > > […] > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ > > -- > > > > -- Reeze Xia http://reeze.cn --- ## #83962 — Xinchen Hui — 2015-02-27T06:49:30+00:00 URL: https://externals.io/message/83958#83962 · In reply to: #83960 Hey: > Hi, > > > > […] > > > 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 > > > […] > > > > -- > Reeze Xia > http://reeze.cn -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #83963 — Xinchen Hui — 2015-02-27T06:53:16+00:00 URL: https://externals.io/message/83958#83963 · In reply to: #83958 Hey: > 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/ --- ## #84009 — Bob Weinand — 2015-02-27T15:08:29+00:00 URL: https://externals.io/message/83958#84009 · In reply to: #83963 > Am 27.02.2015 um 07:53 schrieb Xinchen Hui : > > Hey: > > > > […] > And, I am not against this switch optimization.. > > I referring it to show where is my concerns came from > > thanks > > […] > > > > -- > 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 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 --- ## #84011 — Xinchen Hui — 2015-02-27T15:12:27+00:00 URL: https://externals.io/message/83958#84011 · In reply to: #84009 > Am 27.02.2015 um 07:53 schrieb Xinchen Hui : > > Hey: > > > > 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/ --- ## #84014 — Bob Weinand — 2015-02-27T15:22:17+00:00 URL: https://externals.io/message/83958#84014 · In reply to: #84011 > Am 27.02.2015 um 16:12 schrieb Xinchen Hui : > > > > […] > Actually, it was called ZendOptimizerPlus... I know, but still, it's better when an extension only does one thing and not two. > > […] > 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 > > […] > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ Bob --- ## #84016 — Dmitry Stogov — 2015-02-27T15:26:58+00:00 URL: https://externals.io/message/83958#84016 · In reply to: #84009 > Am 27.02.2015 um 07:53 schrieb Xinchen Hui : > > Hey: > > > > 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 --- ## #84018 — Dmitry Stogov — 2015-02-27T15:30:48+00:00 URL: https://externals.io/message/83958#84018 · In reply to: #84014 > > > […] > wrote: > > […] > wrote: > > […] > depending > > […] > separate > > […] > > I know, but still, it's better when an extension only does one thing and > not two. > > > […] > That > > […] > more. > > […] > then > > […] > > 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) > > > […] > > 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. > > > […] > > Bob --- ## #84179 — Julien Pauli — 2015-03-02T19:06:35+00:00 URL: https://externals.io/message/83958#84179 · In reply to: #84018 > > > > […] > Zend/. > > […] > land, > > […] > why > > […] > by > > […] > > I think so. This may affect some binary interface but should be completely > transparent for users. > > Thanks. Dmitry. > > > > > > […] > 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), 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. Julien.Pauli --- ## #84183 — Pierre Joye — 2015-03-02T20:33:11+00:00 URL: https://externals.io/message/83958#84183 · In reply to: #83958 > > 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 > 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? As it sounds appealing, I am not a big fan of creating different scenarios from a core perspective. It will make the testing and maintenance harder, by introducing extra possible bugs. If I am not mistaken, it was planed to have to integrate opcache in the engine, making it part of it instead than a still optional extension. That would be a better way and may open new possibilities. --- ## #84184 — Anthony Ferrara — 2015-03-02T20:47:39+00:00 URL: https://externals.io/message/83958#84184 · In reply to: #84179 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 > > > > […] > > > 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), 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. > > > Julien.Pauli --- ## #84232 — Julien Pauli — 2015-03-03T12:34:42+00:00 URL: https://externals.io/message/83958#84232 · In reply to: #84184 > Julien, > > > > […] > cache > > […] > not > > […] > should > > […] > should > > […] > > 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. > > […] > not > > […] > source > > […] > Zend/) ? > > […] > and > > […] > from > > […] > 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 --- ## #84236 — Zeev Suraski — 2015-03-03T13:52:18+00:00 URL: https://externals.io/message/83958#84236 · In reply to: #84179 > -----Original Message----- > From: julienpauli@gmail.com [mailto:julienpauli@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 --- ## #84237 — Julien Pauli — 2015-03-03T14:43:45+00:00 URL: https://externals.io/message/83958#84237 · In reply to: #84236 > > […] > > 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 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 --- ## #84238 — Rowan Collins — 2015-03-03T14:53:28+00:00 URL: https://externals.io/message/83958#84238 · In reply to: #84237 Julien Pauli wrote on 03/03/2015 14:43: > > […] > 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] --- ## #84239 — Zeev Suraski — 2015-03-03T14:56:58+00:00 URL: https://externals.io/message/83958#84239 · In reply to: #84237 > -----Original Message----- > From: julienpauli@gmail.com [mailto:julienpauli@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 > > […] > 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 --- ## #84243 — Anthony Ferrara — 2015-03-03T15:50:13+00:00 URL: https://externals.io/message/83958#84243 · In reply to: #84239 Zeev, > > […] > > 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 --- ## #84245 — Zeev Suraski — 2015-03-03T16:04:01+00:00 URL: https://externals.io/message/83958#84245 · In reply to: #84243 > -----Original Message----- > From: Anthony Ferrara [mailto:ircmaxell@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, > > > […] > > 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 --- ## #84458 — Derick Rethans — 2015-03-09T10:24:51+00:00 URL: https://externals.io/message/83958#84458 · In reply to: #83958 > 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 > 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? I think it's a very sensible approach. I would however like to see this sort of 'experimental' optimisations to be also possible through an extension. I think some of Sara's? AST hooks might help here? cheers, Derick --- ## #84469 — Dmitry Stogov — 2015-03-09T12:47:26+00:00 URL: https://externals.io/message/83958#84469 · In reply to: #84458 > > > > > […] should goes.. > > […] > > I think it's a very sensible approach. I would however like to see this > sort of 'experimental' optimisations to be also possible through an > extension. I think some of Sara's? AST hooks might help here? AST may be siutable only for very basic optimisations. Opcache already implements optimisations on top of Control Flow Graph, but they take significant time. Without opcache they would slowdown execution instead of speedup. During work on JIT we developed a more smart framework for optimization based on Extended Static Single Assignment form. I think in the future we will able to get gain from it even without JIT. Thanks. Dmitry. > > cheers, > Derick --- ## #84470 — Bob Weinand — 2015-03-09T12:52:11+00:00 URL: https://externals.io/message/83958#84470 · In reply to: #84458 > Am 09.03.2015 um 11:24 schrieb Derick Rethans : > > > > > […] > > I think it's a very sensible approach. I would however like to see this > sort of 'experimental' optimisations to be also possible through an > extension. I think some of Sara's? AST hooks might help here? > > cheers, > Derick Hey Derick, I don't think this would work. The AST hooks allow changing the AST, but they wouldn't allow emitting opcodes based on AST. (We can manipulate the AST, but we can't substitute the function which compiles e.g. a switch-AST / zend_compile_switch) The only thing which would work here is changing the opcodes after the compilation, but that's a hack. That's going to opcache way and implies that we have to do a) full-op_array walks and b) messing around with jump-offsets. Also, when we do this in an ext, we must assume that we don't run this and opcache simultaneously etc. (because opcache relies on ZEND_SWITCH opcode to *not* exist and the ext would have to rely on the specific order in which instructions are emitted by the compiler) The way I did it here is IMO the only clean way to do it. Feel free to prove me wrong, though ;-) … Also, we could do the optimization only in opcache, but this really wouldn't ease integration of this particular optimization... I'd rather like to see specific optimizations very close to the Engine also in the Engine or in some subdirectory of Zend. Instead of an ext. Releases anyway already are dependent on opcache keeping up with the engine. Bob --- ## #84472 — Dmitry Stogov — 2015-03-09T13:16:42+00:00 URL: https://externals.io/message/83958#84472 · In reply to: #84470 > > […] > goes.. > > […] > > Hey Derick, > > I don't think this would work. The AST hooks allow changing the AST, but > they wouldn't allow emitting opcodes based on AST. > (We can manipulate the AST, but we can't substitute the function which > compiles e.g. a switch-AST / zend_compile_switch) > > The only thing which would work here is changing the opcodes after the > compilation, but that's a hack. That's going to opcache way and implies > that we have to do a) full-op_array walks and b) messing around with > jump-offsets. > Also, when we do this in an ext, we must assume that we don't run this and > opcache simultaneously etc. (because opcache relies on ZEND_SWITCH opcode > to *not* exist and the ext would have to rely on the specific order in > which instructions are emitted by the compiler) > > The way I did it here is IMO the only clean way to do it. Feel free to > prove me wrong, though ;-) > I think if we can implement efficient ZEND_SWITCH in ZE and it provides some gain, we should do it there. I know some other languages use similar instruction (Prolog WAP uses switch_on_...), but the semantic there is more clear. In php we have to care about NULL, FALSE, `TRUE` and conversion to INT and STRING. May be it's possible to simplify this limiting the usage by cases when only numbers and non-numeric strings are used. Then we could use more clear and efficient ZEND_SWITCH_LONG and ZEND_SWITCH_STRING. Thanks. Dmitry, > > … > > Also, we could do the optimization only in opcache, but this really > wouldn't ease integration of this particular optimization... > I'd rather like to see specific optimizations very close to the Engine > also in the Engine or in some subdirectory of Zend. Instead of an ext. > Releases anyway already are dependent on opcache keeping up with the engine. > > Bob