On 1/25/2013 4:37 AM, Julien Pauli wrote:
On Fri, Jan 25, 2013 at 9:19 AM, Rasmus Lerdorf <ras...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
