Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83576
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender)
Message-ID: <54EB4091.40806@gmail.com>
Date: Mon, 23 Feb 2015 11:00:33 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Zeev Suraski <zeev@zend.com>, Joe Watkins <pthreads@pthreads.org>
CC: PHP internals <internals@lists.php.net>
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>
In-Reply-To: <661590f4daa710176268b43c1b950583@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
From: jgmdev@gmail.com (Jefferson Gonzalez)

On 02/23/2015 05:05 AM, Zeev Suraski wrote:
>> -----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.
>

In that case since coercive is less strict it would be needed to 
duplicate the code in order to optimize, example:

function calc (int $val1, int $val2){ ... }

//This call does not requires coercive type checks
calc(1,6) -> direct call to optimized C function

//This call may require coercive checks
calc($val1, $val2) -> call to coercive implementation of the function

So in order to optimize I guess it would be needed to generate 2 
versions of a function: optimized and coercive, which will increase the 
required ram at runtime and even the CPU in order to gain the 
performance benefits presented on strict mode.