Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83473
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.48 as permitted sender)
Message-ID: <54E9E6B5.3030905@gmail.com>
Date: Sun, 22 Feb 2015 10:24:53 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Etienne Kneuss <colder@php.net>, 
 Anthony Ferrara <ircmaxell@gmail.com>,
 Zeev Suraski <zeev@zend.com>
CC: PHP internals <internals@lists.php.net>
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com> <CAAyV7nHq_-9jyRcwJmiAxthmEo3u3MDXcyOC09LV2DETABzCoA@mail.gmail.com> <8250289916f5128b5bc1a114428d374e@mail.gmail.com> <CAAyV7nHAicJCQU87YkhZ700a=k4MRqVJtMV-mG4F0MQsn82OfQ@mail.gmail.com> <CACQesk5cqzWD4jGSsv7b1ZoiinL7vyC5ZSZ2nemTMuKfUwqk2Q@mail.gmail.com>
In-Reply-To: <CACQesk5cqzWD4jGSsv7b1ZoiinL7vyC5ZSZ2nemTMuKfUwqk2Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: jgmdev@gmail.com (Jefferson Gonzalez)

On 02/22/2015 09:00 AM, Etienne Kneuss wrote:

> There have been several attempts:
> for JS: http://users-cs.au.dk/simonhj/tajs2009.pdf
> or similar techniques applied to PHP, quite outdated though:
> https://github.com/colder/phantm
>
> You are right that the lack of static information about types is (one of
> the) a main issue. Recovering the types has typically a huge performance
> cost, or is unreliable
>
> But seriously, time is getting wasted on this argument; it's actually a
> no-brainer: more static information helps tools that rely on static
> information. Yes. Absolutely. 100%.
>
> The question is rather: at what weight should we take (potential/future)
> external tools into account when developping language features?
>

Previous on the list nodejs JIT engine was mentioned as a working 
example of a JIT without the language having any sort of type 
information. While this is true I think it should also be considered the 
amount of checks and resources required for the generated machine code 
to achieve this. On this tests you can see that in most situations the 
javascript v8 engine used on nodejs uses much more memory than that of 
current PHP (compare it to C also) 
(benchmarksgame.alioth.debian.org/u64/compare.php?lang=v8&lang2=php) 
Yes, it is faster, but it consumes much more CPU and RAM in most 
situations, and I'm sure that it is related to the dynamic nature of the 
language.

A JIT or AOT machine code generator IMHO will never have a decent use of 
system resources without some sort of strong/strict typed rules, 
somebody explain if thats not the case.

As I see it, some example, if the JIT generated C++ code to then 
generate the machine code:

function calc(int $val1, int $val2) : int {return $val1 + $val2;}

On weak mode I see the generated code would be something like this:

Variant* calc(Variant& val1, Variant& val2) {
     if(val1.isInt() && val2.isInt())
         return new Variant(val1.toInt() + val2.toInt());

     else if(val1.isFloat() && val2.isFloat())
         return new Variant(val1.toInt() + val2.toInt());
     else
         throw new RuntimeError();
}

while on strict mode the generated code could be:

int calc(int val1, int val2) {
     return val1 + val2;
}

So in this scenario is clear that strict mode performance and memory 
usage would be better. Code conversion code would be required only in 
some cases, example:

calc(1, 5) // No need for casting

calc((int) "12", (int) "15") // Needs casting depending on how the 
parser deals with it

If my example is right it means strict would be better to achieve good 
performance rather than weak which is almost the same situation we have 
now with zval's. Also I think is wrong to say that casting will always 
take place on strict mode.

So I have some questions floating on my mind for the coercive rfc.

1. Does weak mode could provide the required rules to implement a JIT 
with a sane level of memory and CPU usage?

2. I see that the proponents of dual weak/strict modes are offering to 
write a AOT implementation if strict makes it, And the impresive work of 
Joe (JITFU) and Anthony on recki-ct with the strict mode could be taken 
to another level of integration with PHP and performance. IMHO is harder 
and more resource hungry to implement a JIT/AOT using weak mode. With 
that said, if a JIT implementation is developed will the story of the 
ZendOptimizer being a commercial solution will be repeated or would this 
JIT implementation would be part of the core?

Thats all that comes to mind now, and while many people doesn't care for 
performance, IMHO a programming language mainly targeted for the web 
should have some caring on this department.