Re: About optimization for compiler

On Fri, Feb 27, 2015 at 6:08 PM, Bob Weinand <bobwei9@hotmail.com> wrote: > Am 27.02.2015 um 07:53 schrieb Xinchen Hui <laruence@gmail.com>: > > Hey: > > On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui <laruence@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 >