[I hope I managed to get the threading right although I think it's more
than likely I didn't;  apologies in advance if that's the case]

> -----Original Message-----
> From: Joe Watkins [mailto:pthre...@pthreads.org]
> Sent: Sunday, February 22, 2015 5:07 PM
> To: Jefferson Gonzalez
> Cc: Etienne Kneuss; Anthony Ferrara; Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> > 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.

Can we take a hint from youtu.be/9MV1ot9HkPg please? :)

> 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.

Can you explain how so, assuming you know the same about what's waiting on
the stack in both cases?  If you know they're already ints, you can
optimize the function to take this assumption into account - identically -
in both the case of a strict or dynamic hint (and as a matter of fact,
even if there's no hint at all).  If, however, you don't know what's
waiting on the stack - you would have to conduct checks in both cases.
Sure, the checks are different - but the difference between them is
behavioral, semantic - not performance related.

> This is an inescapable difference, of the the kind that definitely does
have a
> negative impact on implementation complexity, runtime, and
maintainability.

This inescapable difference somehow manages to escape a bunch of people
here, myself included...

> 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.

I'll have to disagree with that statement.  I'm not yet sure what we can
achieve with JIT in real world PHP web apps, but I've seen enough to know
that with JIT, certain use cases which are impractical today due to
performance (mainly data crunching) suddenly become viable.  And that's
with no STH at all, strict or otherwise.  Our JIT POC runs bench.php 25
times faster than PHP 7, without a single byte changed in the source (no
typo, 25 times faster, not 25%).  Unfortunately, most real world app code
doesn't look anything like what bench.php does - but it should illustrate
the point about the viability of JIT/AOT for dynamic platforms.

To take another example, JavaScript is extremely lax, are you suggesting
that it doesn't make sense to use JIT with JavaScript?  JIT made JS
performance literally explode, without changing the language to be strict.

If what you can already discern from dynamic type inference (which is
quite a lot, as JS proves) isn't enough for you - what you need isn't some
specific kind of type hinting (strict or otherwise) - but more tools to
tell what the type is in situation where today you can't (or find it hard
to) infer it.  Strictly typed variable declarations would be one such
thing, changing how our operators work to be more strict would be another
(for the record, I'm absolutely not suggesting we do that!).  In short,
changing PHP to be a much more strongly typed language than it is today,
with or without Strict STH.

> > 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?
>
> 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),

I don't see how that's possible, unless you add facilities such as the
ones I mentioned above.  If that's the goal, I think it should be clearly
stated.  Without that, you need the exact same type inference with strict
and weak types in order to develop useful JIT/AOT.

>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.

The difference is really not about what kind of JIT implementation anyone
prefers to have, but what kind of language behavior it's going to have to
address.  Trust me, I can tell you with absolute confidence that anybody
who writes a JIT engine - Dmitry and JS engine devs included - would
prefer to have the types just handed to him, rather than have to infer it.
Type inference is hard.  But that would be the task at hand.

Thanks,

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to