Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83256
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54E66569.8000709@garfieldtech.com>
References: <011801d04a07$83ab1c00$8b015400$@php.net>
	<CABDNdAFQsbo-A-gijPCwYDOf3ts-yKpP0tAL--WUaLU26GB-AQ@mail.gmail.com>
	<016f01d04a3a$e9183220$bb489660$@php.net>
	<CAESVnVoM7YbmXA8hTG1O66j+6YX3Xx2Q3uj_F=TPjHA4ws=8JA@mail.gmail.com>
	<d8031ce52e9965c789887e8f7b687a4e@mail.gmail.com>
	<CAESVnVpA+M6iv_zbDmKTEF8Q1zKjwnbi1ucc=UyuUyRr+X+U3w@mail.gmail.com>
	<022801d04ab1$4a0c47d0$de24d770$@php.net>
	<1913e09d7f52541901d8574d2080a63f@mail.gmail.com>
	<CAAyV7nFD=BQ5dBYiKzhbOKTomKmWvruTnb=R_n9mYB-Lz1P9pg@mail.gmail.com>
	<7a5d96b34b98ec1f3ee17be7fa6a1e81@mail.gmail.com>
	<CAPhkiZxpYbaPN1370_HFTVnBA=Jg-rU8DrB2P+2dmRcJfGWPtw@mail.gmail.com>
	<2CBDEB67-3DE3-437D-9AF3-0E6A92027244@zend.com>
	<CAPhkiZwcD3h42=9eak4uP9n2GBE=v0LVP6Ncq9Oz7L91dJ5y5w@mail.gmail.com>
	<4cc0c81c7199a452534bb8edcdb19914@mail.gmail.com>
	<54E589F6.9030002@garfieldtech.com>
	<d62afd01c97a2d00466ac88579fa861c@mail.gmail.com>
	<54E66569.8000709@garfieldtech.com>
Date: Thu, 19 Feb 2015 20:57:33 -0500
Message-ID: <CAAyV7nG79GbQt_hcAsV15Ad-7k7KjDW43HTGyegHPoswDMNzJA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Reviving scalar type hints
From: ircmaxell@gmail.com (Anthony Ferrara)

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. 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.

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).

Anthony