> -----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. > You may be able to perform some of the same optimizations, but the code > executed at runtime is going to be more complex to execute and to > generate, that is obviously true. Again, not necessarily. We shouldn't assume we'll generate machine code for all the possible flows. The code generated would be very similar in both strict and coercive cases. > The JIT Zend had needed to generate similarly complicated code and *it > was not faster than PHP, in the real world*, we are told. It depends on what kind of real world we're talking about here. For number crunching, it's super-fast with very tangible gains, and that's an understatement. Not sure if you saw my email from yesterday, but it shows 25x (2500%, no mistake) gains on bench.php, with zero changes to the code, and obviously, without type hints, strict or dynamic. With web apps we tested, there wasn't a tangible difference, but that doesn't (yet) mean much. We stopped most of the work on it when the PHPNG effort began. It may or may not be possible to squeeze more performance using JIT out of these apps, we won't know until we try again. > I'm not sure what you are arguing about, there is no point in > generating any > code that is not faster than Zend, and Zend just got a bunch faster. JIT might end up being about making PHP viable for more CPU-bound use cases, rather than speeding up existing Web workloads. But it's way too early to conclude that. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
