Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84016
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU437-SMTP88BCE6F234A85E87BA3F4BE2150@phx.gbl>
References: <CABBJUpd8f8ApcPqJp6d5ih0Bywkk4LUnFdQOD=ovL1U6nhid0Q@mail.gmail.com>
	<CABBJUpf63s3_Yp2o2_YdWYZJKVPqVTR+94qXmZUU7R5=8NiJrQ@mail.gmail.com>
	<BLU437-SMTP88BCE6F234A85E87BA3F4BE2150@phx.gbl>
Date: Fri, 27 Feb 2015 19:26:58 +0400
Message-ID: <CA+9eiLsUh33tS7v3qLH+KyUtKOy1oNPK5opU_8-iOJVq91WFEg@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=bcaec52bf2d9ce39570510137f1b
Subject: Re: About optimization for compiler
From: dmitry@zend.com (Dmitry Stogov)

--bcaec52bf2d9ce39570510137f1b
Content-Type: text/plain; charset=UTF-8

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
>

--bcaec52bf2d9ce39570510137f1b--