Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65162
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.43 as permitted sender)
MIME-Version: 1.0
Sender: thbley@gmail.com
In-Reply-To: <51024016.4010005@lerdorf.com>
References: <slrnkg3ag2.g88.dsp@experimentalworks.net>
	<CAJW__o2gncnxnAGd7M7jZjxGADzt2D9xYQOyhp_797Lebx5JSA@mail.gmail.com>
	<CAL+t6cH6b290+T9=dLp_FFaFCAUiJumx9zvWQNiUr5KfKyunXQ@mail.gmail.com>
	<51023AB1.2010607@b1-systems.de>
	<51024016.4010005@lerdorf.com>
Date: Fri, 25 Jan 2013 12:55:50 +0100
Message-ID: <CA+_UWzr=U3mBW22xSSKfbEswS4-yxtnWWABEre_zbeMXWr83tQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
From: thbley+php@gmail.com (Thomas Bley)

> One thing I can guarantee is that if we add it to core in its current
> condition it will delay 5.5 by 6+ months if not longer.

I think it is fine if APC doesn't support all features of PHP. When
there is a clear documentation, everybody can decide if he skips some
features for better performance. Maybe this also offers room for more
optimizations.

Regards,
Thomas


On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 01/24/2013 11:56 PM, Ralf Lang wrote:
>>> From what I understood from Rasmus the biggest challenge with merging APC
>>> into core is the fact that the compiler currently isn't built to support
>>> opcode caching. One of the challenges he pointed out was some of the
>>> MAKE_NOP trickery that can make APC's work a bit more complex than
>>> necessary. It's possible to optimize the compiler enough to the point that
>>> APC's code could be reduced down to very simple opcode caching, putting
>>> less stress on the engine and making it easier to maintain.
>>
>> I think there was some support for moving APC first from pecl to the PHP
>> standard distribution's ext folder before any tighter integration is
>> started.
>
> I'm really not convinced that by moving it to core we will magically get
> people to help with it. I have been trying to get people interested for
> years, and it hasn't gotten very far. Everyone wants it in the core, but
> with a couple of exceptions, nobody is willing to actually work on it to
> get it there.
>
> And I can understand the lack of help. It is probably the most
> complicated piece of the entire stack. It is a an op_array juggler doing
> a complex dance on a tight rope backwards and blindfolded. It is
> essentially multi-threaded in that there are multiple processes all
> reading and writing the same chunk of memory while dealing with a
> compiler that spits out context-sensitive op_arrays that were never
> designed to be cached and executed this way.
>
> So the learning curve is steep and the bugs are extremely hard to track
> down because it is the only PHP component that isn't a perfect sandbox.
> A slight memory corruption almost anywhere in any extension can segfault
> a dozen requests later with a backtrace that points to the opcode cache
> code. Not to mention web servers like Apache that longjmp() on us at the
> wrong time. Zend-signals addresses this, but even in 5.4 they aren't
> enabled by default because of stability issues and without those no
> shared memory opcode cache is safe.
>
> I firmly believe that we need opcode caching in core. I'm rather
> skeptical that simply moving pecl/apc to ext/apc is going to help users
> in any way. People have no trouble finding and installing APC today. The
> real issue here is robustness and lag time between a PHP release and and
> solid APC release and that has to do with resources which are scarce due
> to the code complexity. This is the real problem we need to solve.
> Either by a number of people stepping up to help with the existing APC
> code, or perhaps more realistically making it a priority in PHP 5.6 to
> streamline the engine and the executor for opcode caching and either
> including a heavily simplified version of APC or writing a new one.
>
> One thing I can guarantee is that if we add it to core in its current
> condition it will delay 5.5 by 6+ months if not longer.
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>