Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84470
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.116.48 as permitted sender)
Message-ID: <BLU436-SMTP14989AFEE416C13C8E00D64E21B0@phx.gbl>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <alpine.DEB.2.11.1503091024030.5941@whisky.home.derickrethans.nl>
Date: Mon, 9 Mar 2015 13:52:11 +0100
CC: Xinchen Hui <laruence@gmail.com>,
 PHP Internals <internals@lists.php.net>,
 Dmitry Stogov <dmitry@zend.com>
Content-Transfer-Encoding: quoted-printable
References: <CABBJUpd8f8ApcPqJp6d5ih0Bywkk4LUnFdQOD=ovL1U6nhid0Q@mail.gmail.com> <alpine.DEB.2.11.1503091024030.5941@whisky.home.derickrethans.nl>
To: Derick Rethans <derick@php.net>
Subject: Re: [PHP-DEV] About optimization for compiler
From: bobwei9@hotmail.com (Bob Weinand)

> Am 09.03.2015 um 11:24 schrieb Derick Rethans <derick@php.net>:
>=20
> On Fri, 27 Feb 2015, Xinchen Hui wrote:
>=20
>> Hey Internals:
>>=20
>>      I was looking Bob's switch optimization..
>>=20
>>      then I start to worry about where is the place optimization =
should goes..
>>=20
>>      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)..
>>=20
>>      and, since 5.5, we already have opcache bundled in..
>>=20
>>      thus, I am proposing a principle, that is:
>>=20
>>      in the future, we only do optimization in opcache side, and keep
>> Zend Compiler without any optimization... considering Zend Compiler =
do
>> things in -O0.
>>=20
>>      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..
>>=20
>>      what do you think?
>=20
> I think it's a very sensible approach. I would however like to see =
this=20
> sort of 'experimental' optimisations to be also possible through an=20
> extension. I think some of Sara's? AST hooks might help here?
>=20
> 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 =
and 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 ;-)

=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 =
engine.

Bob=