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 ? This sounds like the kind of strict mode we're talking about, where no coercion is necessary because inference is so reliable given a good starting place (function entry with strictly typed parameters). > 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. I guess we are hedging our bets that having to travel those paths will suck away so much performance, that it will make all of the effort required to make any of this a reality seem, somehow ... wasted. > JIT might end up being about making PHP viable for more CPU-bound use cases ... This is probably quite realistic. In case anyone is reading and thinks I'm using any of this to justify dual mode, I'm not doing that. The original RFC justified it well enough, I just happen to disagree with some of the assertions made in this thread and or RFC. Cheers Joe On Mon, Feb 23, 2015 at 9:05 AM, Zeev Suraski <z...@zend.com> 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. > > > 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 >
