On Feb 22, 2015 6:07 PM, "Joe Watkins" <pthre...@pthreads.org> wrote:
>
> > 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.
PHP7 interpreter skips RECV instructions without type hints, because they
do nothing.
with type hints, they may perform checks and conversion.
>
> 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.
in both cases code is similar - an additional call on slow path
if (UNEXPECTED(!valid_type(arg)) {
// slow path
zend_error(...) or convert_to_type(arg);
}
The problem with run-time switch is the fact that we will have to generate
additional check and both calls in slow patch. This is why I'm against the
run-time declare() switch.
>
> 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.
Strictness is defined on call-site. So when you compile a function, you
don't know with what semantic it's going to be called. Now think about
different declare(strict) setting in different files and call chain. Do you
see the mess? :)
>
> > 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 think our approches were very similar and leaded us to simular decisions,
however we alredy tried jit-ing bench.php with type hints (strict). While
JIT itselv makes bench.php about 5 times faster, type hints adds about 2%.
Strict or weak make no difference at all.
>
> 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.
We are going to open our work soon, but we are not going to work on it
actevely, because all the forces at PHP7.
Thanks. Dmitry.
>
> 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
> >
> >
