> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Monday, February 23, 2015 4:14 PM > To: Zeev Suraski > Cc: Joe Watkins; PHP internals > Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints > RFC) > > Zeev, > > >> 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. > > Yes, but mandel() from bench.php isn't generic code. It is a subset of > valid > code. One that wouldn't need any changes to move to strict mode.
I'm not sure what that means. mandel() is an example in the very same way that foo() and bar() you presented were examples. It also happens to be a real world example showing Joe that not only is it possible to do type inference without strict typing (who asked " isn't the only way you can begin to infer the type with real confidence is by having strict typed parameters?") - but it's possible to do a great job at it, too. > Additionally: "would not be as fast as an equivalent C program". I > compiled > mandel() using C (via PECL). It wasn't 25x faster, it was 75734.13830x > faster > (3000x with -O0). So no, you're way off from C speed. Those were our results: PHPNG-JIT (JIT=on) 0.011 (25 times faster than php-7) gcc -O2 (4.9.2) 0.013 gcc -O0 (4.9.2) 0.022 PHP-7 0.281 (15 times faster than php-5.0) PHP-5.6 0.379 PHP-5.5 0.383 PHP-5.4 0.406 PHP-5.3 0.855 PHP-5.2 1.096 PHP-5.1 1.217 PHP-4.4 4.209 PHP-5.0 4.434 Something broken in your setup. BTW, I'm not claiming our JIT is faster than gcc. It's at the margin of error level. > > 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). > > Again, please make it clear to people that you're talking about special > cases > of userland code, where the rest of us are talking about general cases. But I'm not. We are all talking about general cases. The code snippets in the email I sent to Jefferson are as generic as they could possibly be, allowing you to fill the code blocks with anything to your heart's content - the outcome would not change. We're in an endless repetitive ping pong here, so I'm going to summarize this thread from my POV: 1. For a given input source file, there is zero difference in terms of AOT/JIT between Strict mode and Coercive mode. In both cases, the level of type inference you can do is identical - and cases where you can determine the type of the arguments being passed conclusively can turn into a C-style call instead of a PHP call. Cases where you cannot determine that would be conceptually similar between Strict and Coercive, except Strict would result in a failure in case it detects the wrong type at runtime, while Coercive may succeed. Intended functional difference, no performance difference. 2. Since Strict rejects any wrongly typed value, in cases where you can determine conclusively that the wrong type may make it into a certain function, you can alert to that fact, prompting the developer to change it. Depending on the nature of the change, it *might* result in the ability to better optimize the code, although so far, there has been no concrete example of that shown (i.e., an example where prompting the user about a potentially invalid code, that would prompt a change, that would result in the ability to generate faster code than the original code running under coercive typing). I think these cases are rare but do exist - primarily in situations where you have the same value repeatedly flipping back and forth between types across function boundaries (e.g. a string converting to float and back to string). 3. The difference between Strict and Coercive modes is exclusively that of function, not performance. Whatever performance gains one may be able to gain, if any, will result from code changes - not from him choosing Strict STH. The changed code would have identical result whether they're run on Strict STH or Coercive STH. 4. As a direct result of #3, one could use the very same static analyzer and emit the very same messages - except conversions which may succeed (like string->int) may be flagged as warnings instead of errors. People who want to minimize implicit conversions will be able to do so, to the exact same level as your static analyzer could warn them if they were running in Strict mode. That is, assuming there are any performance gains to be had from such explicit conversions. I think we've all spent enough time on that topic, and the academic discussion has run its course. I find myself restating to the same principals again and again, and so far no counterproofs have been shown to refute any of them. If you believe you come up with any counterproofs to any of the above points - code ones, not theoretical ones - please share them. I'm going to focus on the actual RFC from this point onwards. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
