Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65850
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ellisons.org.uk from 79.170.44.47 cause and error)
Message-ID: <511D93E3.3010707@ellisons.org.uk>
Date: Fri, 15 Feb 2013 01:48:19 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Christopher Jones <christopher.jones@oracle.com>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Alexey Zakhlestin <indeyets@gmail.com>,
 Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
References: <e8aaa4ce59a801e53c6abc9d287d1859@mail.gmail.com> <511BFC81.8020400@oracle.com> <7de2703f77537a47b457c4479a19ac3a@mail.gmail.com> <CAOc_q_wT5Umo1c2C-H33+n79sBRa64a1BRZYh1bHj3NdRer7jg@mail.gmail.com> <511D2BD6.2090903@sugarcrm.com>
In-Reply-To: <511D2BD6.2090903@sugarcrm.com>
Content-Type: multipart/alternative;
 boundary="------------010309040805040906010705"
Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available
From: Terry@ellisons.org.uk (Terry Ellison)

--------------010309040805040906010705
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 14/02/13 18:24, Stas Malyshev wrote:
>> Are optimizations documented?
> Not yet AFAIK.
>
No, but they are pretty self-explanatory.  O+ is a _Zend_ extension 
rather than a _PHP_ extension and this enables it to exploit extra 
hooks  (see the tail of ZendAccelerator.c) and specifically follow 
through  accel_op_array_handler() and the routines in the Optimizer 
subdirectory.  Essentially this hook is invoked as an epilogue to the 
generating of any op_array.  What this does is a number of peephole 
optimizisations to simplify and NOP out instruction sequences, and the 
last pass compresses the code removing dead NOPs to shrink the op_array 
-- this is typical of the sorts of things that the optimization passes 
of a compiler would do.

And this is a segue into one architectural issue the immediately struck 
me on scanning the code: surely there is a natural domain separation 
between compilation, image startup/rundown, and execution.  (i) is 
optimally done once per S/W version, (ii) per request, (iii) per 
instruction executed.  Surely O+ is currently a hybrid of (i) and (ii) 
and whilst this might have occurred for understandable historical 
reasons, I question this rationale going forward.

(A) The op-code optimization should be integrated into the core compiler 
and enabled through a GC(compiler_option) to be available to *any* 
opcode cache -- or to the application designer (by exposing these 
options through an INI directive.

(B) The O+ opcode cache itself is logically quite separate.  It makes 
great sense to keep ithis as a Zend extension (given the desire from 
some of the dev team to maintain a clear logical separation between the 
upper PHP environment and the Zend, Hippop, ... execution environments 
that support it).  A Zend opcode cache belongs firmly in the Zend world 
and shouldn't be a PHP extension.

I also note some interesting difference in approaches between O+ and 
APC, say for example:

1) in the handling of the ZEND_INCLUDE_OR_EVAL instruction where APC 
patches the op handler and O+ does peephole opcode examination. Both 
these workarounds could be avoided by tidying up the scope of work in 
the instruction code.

2) in the treatment of early binding class inheritence: APC include some 
reasonably complex logic to back this out; O+ sets a compiler option to 
disable this inheritance occurring in the first place, an approach that 
APC might want to copy.

--------------010309040805040906010705--