Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84469
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1503091024030.5941@whisky.home.derickrethans.nl>
References: <CABBJUpd8f8ApcPqJp6d5ih0Bywkk4LUnFdQOD=ovL1U6nhid0Q@mail.gmail.com>
	<alpine.DEB.2.11.1503091024030.5941@whisky.home.derickrethans.nl>
Date: Mon, 9 Mar 2015 15:47:26 +0300
Message-ID: <CA+9eiLt-rUADFTKDo4589DJnkxAA=D_YD_fwGYEscgw64kvkjw@mail.gmail.com>
To: Derick <derick@php.net>
Cc: PHP Internals <internals@lists.php.net>, Bob Weinand <bobwei9@hotmail.com>, 
	Xinchen Hui <laruence@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c28becbcb9df0510da6f0a
Subject: Re: [PHP-DEV] About optimization for compiler
From: dmitry@zend.com (Dmitry Stogov)

--001a11c28becbcb9df0510da6f0a
Content-Type: text/plain; charset=UTF-8

On Mar 9, 2015 1:24 PM, "Derick Rethans" <derick@php.net> wrote:
>
> 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
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?
>
> 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?

AST may be siutable only for very basic optimisations.
Opcache already implements optimisations on top of Control Flow Graph, but
they take significant time. Without opcache they would slowdown execution
instead of speedup. During work on JIT we developed a more smart framework
for optimization based on Extended Static Single Assignment form. I think
in the future we will able to get gain from it even without JIT.

Thanks. Dmitry.

>
> cheers,
> Derick

--001a11c28becbcb9df0510da6f0a--