> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Monday, February 23, 2015 3:43 AM > To: Stanislav Malyshev > Cc: Zeev Suraski; Jefferson Gonzalez; PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Stas, > > >> It is still a performance advantage, because since we know the types > >> are stable at compile time, we can generate far more optimized code > >> (no variant types, native function calls, etc). > > > > I don't see where it comes from. So far you said that your compiler > > would reject some code. That doesn't generate any code, optimized or > > otherwise. For the code your compiler does not reject, still no > > advantage over dynamic model. > > It rejects code because doing code generation on the dynamic case is > significantly harder and more resource intensive. Could that be built in? > Sure. > But it's a very significant difference from generating the static code.
I hope I demonstrated in the other email that lists how two use cases would look with coercive type hints, the strategies and implementation of doing the optimizations for those cases where we can infer the type in compile time, would be similar in cost, complexity and resource consumption to the optimizations you're talking about. Even if we keep the handling of all other types as AOTless/JITless, it would still have performance equivalent to the strict case, given inputs that the strict case accepts. Either way, I'm happy we all agree that equally-efficient code can be generated for the dynamic case, which is the point I was making in the Coercive typing RFC. We still have the gap on whether it's truly a lot harder and resource intensive - I don't think it is as we can do the very same things in compile-time - but that's a smaller gap that I personally care less about. I wanted it to be clear to everyone that we can reach the same level of optimizations for Coercive type hints as we can for Strict. > And even if we generated native code for the dynamic code, it would still > need variants, and hence ZPP at runtime. Hence the static code has a > significant performance benefit in that we can indeed bypass type checks > as > shown in the PECL example a few messages up (more than a few). We can only eliminate the ZPP structure during compile time if we know with certainty what the type is. If we do, we know that for both strict type hints and coercive type hints (i.e. we either managed to prove it's an int in the static analyzer in the strict case, or we managed to deduce what the type is in the coercive case). If we don't - we the ZPP structure it in exactly the same way. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
