On Fri, Feb 20, 2015 at 9:26 AM, Dmitry Stogov <dmi...@zend.com> wrote: > Hi Anthony, > > On Fri, Feb 20, 2015 at 5:55 PM, Anthony Ferrara <ircmax...@gmail.com> > wrote: >> >> Dmitry >> >> On Fri, Feb 20, 2015 at 9:25 AM, Dmitry Stogov <dmi...@zend.com> wrote: >> > >> > >> > On Fri, Feb 20, 2015 at 5:08 PM, Pierre Joye <pierre....@gmail.com> >> > wrote: >> >> >> >> hi Dmitry, >> >> >> >> On Thu, Feb 19, 2015 at 11:13 PM, Dmitry Stogov <dmi...@zend.com> >> >> wrote: >> >> > On Fri, Feb 20, 2015 at 4:57 AM, Anthony Ferrara >> >> > <ircmax...@gmail.com> >> >> > wrote: >> >> > >> >> >> Larry, >> >> >> >> >> >> > Anthony, can you expand here at all about the practical benefits >> >> >> > of >> >> >> > strong-typing for variable passing for the compiler? That seems >> >> >> > to >> >> >> > be >> >> >> the >> >> >> > main point of contention: Whether or not there are real, practical >> >> >> benefits >> >> >> > to be had in the compiler of knowing that a call will be in >> >> >> > "strict >> >> >> mode". >> >> >> > (If there are, then the split-mode makes sense If there are not, >> >> >> > then >> >> >> > there's little benefit to it.) >> >> >> >> >> >> For the normal compiler & engine there will be no benefit for the >> >> >> foreseeable future. >> >> >> >> >> >> For a tracing JIT compiler, there will be no advantage. >> >> >> >> >> >> For a local JIT compiler, there can be some optimizations around >> >> >> reduced conversion logic generated (and hence potentially better >> >> >> cache >> >> >> efficiency, etc). A guard would still be generated, but that's a >> >> >> single branch rather than the full cast logic. This would likely be >> >> >> a >> >> >> small gain (likely less than 1%, possibly significantly less). >> >> >> >> >> >> For a AOT compiler (optimizing compiler), more optimizations and >> >> >> therefore gains can be had. The big difference here is that type >> >> >> assertions can be done at compile time. >> >> > >> >> > >> >> > AOT compiler that know type of passed argument and expected parameter >> >> > type, >> >> > may eliminate guard check independently on hint semantic (strong or >> >> > week). >> >> > If you don't know first or second you'll have to generate guard code >> >> > anyway >> >> > independently from hint semantic (strong or week). Is this wrong? >> >> > >> >> > We may introduce strong type hints because of your mistake. >> >> >> >> >> >> May, could, would, all that are totally irrelevant to the debate about >> >> type hinting. The speed benefit is not significant. >> > >> > >> > What is significant? Miracle ability of static analyzes for AOT? >> >> Please, can we discuss something without snark? And can we get past >> AOT? It's distracting. I only mentioned it here because I was >> specifically asked about it. It's not in my RFC. So please, let's get >> past it. > > > sorry, I shouldn't be too emotional. > actually, it's hard to express emotions with may bad English :) > I think, you are doing a great job regarding AOT, but I think strict types > won't help you a lot. > We may discuss it out of the list on next week.
if any place, on EFNet, if not the ML must remain the place to discuss things. >> >> >> I think we can agree on that, and we did as far as I can tell :) >> > >> > >> > I didn't agree with you. >> > Probably, I told that performance impact of run-time switch of type >> > hinting >> > semantic is slightly negative and it would be great to fix it if >> > possible. >> >> Everyone is saying this shouldn't be voted on based on performance. >> You, me, Pierre, everyone. > > > Performance is not a stopper for vote, but it doesn't mean it's not > important. It is, only not in this context unless the patch changed in such ways that the performance impact becomes relevant. However, as of now, it is not. See Matt's perf results using the usual suspects. Cheers, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
