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