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