Zeev, As this is going in circles, this will be my last post here (it seems we feel the same in this regards):
> 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. I thought something was broken too, but it turns out it was just GCC's optimizer doing what it was supposed to do. Eliminate dead code (meaning code that has no side effects and doesn't affect the outcome). > 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. For a *given* arbitrary source file, yes you are correct. For a given source code which will not produce errors at runtime, you are not correct. Because coercive will let through things that a static analyzer would error at (the code wouldn't be valid in strict mode). Therefore, the level of type inference you can do is different. You can say that for any correct strict file, you can run it in coercive mode and have the same benefits. But the reverse is not true. Valid coercive code is not necessarily valid strict code. So the assumptions and analysis you can do on strict code doesn't apply in the general case to coercive code. Hence the point I've been trying to make the entire time. > 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). Again, it comes down to analyzability. For an arbitrary valid (non-error-producing) source file, strict mode will allow more optimizations. Not because for a specific example it can do more, but it can do so for a far greater percentage of the code in strict mode. > 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. Again, for very specific examples, yes. For the general case of both, no. > 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. And the same can be done today without any type hints. For a very significant subset of code. With strict mode, the vast majority of valid code will be analyzable (and hence optimizable). Without it, a much smaller subset can be. > 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. I've shown what I believe are counterproofs. I've given example after example to show where valid (never producing an error at runtime in coercive mode) code is ambiguous to a static analyzer. And I've shown that to make it unambiguous is akin to applying the restrictions that strict mode enforces. Therefore, coercive is not the same as strict mode in terms of analyzability. But since we're going in circles, I would simply ask that you remove any reference to the topics from your RFC. It's contentions enough as it is, and your presentation of only one side is not only unfair, but also misleading. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
