Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP14989AFEE416C13C8E00D64E21B0@phx.gbl>
References: <CABBJUpd8f8ApcPqJp6d5ih0Bywkk4LUnFdQOD=ovL1U6nhid0Q@mail.gmail.com>
	<alpine.DEB.2.11.1503091024030.5941@whisky.home.derickrethans.nl>
	<BLU436-SMTP14989AFEE416C13C8E00D64E21B0@phx.gbl>
Date: Mon, 9 Mar 2015 16:16:42 +0300
Message-ID: <CA+9eiLucKftOG37_NkOR3F2OHwHhmiP20hjZtOXN5KiD-ysCJQ@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Derick Rethans <derick@php.net>, Xinchen Hui <laruence@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c28bec6762410510dad887
Subject: Re: [PHP-DEV] About optimization for compiler
From: dmitry@zend.com (Dmitry Stogov)

--001a11c28bec6762410510dad887
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 9, 2015 at 3:52 PM, Bob Weinand <bobwei9@hotmail.com> wrote:

> > Am 09.03.2015 um 11:24 schrieb Derick Rethans <derick@php.net>:
> >
> > On Fri, 27 Feb 2015, Xinchen Hui wrote:
> >
> >> Hey Internals:
> >>
> >>      I was looking Bob's switch optimization..
> >>
> >>      then I start to worry about where is the place optimization shoul=
d
> 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?
> >
> > I think it's a very sensible approach. I would however like to see this
> > sort of 'experimental' optimisations to be also possible through an
> > extension. I think some of Sara's? AST hooks might help here?
> >
> > cheers,
> > Derick
>
> Hey Derick,
>
> I don't think this would work. The AST hooks allow changing the AST, but
> they wouldn't allow emitting opcodes based on AST.
> (We can manipulate the AST, but we can't substitute the function which
> compiles e.g. a switch-AST / zend_compile_switch)
>
> The only thing which would work here is changing the opcodes after the
> compilation, but that's a hack. That's going to opcache way and implies
> that we have to do a) full-op_array walks and b) messing around with
> jump-offsets.
> Also, when we do this in an ext, we must assume that we don't run this an=
d
> opcache simultaneously etc. (because opcache relies on ZEND_SWITCH opcode
> to *not* exist and the ext would have to rely on the specific order in
> which instructions are emitted by the compiler)
>
> The way I did it here is IMO the only clean way to do it. Feel free to
> prove me wrong, though ;-)
>

I think if we can implement efficient ZEND_SWITCH in ZE and it provides
some gain, we should do it there.
I know some other languages use similar instruction (Prolog WAP uses
switch_on_...), but the semantic there is more clear.
In php we have to care about NULL, FALSE, TRUE and conversion to INT and
STRING.
May be it's possible to simplify this limiting the usage by cases when only
numbers and non-numeric strings are used.
Then we could use more clear and efficient ZEND_SWITCH_LONG and
ZEND_SWITCH_STRING.

Thanks. Dmitry,



>
> =E2=80=A6
>
> Also, we could do the optimization only in opcache, but this really
> wouldn't ease integration of this particular optimization...
> I'd rather like to see specific optimizations very close to the Engine
> also in the Engine or in some subdirectory of Zend. Instead of an ext.
> Releases anyway already are dependent on opcache keeping up with the engi=
ne.
>
> Bob

--001a11c28bec6762410510dad887--