Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62850
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.12.24 cause and error)
Message-ID: <50485DFC.8070603@hoa-project.net>
Date: Thu, 06 Sep 2012 10:25:32 +0200
Reply-To: ivan.enderlin@hoa-project.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0a2
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c-+Hgcv5B4+eGDS+jEj6oNoyefBWO-M=kvThaVdckz62g@mail.gmail.com> <504836A3.20904@zend.com>	<50485647.1060102@hoa-project.net> <CAPwsocGPS7JOxn_Lwx4VZziYrse51aMji3JYx_Aj_Y5EVe4v0w@mail.gmail.com> <50485AA6.4090803@sugarcrm.com>
In-Reply-To: <50485AA6.4090803@sugarcrm.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa")

On 06/09/12 10:11, Stas Malyshev wrote:
> Hi!
>
>>> The lexing and parsing processes will not be slower than actual, and =
the
>> construction of an AST is a new process. Well, as usual, new process
>> requires new resources. But if we look further, it will certainly be a=
 nice
>> tool to perform better opcode caching, it will remove a lot of hacks, =
it
>> will allow third-part tools working on safeness, security, quality etc=
=2E to
>> go deeper at low-costs which is very important for PHP community, it w=
ill
>> facilitate future works
> I don't see how it would lead to better opcode caching.
JIT, lazy-parsing, lazy-opcode generation, caching heuristics,=20
optimisation of opcode generation=85
PHP is interpreted and this is why it is able to offer high dynamic=20
constructions and executions. PHP incredibly scales. But we can do=20
better, maybe by mixing cache + interpretation in a better way. I don't=20
know. I said we are certainly not the first ones facing this =93problem=94=
=2E=20
We have to search in the literature if such solutions exist.

> As for
> third-party tools, I do not see why third-party tools need PHP to chang=
e
> the parser. If PHP's parser is not good enough for those tools, they ca=
n
> have their own parser.
Not if we expose the AST directly into the PHP user-land (maybe through=20
a specific configuration: --enable-user-ast or something like that).

>> Maybe the upfront cost of a parse goes up, but once it is parsed and t=
he
>> opcodes are cached, you won't have this cost again until you change th=
e
>> script. Then you have all of the benefits for every subsequent request=
=2E
> So far we have not seen not only any of these benefits, but any
> explanation of what exactly these benefits would be and any proof they
> would actually benefit anybody.
Because it is a very hard topic and so, it is hard to explain quickly.

> I seriously would propose people
> interested in this project just take up this project and see if it's
> beneficial or not. Just talking about what might happen on the list
> would achieve nothing.
Exactly what I have proposed: =93Let's try as a POC and we will quickly=20
see if this is a wrong way or not=94.

Cheers.

--=20
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/