Re: JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)

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.