Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65880
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: <511E86F8.5040807@ellisons.org.uk>
Date: Fri, 15 Feb 2013 19:05:28 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: 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> <511D93E3.3010707@ellisons.org.uk> <511D967D.6040604@sugarcrm.com>
In-Reply-To: <511D967D.6040604@sugarcrm.com>
Content-Type: multipart/alternative;
 boundary="------------030503080106040008060309"
Subject: Re: [PHP-DEV] Zend Optimizer+ Source Code now available
From: Terry@ellisons.org.uk (Terry Ellison)

--------------030503080106040008060309
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 15/02/13 01:59, Stas Malyshev wrote:
>> (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.
> Most optimizations would not give perceivable benefit unless the
> optimized code is run many times. So enabling it without opcode cache
> would not produce very big benefit. But yes, in theory these code parts
> can live separately and they don't actually need each other.
My point here is that APC and the other opcode caches would also benefit 
from these optimizations; they really belong to the compiler and not to 
an opcode accelerator.  Also yes, this type of optimisation usually has 
no net benefit unless  #runs / compile is much greater than one, however 
there are scenarios (e.g. some nasty iteration intensive batch process) 
where taking the hit on optimisation still produces a net runtime saving.
>> that support it).  A Zend opcode cache belongs firmly in the Zend world
>> and shouldn't be a PHP extension.
> I must say I don't understand this conclusion.
Put simply PHP extensions should only reference the APIs exposed in the 
php headers.  Zend has its own interface and extensions and since a Zend 
Opcode cache is SO intimately coupled with the Zend environment it makes 
sense to use a Zend extension to implement this.  The whole idea of 
opcode caching just isn't relevant to a Hiphop environment or even for 
that matter a CLR or Java one since this do their own internal caching 
anyway.
>
>> 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.
> Could you explain this a bit more?
As I posted in a separate not to this list, I've am developing my own 
LPC extension, a fork of APC optimized for CLI and GCI use.  The dogma 
here is that there is no point in opcode caching because "performance 
isn't a driver".   Well my experience is that performance is always a 
driver  For example, just because your application is running on a 
shared service where UID enforced security must be applied and therefore 
some form of scalable per-UID execution environment must be used doesn't 
mean that you don't care about performance.  LPC still give a ~ 2x 
throughput improvement on MediaWiki for example.

I forked and rewrote this cache extension because I couldn't stretch the 
APC code to do what I want in a performant manner without breaking it.  
It's a demonstrator to help me understand the real issues here and to 
get to grips with the minutiae of PHP caching technologies.  I just 
don't see this ever getting to production, but I must admit that 
regressing some of this technologies onto O+ is an option that interests 
me because this does hold out the potential of a standard optimiser 
extension that supports all mainstream SAPIs.

Now to ZEND_INCLUDE_OR_EVAL.  My rationale here is that if the admin has 
specified a stat=0 (or equiv) option then this is a statement that the 
caches content and metadata can be trusted so there is no point in 
examining or reading source files.  However, in the case of the xxx_once 
variants of this instruction, the 
ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER() does path resolution and in 
the case of first load opens the source stream.  Why?  Why not just 
leave examination of the source stream to the compile function?  LPC 
(like APC though for different reasons)  has to rehook the 
ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLE()  handler with a wrapper that 
does dynamic code modification to prevent this access occurring.  O+ 
adopts a different strategy.

LPC or APC having to walk through and essential patch over (private) 
static constant op_handler vectors is just plain horrible.  No, IMO the 
Zend architecture should be designed to support caching; it should 
present a proper clean interface that extensions such as O+ and APC 
implement; and the entire PHP test suite should be capable of being 
executed with a cache extension in place and a good cache should not 
introduce any test failures.

Sorry for the rant and I hope that I answered your Q :)



--------------030503080106040008060309--