Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83532
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.177 as permitted sender)
References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com>
	<CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>
	<54EA5EDA.8010605@gmail.com>	<CAAyV7nFt3KL_uH4HuA5xQ7HY+3_3=fq=pg0_U1aMrdirETC6LQ@mail.gmail.com>
	<54EA6A99.5010609@gmail.com>	<CAAyV7nE2Cfr0ohpPnXWnf5agmyGfeirNH-3UGyHEhsDaMvmsoQ@mail.gmail.com>
	<54EA7F15.9030606@gmail.com> <CAAyV7nHqeKUcnRBEhrSbxyCg-okxs4S9G95PsEhFyA-k-iDnUA@mail.gmail.com>
In-Reply-To: <CAAyV7nHqeKUcnRBEhrSbxyCg-okxs4S9G95PsEhFyA-k-iDnUA@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQIDXD7ehmaYKzbAddTs7O1sB4MzmgIw+OLdAe4e2iYCibfnDQEmdWqtAiDZcfAB4cR2SQLEF8I9nCKybTA=
Date: Mon, 23 Feb 2015 04:31:02 +0200
Message-ID: <90e29a09812f8b8f8f6917d4aa4ea936@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>, smalyshev@gmail.com
Cc: Jefferson Gonzalez <jgmdev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> Sent: Monday, February 23, 2015 3:43 AM
> To: Stanislav Malyshev
> Cc: Zeev Suraski; Jefferson Gonzalez; PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Stas,
>
> >> It is still a performance advantage, because since we know the types
> >> are stable at compile time, we can generate far more optimized code
> >> (no variant types, native function calls, etc).
> >
> > I don't see where it comes from. So far you said that your compiler
> > would reject some code. That doesn't generate any code, optimized or
> > otherwise. For the code your compiler does not reject, still no
> > advantage over dynamic model.
>
> It rejects code because doing code generation on the dynamic case is
> significantly harder and more resource intensive. Could that be built in?
> Sure.
> But it's a very significant difference from generating the static code.

I hope I demonstrated in the other email that lists how two use cases would
look with coercive type hints, the strategies and implementation of doing
the optimizations for those cases where we can infer the type in compile
time, would be similar in cost, complexity and resource consumption to the
optimizations you're talking about.  Even if we keep the handling of all
other types as AOTless/JITless, it would still have performance equivalent
to the strict case, given inputs that the strict case accepts.

Either way, I'm happy we all agree that equally-efficient code can be
generated for the dynamic case, which is the point I was making in the
Coercive typing RFC.  We still have the gap on whether it's truly a lot
harder and resource intensive - I don't think it is as we can do the very
same things in compile-time - but that's a smaller gap that I personally
care less about.  I wanted it to be clear to everyone that we can reach the
same level of optimizations for Coercive type hints as we can for Strict.

> And even if we generated native code for the dynamic code, it would still
> need variants, and hence ZPP at runtime. Hence the static code has a
> significant performance benefit in that we can indeed bypass type checks
> as
> shown in the PECL example a few messages up (more than a few).

We can only eliminate the ZPP structure during compile time if we know with
certainty what the type is.  If we do, we know that for both strict type
hints and coercive type hints (i.e. we either managed to prove it's an int
in the static analyzer in the strict case, or we managed to deduce what the
type is in the coercive case).  If we don't - we the ZPP structure it in
exactly the same way.

Thanks,

Zeev