Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83553
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.171 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>	<54EA891B.6030405@gmail.com>	<09b9ee836c04b1750614a91bd39a5bed@mail.gmail.com>
	<54EA97A2.4010701@gmail.com> <CAL=_i_nn_az7gsu2Y7Qhp29cP1gJ96T_0SmG60rhY12qKvr6qA@mail.gmail.com>
In-Reply-To: <CAL=_i_nn_az7gsu2Y7Qhp29cP1gJ96T_0SmG60rhY12qKvr6qA@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQIDXD7ehmaYKzbAddTs7O1sB4MzmgIw+OLdAe4e2iYCibfnDQEmdWqtAiDZcfAB4cR2SQJXxpD6Ais01rQBOuFyBwIXH55km/qaqHA=
Date: Mon, 23 Feb 2015 11:05:48 +0200
Message-ID: <661590f4daa710176268b43c1b950583@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: 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: Joe Watkins [mailto:pthreads@pthreads.org]
> Sent: Monday, February 23, 2015 10:03 AM
> To: Jefferson Gonzalez
> Cc: Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Zeev,
>
>     I missed the initial replies to this, just had a quick read through
> (of the kind
> you have first thing on a Monday morning).
>
>     Essentially the problem is this:
>
>     > My point is that we can do the very same optimizations with coercive
> types as well - basically, that there is no delta.
>
>    The problem is that an implementation that has to care about coercion,
> one that has to care about nonsense input, has to generate considerably
> more complex code, to manage that input or perform those coercions.

Not necessarily.  If you can infer the type with confidence, you can do away
with coercion code altogether.  If you can't, then you're not obligated to
generate optimized paths for every possible input - you can just defer to
the relevant coerce() function.  It's very similar to what you'd be able to
do with strict, except instead of calling coerce(), it would run a runtime
type check that errors out on failure.  The difference is that of
functionality, not performance.

>    You may be able to perform some of the same optimizations, but the code
> executed at runtime is going to be more complex to execute and to
> generate, that is obviously true.

Again, not necessarily.  We shouldn't assume we'll generate machine code for
all the possible flows.  The code generated would be very similar in both
strict and coercive cases.

>    The JIT Zend had needed to generate similarly complicated code and *it
> was not faster than PHP, in the real world*, we are told.

It depends on what kind of real world we're talking about here.  For number
crunching, it's super-fast with very tangible gains, and that's an
understatement.  Not sure if you saw my email from yesterday, but it shows
25x (2500%, no mistake) gains on bench.php, with zero changes to the code,
and obviously, without type hints, strict or dynamic.  With web apps we
tested, there wasn't a tangible difference, but that doesn't (yet) mean
much.  We stopped most of the work on it when the PHPNG effort began.  It
may or may not be possible to squeeze more performance using JIT out of
these apps, we won't know until we try again.

>    I'm not sure what you are arguing about, there is no point in
> generating any
> code that is not faster than Zend, and Zend just got a bunch faster.

JIT might end up being about making PHP viable for more CPU-bound use cases,
rather than speeding up existing Web workloads.  But it's way too early to
conclude that.

Thanks,

Zeev