Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65165
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
Message-ID: <51027ACC.5020308@zerocue.com>
Date: Fri, 25 Jan 2013 06:30:04 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Julien Pauli <jpauli@php.net>
CC: Rasmus Lerdorf <rasmus@lerdorf.com>, Ralf Lang <lang@b1-systems.de>, 
 internals@lists.php.net
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> <CAMUwpuSNvr3LG4HT0D91wFoF+y0Dc8B9-yCW8YeHL0WALFDWPw@mail.gmail.com>
In-Reply-To: <CAMUwpuSNvr3LG4HT0D91wFoF+y0Dc8B9-yCW8YeHL0WALFDWPw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
From: cpriest@zerocue.com (Clint Priest)


On 1/25/2013 4:37 AM, Julien Pauli wrote:
> On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
>
>> 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.
I'm not sure if anyone has a deep understanding of APC and the problems 
the existing compiler design causes for it, perhaps another great place 
to start on this project is to get a list of the high-level problems the 
compiler does or doesn't do that could be changed.  Then we can break 
those down and identify the parts of the engine that will require some 
re-work.
>> 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.
>>
> That feels like a safe idea. I'm convinced that having more internals
> documentation will help
> developpers understand at least the engine (that's what interest us here).
I agree that bringing some more documentation can only help; people with 
less experience or who have missing areas of expertise in the core will 
more easily be able to step up and help with the problem.

> I know it's a hard task, but we all here have blogs where sometimes we
> write great articles
> about a part of internals, I think we should focus on working alltogether
> writing a real technical doc for the engine,
> that will help people (like me for example), understand some dark parts of
> it, and then find ideas or solutions for it to
> evolve the right way.

This may only be my perception, but in having to learn what I did for 
the failed accessors project I felt like there were 2 or 3 more or less 
identical ways the compiler and/or executor was doing the same thing.  
Without further understanding I presumed it was because as time went by 
a new "way" was added because the old way just wasn't enough.  In 
essence adding to the technical debt. Possibly/probably just a 
misconception of my own but that's the way it felt.

I'd be happy to jump in and help fix this in any way I can but I don't 
even know where the string starts or what it looks like to unravel the 
problem at this point.

-- 
-Clint