Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84018
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP2039471E714BB553BE06CC8E2150@phx.gbl>
References: <CABBJUpd8f8ApcPqJp6d5ih0Bywkk4LUnFdQOD=ovL1U6nhid0Q@mail.gmail.com>
	<CABBJUpf63s3_Yp2o2_YdWYZJKVPqVTR+94qXmZUU7R5=8NiJrQ@mail.gmail.com>
	<BLU437-SMTP88BCE6F234A85E87BA3F4BE2150@phx.gbl>
	<CABBJUpcD5MTHYc8UVi-=MpXs3U-pAb0KcZVj0nXJiu_SdOqQBg@mail.gmail.com>
	<BLU436-SMTP2039471E714BB553BE06CC8E2150@phx.gbl>
Date: Fri, 27 Feb 2015 19:30:48 +0400
Message-ID: <CA+9eiLvb-_5TzW8-_Sguxa0JmqtuAT21A7jkydV4-6z-w1-EaA@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Xinchen Hui <laruence@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133e5f28843a50510138ddd
Subject: Re: [PHP-DEV] Re: About optimization for compiler
From: dmitry@zend.com (Dmitry Stogov)

--001a1133e5f28843a50510138ddd
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 27, 2015 at 6:22 PM, Bob Weinand <bobwei9@hotmail.com> wrote:

>
> > Am 27.02.2015 um 16:12 schrieb Xinchen Hui <laruence@gmail.com>:
> >
> > On Fri, Feb 27, 2015 at 11: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?
> >>
> >> 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
>
>

--001a1133e5f28843a50510138ddd--