Hi Anthony, If you are working on JIT, you should understand that declare() switch to strict typing can't improve anything, because it works on caller side and in each function you now will have to generate code for both weak and strict checks.
According to mandel() and integer to float conversion in the loop, it's possible to perform a backward data-propagation pass to catch this case and replace integer by float in first place. We did it in our old JIT prototypes without any type hinting. Also, don't use "fild", use SSE2 and/or AVX. Thanks. Dmitry. On Fri, Feb 13, 2015 at 5:43 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > Zeev, > > On Fri, Feb 13, 2015 at 6:34 AM, Zeev Suraski <z...@zend.com> wrote: > > > >> On 13 בפבר׳ 2015, at 13:13, Andrea Faulds <a...@ajf.me> wrote: > >> > >> Hi, > >> > >>> On 13 Feb 2015, at 09:37, Patrick ALLAERT <patrickalla...@php.net> > wrote: > >>> > >>> Voted "no" because of the reasons already mentioned by a bunch of > others here. > >>> > >>> Weak type hint as presented earlier: +1 (and very good job Andrea > about that!). > >>> declare(strict_types=1): -1, not only about the syntax, but also about > the mixed mode it introduces. > >>> > >>> I'm pretty confident that this RFC will "pass" with just above 2/3 of > majority while it could reach much more. > >>> > >>> I am pretty sure that if this RFC doesn't include a strict type mode > _the way it is proposed_ (or even, not at all, as part of another related > RFC), it would have some "no" converted to "yes" and would have a wider > adoption, which is for sure a better option than relying on a voting > mechanism which still is a supporting tool, we're not politicians after all > :) > >> > >> It wouldn’t have wider adoption. Excluding a large portion of the PHP > community (which favours strict types) and giving them something which > doesn’t work for their use cases (weak types) is not going to win any fans. > > > > Any fans? Really? > > > > How about we put it to a test instead of guessing the outcome? > > > > We have long operated as a Do-ocracy in that the RFC author has final > say over what goes into their proposal. You are definitely free to ask > and make suggestions (and share opinions), but ultimately it's up to > the author. Andrea, as the author of this RFC, has apparently decided > that it isn't going to happen in this proposal at this time. Please > respect that, even if you don't agree. > > With that said, there's nothing stopping you from putting up your time > to create a competing proposal and patch. If you really believe that > weak types are the better way forward, why not codify that? If only > one of the RFCs passes, then you have your answer. If both pass, we > can simply have another vote to choose which to move forward with. > Competition is healthy for the community. > > You also said earlier in the thread that you don't agree with the > points that I made on my blog post > (http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html). Can you > share what you don't agree with (in the comments or this thread)? > Rasmus posted some issues, most of which I consider details in this > proposal (declare() and lack of handling the int->float conversion > case) and I replied to them (I think they are handleable). If you have > other disagreement, why not share? > > I would especially would like a response to the point that I made > where I showed 3 examples where weak hints of any type would cause > subtle and hard-to-find bugs; one of which was a high-level security > risk. > > One final side-point: In my work on Recki-CT, I learned very early on > that casts are quite expensive. When compiling mandel() from > Zend/bench.php, the implicit casts that were happening on $w2, $x and > a few other vars (which were ints) to floats for the computation added > approximately 10% to the runtime of the function. The casts in mandel2 > accounted for 20% of the runtime. Let me say that again: the > int->float conversion in the loops accounted for between 10% and 20% > of the function call. And that's not a dynamic cast (a branch based on > type), it's a single `fild` instruction. Having the ability to > statically know that a cast will never be needed can result in > significantly faster (and easier) native code generation... > > Thanks > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
