Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82788
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLub7hLwEEMqzs-v6Lo-akh6HAAq_9rSQ3S8OyXYcusNkA@mail.gmail.com>
References: <CA+9eiLvtMVZz6f=MXckg55tpGR1CdozOLdn=+oGVjkC=6+XdRQ@mail.gmail.com>
 <CAL=_i_n-h79q4+fXoNnSiaii7CnOBJXwBH2FR0KCwX4dmbcs6w@mail.gmail.com> <CA+9eiLub7hLwEEMqzs-v6Lo-akh6HAAq_9rSQ3S8OyXYcusNkA@mail.gmail.com>
Date: Mon, 16 Feb 2015 15:55:53 +0800
Message-ID: <CAEZo+gc5W+ZspKZqbqNWayWkiA-1BSh+=YRoHgu+nfjuKNLvag@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Joe Watkins <pthreads@pthreads.org>, 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: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] PHP JIT or AOT
From: hufeng1987@gmail.com (Netroby)

I guess we can gave a try. PHP 7 is fine well enough. let's working
hard to make it published.

The talk about other things should be early . let's see PHP 7 released
and see how it will change our world.

Code it , ship it. Let's see the result.

Appreciate your time.
----------------------------
Netroby


2015-02-16 15:32 GMT+08:00 Dmitry Stogov <dmitry@zend.com>:
> On Mon, Feb 16, 2015 at 10:16 AM, Joe Watkins <pthreads@pthreads.org> wrote:
>
>> Morning,
>>
>> I'm not sure where this conversation started ...
>>
>
> it's a fork from "Salar Type Hints"...
>
>
>>
>> > 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 ?
>>
>
> Even VM just calls a conversion function.
>
> Alternatively, possibly preferably, wouldn't a guard to tell if the
>> function is being called in strict mode
>> be a good idea here ?
>>
>
> If we know what function is called in strict mode, we must already know
> where it's called from, so we should also know the types of passed
> arguments, then we may eliminate checks at all (independently on
> strictness). If we don't know the types we will need to check them anyway.
>
>
>> 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.
>>
>
> Yeah, we will need to open it, even if it doesn't make gain for real life.
> but lets make all the PHP7 related work first.
> I would be glad, if later we'll combine our experience and work on JIT/AOT
> together.
>
> Thanks. Dmitry.
>
>
>>
>> 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
>>> >
>>>
>>
>>