> I would be glad, if later we'll combine our experience and work on JIT/AOT together.
This is obviously something I look forward too :) Cheers Joe On Mon, Feb 16, 2015 at 8:00 AM, Joe Watkins <pthre...@pthreads.org> wrote: > It's Monday morning, maybe I'm misunderstanding ... > > > 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 > > We'll always know the types of arguments at the call site surely ? It's > knowing the types at the location being called that is important, > and needed in order to eliminate checks, isn't it ? > > Cheers > Joe > > On Mon, Feb 16, 2015 at 7:55 AM, Netroby <hufeng1...@gmail.com> wrote: > >> 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 <dmi...@zend.com>: >> > On Mon, Feb 16, 2015 at 10:16 AM, Joe Watkins <pthre...@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 <dmi...@zend.com> >> wrote: >> >> >> >>> On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara < >> ircmax...@gmail.com> >> >>> wrote: >> >>> >> >>> > Dmitry, >> >>> > >> >>> > On Sun, Feb 15, 2015 at 1:43 PM, Dmitry Stogov <dmi...@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 >> >>> > >> >>> >> >> >> >> >> > >
