Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83524
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.52 as permitted sender)
Message-ID: <54EA83E4.1030107@gmail.com>
Date: Sun, 22 Feb 2015 17:35:32 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Anthony Ferrara <ircmaxell@gmail.com>, Zeev Suraski <zeev@zend.com>
CC: PHP internals <internals@lists.php.net>
References: <2e4694f9805ee81ea0b2c79eab06c2d6@mail.gmail.com>	<CAAyV7nExeZ1xouJAsACm9AvAGuQw0e-0FgVdEOAyzsC5OEn5_Q@mail.gmail.com>	<83921f861c3378dfc6ea34b6681f2edd@mail.gmail.com>	<CAAyV7nEhdeXQbUi9jy10M1NyfaV-w1kF=nWeSW0zd8UQh2_dJQ@mail.gmail.com>	<26a5bb62bd37a3f610b2a6c10f84d855@mail.gmail.com>	<CAAyV7nEf_q_NkoQrWN1pa_ot8Ype-SCdvJOdpevUsd4y8Kv6pA@mail.gmail.com>	<6d317b6cce0cc1aaded1dae11218234d@mail.gmail.com>	<CAAyV7nFcGWJOj-R3ZEn8XkGFqzuw1Ef3tx3Ykm3AXg6KxB+wHg@mail.gmail.com>	<7d58f9b893c257c7289166b31bbdd9ac@mail.gmail.com> <CAAyV7nEoRfPi9u+2OhfZeuTpNJ+innmyajiEYRGSbX+zOP_4Dg@mail.gmail.com>
In-Reply-To: <CAAyV7nEoRfPi9u+2OhfZeuTpNJ+innmyajiEYRGSbX+zOP_4Dg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] JIT (was RE: [PHP-DEV] Coercive Scalar Type Hints RFC)
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> The difference though is the journey. The static analyzer can reason
> about far more code with strict types than it can without (due to the
> limited number of possibilities presented at each call). So this
> leaves the dilema: compiled code that behaves slightly differently
> (what Recki does) or whether it always behaves the same.

Wait, so are you saying that advantage of having strict typing in PHP
core is that some analyzer - which does not share code with PHP core,
AFAIU - if it interpreted PHP types in strict manner and provided
warnings where types it can statically deduce do not match and the
authors of the code agreed with its suggestions and rewrote their code
so that the analyzer would not complain, would in some cases result in
code that might be JIT-optimized more efficiently?

That is not a claim about strict typing in PHP core having any benefit
at all. I'm not sure even this claim is true (as adding (int) doesn't
actually improve performance - it just shifts around the place where the
conversion is done, and once conversion is done, you can do the same
optimizations as before) - but even if there's some situation where it
is true, I don't see how it makes difference for PHP core (even in
situation of "PHP core + JIT extension" or "non-Zend PHP runtime with
AOT/JIT").

-- 
Stas Malyshev
smalyshev@gmail.com