Re: About optimization for compiler
| From: | Bob Weinand | Date: | Mon, 09 Mar 2015 12:52:11 +0000 |
| Subject: | Re: About optimization for compiler | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-84470@lists.php.net to get a copy of this message | ||
> 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 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?
>
> 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 ;-)
…
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