About optimization for compiler View as Markdown

Julien,

Bob's code optimizes things by adding a new OPCode.
This is different from compiler optimizations.

Compiler optimizations are about changing native, supported OPCode
structures to other native supported OPCode structure, but that will run
faster at runtime.

I agree with dmitry that if we separate the optimizer from the OPCode cache
(both in OPCache actually), then the one who will use the optimizer but not
the cache, will suffer from a drop in performance. This is silly and should
be prevented.

We should keep both the optimizer and the cache together IMO, or, we should
forbid the optimizer to fire up if no OPCode cache is done after (as the
optimizer will eat some performances for nothing).

I disagree.

All compilation happens interactively (meaning during a request), we
can't afford REALLY complex optimizations (a request taking 5 minutes
would be out of the question) even if we had an opcode cache.
Therefore the optimizations that we include can't be THAT expensive
anyway. Yes, it may double or quadruple compilation time. But we're
talking 10's of milliseconds, not minutes.

And at that point, why should a CLI script like Composer be forbidden
to benefit from those optimizations? Yes, it make take slightly longer
to compile the script, but the potential benefit of the optimizations
could outweigh any additional compilation cost.

We discussed some time ago to merge OPCache into PHPCore (back to PHP 5.5
dev)
I'm all +1 with that, and for doing that for PHP7.0
When PHP 7.0 will be released, we will not support any new feature in
OPCache for PHP5 branches anyway.
As OPCache is nowadays not compatible at all with PHP7 (development has not
started yet, or I'm not aware of it) , why not merge OPCache to PHP7 source
tree (when the time for this will come), still as an extension at first
time, and keep developing optimizer passes into this (aka : not in Zend/) ?

I'm also +1 to keep our optimizations into OPCache (into an extension), and
allow them to be disabled (like its the case actually), because this
subject is very hot and sensible.
We should keep a PHP compiler as-is, and move optimization passes away from
it. zend_extension_op_array_handler() callback is designed for that purpose.

-1

I think that the optimizations should be separated out. Have them go
into a separate extension. Then merge opcache into the engine. I don't
mean copy it, but actually implement it internally.

Right now, there's a fair bit of duplication and abstraction in the
engine just to enable opcache. A great example is that there are two
separate string interning systems that only share a common API between
Zend and OpCache. There are other areas of opcache where
datastructures are duplicated (or more precisely, information about
them is duplicated).

So if we merge in the cache to the engine, we can make a far more
streamlined and cohesive compiler. Then, the optimizations can be
enabled by another extension (or perhaps multiple).

We can even make the optimizations pluggable to enable other
block-level passes to occur (in CFG form, as block_pass.c uses) rather
than require every extension re-implement a lot of logic...

Overall, I'd prefer to keep the optimizations separate in one or more
clear extensions rather than deeply integrated with temporally-related
code. Then the extensions can decide whether to optimize or not (based
on ini setting perhaps, based on SAPI, cache setting, etc). Besides,
there are more places to optimize than just the oparray (for example,
you can do some optimizations on top of the AST). So having one place
for all of them to go will simply get unwieldy over time.

Anthony

Am 27.02.2015 um 16:12 schrieb Xinchen Hui laruence@gmail.com:

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...

I know, but still, it's better when an extension only does one thing and
not two.

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.

Doing it in opcache would currently need to play with extension-defined
opcodes etc. I'd rather not be so invasive in opcache that after the
optimizations it cannot run in a normal Zend VM anymore. (also a reason
why
integrating into Zend would be a good idea)

or, maybe, we could embed opcache(Optimizer) into Zend later... but of
course, it only can happen in next major version...

Do we really need a major version for this? It doesn't involve major
ABI/API breaks. The compiler step is usually also rather left untouched
by
most extensions. If we want to do this, we could target 7.1 without major
issues.

I think so. This may affect some binary interface but should be completely
transparent for users.

Thanks. Dmitry.

thanks

Bob

--
Xinchen Hui
@Laruence
http://www.laruence.com/

Bob

Bob's code optimizes things by adding a new OPCode.
This is different from compiler optimizations.

Compiler optimizations are about changing native, supported OPCode
structures to other native supported OPCode structure, but that will run
faster at runtime.

I agree with dmitry that if we separate the optimizer from the OPCode cache
(both in OPCache actually), then the one who will use the optimizer but not
the cache, will suffer from a drop in performance. This is silly and should
be prevented.

We should keep both the optimizer and the cache together IMO, or, we should
forbid the optimizer to fire up if no OPCode cache is done after (as the
optimizer will eat some performances for nothing).

We discussed some time ago to merge OPCache into PHPCore (back to PHP 5.5
dev)
I'm all +1 with that, and for doing that for PHP7.0
When PHP 7.0 will be released, we will not support any new feature in
OPCache for PHP5 branches anyway.
As OPCache is nowadays not compatible at all with PHP7 (development has not
started yet, or I'm not aware of it) , why not merge OPCache to PHP7 source
tree (when the time for this will come), still as an extension at first
time, and keep developing optimizer passes into this (aka : not in Zend/) ?

I'm also +1 to keep our optimizations into OPCache (into an extension), and
allow them to be disabled (like its the case actually), because this
subject is very hot and sensible.
We should keep a PHP compiler as-is, and move optimization passes away from
it. zend_extension_op_array_handler() callback is designed for that purpose.

Julien.Pauli

-----Original Message-----
From: julienpauli@gmail.com [mailto:julienpauli@gmail.com] On Behalf Of
Julien Pauli
Sent: Monday, March 02, 2015 9:07 PM
To: Dmitry Stogov
Cc: Bob Weinand; Xinchen Hui; PHP Internals
Subject: Re: [PHP-DEV] Re: About optimization for compiler

As OPCache is nowadays not compatible at all with PHP7 (development has
not started yet, or I'm not aware of it) , why not merge OPCache to PHP7
source tree (when the time for this will come), still as an extension at
first
time, and keep developing optimizer passes into this (aka : not in Zend/)
?

It's a bit OT, but can you explain what you mean here? OPcache works with
the current master (PHP 7), and actually, OPcache worked with phpng all
along and definitely since it was merged into master... It's been
integrated to the php-src tree since it became standard in 5.5. Do you mean
the standalone github repos for older versions?

I'm also +1 to keep our optimizations into OPCache (into an extension),

I'm slightly confused - you mean keep it in (or move optimization over to)
the OPcache extension, or move it into its own extension?
If it's the former, then I agree. Optimization passes and opcode caching
are very much linked, as performing optimizations without having an opcode
cache rarely makes sense.

and
allow them to be disabled (like its the case actually), because this
subject is
very hot and sensible.

We should keep a PHP compiler as-is, and move optimization passes away
from it. zend_extension_op_array_handler() callback is designed for that
purpose.

Agreed.

Zeev