Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67027
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain zend.com does not designate 209.85.215.42 as permitted sender)
References: <CA+9eiLsjK0wTT4L0UN9uJdSJgO8se3YDebZwSHycrqAJswJufQ@mail.gmail.com>
 <CAL0xaBECR92ur0SDVZzYyh23+d-UnBE+DUjqkEAJZ=1EtUyNTQ@mail.gmail.com>
In-Reply-To: <CAL0xaBECR92ur0SDVZzYyh23+d-UnBE+DUjqkEAJZ=1EtUyNTQ@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQFVPpSNbOGMJmTVWXvN9y+HxauxBwDgUUw9mbpZ/8A=
Date: Wed, 10 Apr 2013 16:18:33 +0300
Message-ID: <346136c9a028d303d8345ffd4c3c8237@mail.gmail.com>
To: Arvids Godjuks <arvids.godjuks@gmail.com>, Dmitry Stogov <dmitry@zend.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Arvids Godjuks [mailto:arvids.godjuks@gmail.com]
> Sent: Wednesday, April 10, 2013 4:08 PM
> To: PHP Internals
> Subject: Re: [PHP-DEV] OPcache optimizer improvement in PHP-5.5?
>
> 2013/4/10 Dmitry Stogov <dmitry@zend.com>
>
> > Hi,
> >
> > Recently, I've found that OPcache optimizer misses a lot of abilities,
> > because it handles only one op_array at once. So it definitely can't
> > perform any inter-function optimizations (e.g. inlining).
> >
> > Actually, it was not very difficult to switch to "script at once"
> > approach.
> > The attached patch demonstrates it and adds per script constants
> > substitution explained in the following script
> >
> > <?php
> > define("FOO", 1);
> > function foo() {
> >     echo FOO . "\n"; // optimizer will replace it with: echo "1\n"; }
> > ?>
> >
> > Of course, I ran the PHP test suite and it passed all the same tests.
> > Personally, I think it's safe to include this patch into 5.5 and make
> > a green light to some other advanced optimizations in 5.5. (e.g.
> > conversion INIT_FCALL_BY_NAME into DO_FCALL).
> >
> > Any thoughts?
> >
> > Thanks. Dmitry.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
> > visit: http://www.php.net/unsub.php
> >
>
>
> Hi!
>
> Many obvious optimizations are not used due to the fact, that script
> translation
> into opcode state has to be fast. The nature of PHP dictated that and this
> was re-
> iterated countless times on this mailing list by the core developers.
>
> To do advanced stuff, you have to create some sort of pre-compile or
> storing
> that compiled code reliably on disk so that if memory cache is dropped or
> restart
> is done, there is no significant preformance hit while all the code
> compiles into
> optimized opcode again.
>
> I would also imagine that good part of the optimizations would require
> multiple
> files to be processed and optimized, but due to dynamic nature of the PHP
> opcode compilation is done on per-file basis, so do the optimizations.
>
> It's very commendable that you want to push optimizations and stuff, but
> there
> are some fundamental stuff that needs to be cared of to do some really
> good
> stuff.

I think it very much depends on the nature of the optimizations.  For the
vast majority of optimizations we can apply to PHP's execution architecture,
I actually don't think that we need to go back to the fundamentals and
consider things like storing pre-compiled scripts on disk.  The compiler,
even with optimization passes still takes split seconds to execute, which
means a 'cold boot' (e.g. when doing a restart) won't be a noticeably
painful process.  As long as you end up reusing the results of that process
a lot more frequently than you have to recreate them - you're fine.

Note that our experience was that reading binary serialized data from disk
isn't significantly faster than invoking the compiler in the first place -
you still have to read the data from disk, you still have to analyze it and
backpatch addresses, etc.;  I know that some people here are revisiting that
assertion - which is absolutely fine - but the assumption that saving
precompiled files on disk eliminates compilation overhead is wrong.  If
anything it gives a marginal benefit...

From my POV I think we're fine with any optimization that does not break the
single-file barrier (in other words, no cross-file optimizations).  The one
Dmitry suggested falls in that category, so I think it's fine, and it's
mostly a question of whether we want it in 5.5 or only in 5.6.

Zeev