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 >
