Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83560
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.173 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>
	<661590f4daa710176268b43c1b950583@mail.gmail.com> <CAL=_i_kKQSHonHni3GMCNs85eUGm=qYaa9GJoJHdAbU8viYFgg@mail.gmail.com>
In-Reply-To: <CAL=_i_kKQSHonHni3GMCNs85eUGm=qYaa9GJoJHdAbU8viYFgg@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQIDXD7ehmaYKzbAddTs7O1sB4MzmgIw+OLdAe4e2iYCibfnDQEmdWqtAiDZcfAB4cR2SQJXxpD6Ais01rQBOuFyBwIXH55kA0f2RCABOSCiv5vWop0w
Date: Mon, 23 Feb 2015 12:08:43 +0200
Message-ID: <214184933573e0242e6d2bfe753bea8d@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 11:29 AM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints
> RFC)
>
> Zeev,
>
> >  If you can infer the type with confidence, you can do away with
> > coercion
> code altogether.
>
>
> Maybe I'm ignorant of something, but isn't the only way you can begin to
> infer the type with real confidence is by having strict typed parameters ?

Not at all.  You can definitely infer lots of type information without any
type hints, strict or weak.  bench.php wouldn't be 25x faster and Mandelbrot
would not be as fast as an equivalent C program if we couldn't infer types
without type hints.  Take a look at it (Zend/bench.php) - much like you can,
as a human, figure out that $i is an integer, and that $recen is a float,
etc. - you can write code that will do that automatically (by taking a look
at the assigned values, at the operators which are used, etc.)  In general.

If you haven't, please read my reply to Jefferson from yesterday:
marc.info/?l=php-internals&m=142463029832159&w=2
It illustrates the point as to why not only are strict types not necessary
to do type inference, they also don't provide you with additional data that
can help you generate better code *assuming the same input source code*.
The bets are off if you change your code and compare how the changed version
runs in the Strict mode and the unmodified one runs in Coercive.  But if you
take the modified code and run it on both Strict and Coercive - you can
reach the same results (except for the obvious, intentional functionality
differences).

Now, there may be cases that a static analyzer - that assumes strict rules -
could prompt a developer to change their code (e.g. explicitly cast), and
it's possible that after the change - the code could be better optimized.
I'm not sure if these cases exist or not, but even if they do - after the
code change, Strict and Coercive runtime implementations would be able to
optimize the code equally well.  It might actually make sense for a static
analyzer to optionally employ strict rules even if we go for the
coercive-only option - pointing the developer to where values in his code
clearly switches types due to a type hint - as some sort of a performance
tip.  This would apply primarily in situations where you have values
changing types back and forth and perhaps, with some developer attention -
that could be avoided.

> >  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.
>
> If the parameters aren't strict but are typed then you need to travel
> coercion
> code paths somewhere, optimized inline, calling an API function, it makes
> no
> real difference.

Correct.  But you're comparing a situation where in Strict - the code would
bail out and fail.  Of course failure is faster than actually doing
something :)  The question is what the developer wants to do semantically.
In most cases, with "32" (string) being passed to an integer type hinted
argument, he'd want it to convert to 32 (setting aside the question on
whether implicitly or explicitly).  Which means that in strict - he'd have
to do something along the lines of an explicit cast - and similarly, it
could be optimized inline, call convert_to_long(), etc.
The root difference is that of functionality, not performance.

Zeev