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. > So that means one less branch > (no guard) per argument per function call. In addition, native calls > can be used in a lot of cases, which means the compiled code doesn't > even need to know about a zval (significant memory and access > reduction). This has potential to be significant. Not to mention the > other optimizations that are possible. > This already worked for as without type hinting. > However, I think making this decision based on performance is the > incorrect way of doing it. For the Zend engine, there will be no > discernible difference between the proposals. It's a red herring. The > difference I would focus on is the ability to statically analyze the > code (with the benefits that comes with). > Completely agree, changing language for compiler is not fair. It's clear that statically typed languages are more suitable but we won't make PHP statically typed. Also, modern JS engines showed - what they may do without typing. In my opinion strict type hints may be useful for program verification, but again, I wouldn't like to change the whole language semantic just to get few unit tests out of the box. Thanks. Dmitry. > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
