Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83481
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.177 as permitted sender)
Message-ID: <54EA3046.9000607@gmail.com>
Date: Sun, 22 Feb 2015 15:38:46 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Joe Watkins <pthreads@pthreads.org>, 
 Jefferson Gonzalez <jgmdev@gmail.com>
CC: Etienne Kneuss <colder@php.net>, 
 Anthony Ferrara <ircmaxell@gmail.com>,
 Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>	<CAAyV7nHq_-9jyRcwJmiAxthmEo3u3MDXcyOC09LV2DETABzCoA@mail.gmail.com>	<8250289916f5128b5bc1a114428d374e@mail.gmail.com>	<CAAyV7nHAicJCQU87YkhZ700a=k4MRqVJtMV-mG4F0MQsn82OfQ@mail.gmail.com>	<CACQesk5cqzWD4jGSsv7b1ZoiinL7vyC5ZSZ2nemTMuKfUwqk2Q@mail.gmail.com>	<54E9E6B5.3030905@gmail.com> <CAL=_i_midq3PGKJHYb32-rKU_vFXm98BH=1gGVQq7D2UBUpV1w@mail.gmail.com>
In-Reply-To: <CAL=_i_midq3PGKJHYb32-rKU_vFXm98BH=1gGVQq7D2UBUpV1w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: jgmdev@gmail.com (Jefferson Gonzalez)

On 02/22/2015 11:06 AM, Joe Watkins wrote:
>
> This is an inescapable difference, of the the kind that definitely does
> have a negative impact on implementation complexity, runtime, and
> maintainability.
>
> To me, it only makes sense to compile strict code AOT or JIT; If you want
> dynamic behaviour, we have an extremely mature platform for that.

So basically weak mode coupled with a JIT will be almost the same thing 
we have today, the only difference is the opcache would be replaced with 
machine code (for a bit more of performance), but the same logic and 
code used on the zend engine will also be used on the generated code of 
the JIT (more bloat).

On the other hand a strict type mode would allow the generation of 
machine code that is much cleaner and similar in respect of C to machine 
code translation, meaning it would be more efficient and less resource 
hungry to the point that functions code generated by the AOT or JIT 
would be more efficient than those functions provided by the zend 
engine, which does lots of type checking/parsing (less bloat).


> There should hopefully be no need to complicate the core with the
> implementation, the number of people that are capable of maintaining Zend
> is low enough already, the number of people able to maintain something as
> new (for us) and complex as a JIT/AOT engine is even less, I fear.

And thats why I asked about the commercial stuff, because, like things 
are looking, from a technical perspective the strict mode opens the 
doors for an easier implementation of AOT or JIT while a weak mode would 
only make it harder for others in the community to work in such things, 
which again rises the question, does this whole idea of favoring a weak 
model by the minority serve as an impediment/complication for others so 
they (those who favor weak) can force a commercial solution?

> I think it's likely that Anthony and I, and Dmitry want different things
> for a JIT/AOT engine. I think Anthony and I are preferring an engine that
> requires minimal inference because type information is present (or
> implicit), while Dmitry probably favours the kind that can infer at
> runtime, the dynamic kind, like Zend is today. They are a world apart, I
> think, I'll be happy to be proven wrong about that.
>
> I like to think that even if Dmitry wrote it all by himself, it would be
> opensource from the start, in fact I don't think that will happen. I'm
> hoping we'll all work on the same solution together.

And it would be ideal to have the most capable people to develop this 
solution to work in a single team from a community point of view. IMHO a 
dual weak/strict mode is the best way of getting people to work together 
in a way that benefits the community. Otherwise, a single handed man 
working on a solution can serve as a justification to commercialize 
something that is being currently offered by others (HHVM).