> -----Original Message----- > From: Joe Watkins [mailto:pthre...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
