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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
