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 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), 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
