On 02/23/2015 05:05 AM, Zeev Suraski wrote:
-----Original Message-----
From: Joe Watkins [mailto:pthre...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
