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
