Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82781
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.220.41 cause and error)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLvtMVZz6f=MXckg55tpGR1CdozOLdn=+oGVjkC=6+XdRQ@mail.gmail.com>
References: <CA+9eiLvtMVZz6f=MXckg55tpGR1CdozOLdn=+oGVjkC=6+XdRQ@mail.gmail.com>
Date: Mon, 16 Feb 2015 07:16:15 +0000
Message-ID: <CAL=_i_n-h79q4+fXoNnSiaii7CnOBJXwBH2FR0KCwX4dmbcs6w@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, Zeev Suraski <zeev@zend.com>, Andrea Faulds <ajf@ajf.me>, 
	Patrick ALLAERT <patrickallaert@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10cb03a6e69a050f2f5c18
Subject: Re: [PHP-DEV] PHP JIT or AOT
From: pthreads@pthreads.org (Joe Watkins)

--047d7b10cb03a6e69a050f2f5c18
Content-Type: text/plain; charset=UTF-8

Morning,

I'm not sure where this conversation started ...

> where in non-strict mode you still need
> to generation runtime conversion logic. That runtime conversion logic
> then requires the ability to hook into Zend's error handling
> mechanism, vastly complicating the generated code (and the generating
> code).

Why do you need to generate conversion logic, why can't you call Zend API
functions ?

Alternatively, possibly preferably, wouldn't a guard to tell if the
function is being called in strict mode
be a good idea here ?

If the generated code is really complicated and that sucks away the
performance
then why not just avoid it, and only enter machine code when a function is
called in strict mode ?

I see the assembly generated by your JIT, but it doesn't really tell us
much, it tells us a little,
what would be really useful is seeing your research, with the understanding
that it is just research.
Please think about that again.

Cheers
Joe

On Mon, Feb 16, 2015 at 6:59 AM, Dmitry Stogov <dmitry@zend.com> wrote:

> On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara <ircmaxell@gmail.com>
> wrote:
>
> > Dmitry,
> >
> > On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> > > Hi Anthony,
> > >
> > > If you are working on JIT, you should understand that declare() switch
> to
> > > strict typing can't improve anything, because it works on caller side
> > and in
> > > each function you now will have to generate code for both weak and
> strict
> > > checks.
> >
> > Well, if you know the destination function at compile time, you don't
> > need to generate generic code. you can generate a direct dispatch
> > (asm-level function call).
>
>
> Right, but in real life app you almost never know what function or method
> you are really call. At function you also can't be sure that it always
> called with proper arguments. This work well only for plain function placed
> into a single PHP file.
>
>
> >   In this case, strict lets you push type
> > checks back to compile time, where in non-strict mode you still need
> > to generation runtime conversion logic. That runtime conversion logic
> > then requires the ability to hook into Zend's error handling
> > mechanism, vastly complicating the generated code (and the generating
> > code).
> >
>
> For cases when you know the called function and all passed and expected
> types, it's possible to use more efficient calling convention passing real
> arguments in CPU registers.
>
> The type checks in PHP7 is quite cheap (2-3 CPU instructions). Strict or
> weak check doesn't make any difference for "fast path" (the same 2-3
> instructions). The slow patch for weak checks is going to be a bit more
> expensive.
>
>
> >
> > In fact, the research I have been doing is precisely around that
> > (where I know for a fact that all remaining function calls are going
> > to be typed, and compile the entire block at one time with direct
> > calls). So that way I never need to actually do even as much as a FCC
> > to call a userland function. Which then lets me avoid generating
> > typing code (since I know the types). Which is why I'm advocating for
> > strict, since that way we can treat an entire graph of function calls
> > as strict and compile them all in one go (no need to even JIT at
> > runtime, just compile AOT).
> >
> > If your research has shown something different, care to share?
> >
>
> Very similar :), but in cases when we know the called function the effect
> from type hinting is negligible. It's almost always possible to generate
> optimal code without any hints.
>
> See code for fibo_r() from bench.php generated by our old JIT for PHP-5.5
> (without type hinting):
> https://gist.github.com/dstogov/5f71d23f387332e9d77c
>
> Unfortunately, we didn't make the same for PHP7 yet.
> More important, in our experiments we saw improvements only on small
> benchmarks (e.g. 25 times on mandelbrot), but nothing on real-life apps.
>
> So a some point, looking into ASM code that endlessly allocates and frees
> zvals, we switched to engine re-factoring.
>
>
> >
> > > According to mandel() and integer to float conversion in the loop, it's
> > > possible to perform a backward data-propagation pass to catch this case
> > and
> > > replace integer by float in first place. We did it in our old JIT
> > prototypes
> > > without any type hinting. Also, don't use "fild", use SSE2 and/or AVX.
> >
> > I did wind up doing a few passes to back-propagate the cast (among
> > other optimizations). But it's still a point that the conversions
> > aren't exactly cheap. But as I said before, that was a side-note and
> > not really an argument for/against strict typing. So worth mentioning,
> > but shouldn't affect anyone's decision.
> >
> > Re fild vs SSE/AVX: that was up to the backend code generator we were
> > using (libjit). It may be an open req against that lib to generate the
> > different instruction, or perhaps it just failed a heuristic. We were
> > working a level higher than the generated ASM, so not really 100% sure
> > why it made that decision.
> >
>
> I saw a big speed difference between FPU and SSE2/AVX code on bench.php, so
> if you may tell libjit to use SSE2/AVX - do it.
>
> Thanks. Dmitry.
>
>
>
>
> >
> > Anthony
> >
>

--047d7b10cb03a6e69a050f2f5c18--