> 1. Does weak mode could provide the required rules to implement a JIT
with a sane level of memory and CPU usage?
There is no objective answer to the question while it has the clause "with
a sane level of ...".
The assertion in the RFC that says there is no difference between strict
and weak types, in the context of a JIT/AOT compiler, is wrong.
function add(int $l, int $r) {
return $l + $r;
}
The first instruction in the interpreted code is not ZEND_ADD, first,
parameters must be received from the stack.
If that's a strict function, then un-stacking parameters is relatively
easy, if it's a dynamic function then you have to generate code that is
considerably more complicated.
This is an inescapable difference, of the the kind that definitely does
have a negative impact on implementation complexity, runtime, and
maintainability.
To me, it only makes sense to compile strict code AOT or JIT; If you want
dynamic behaviour, we have an extremely mature platform for that.
> 2. ... 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?
There should hopefully be no need to complicate the core with the
implementation, the number of people that are capable of maintaining Zend
is low enough already, the number of people able to maintain something as
new (for us) and complex as a JIT/AOT engine is even less, I fear.
I think it's likely that Anthony and I, and Dmitry want different things
for a JIT/AOT engine. I think Anthony and I are preferring an engine that
requires minimal inference because type information is present (or
implicit), while Dmitry probably favours the kind that can infer at
runtime, the dynamic kind, like Zend is today. They are a world apart, I
think, I'll be happy to be proven wrong about that.
I like to think that even if Dmitry wrote it all by himself, it would be
opensource from the start, in fact I don't think that will happen. I'm
hoping we'll all work on the same solution together.
Cheers
Joe
On Sun, Feb 22, 2015 at 2:24 PM, Jefferson Gonzalez <jgm...@gmail.com>
wrote:
> 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
>
>
