Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84011
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 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 23:12:27 +0800
Message-ID: <CABBJUpcD5MTHYc8UVi-=MpXs3U-pAb0KcZVj0nXJiu_SdOqQBg@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: PHP Internals <internals@lists.php.net>, Dmitry Stogov <dmitry@zend.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: About optimization for compiler
From: laruence@gmail.com (Xinchen Hui)

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...

> 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.

or, maybe, we could embed opcache(Optimizer) into Zend later... but of
course, it only can happen in next major version...

thanks
> Bob



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/