Morning, I'm not sure where this conversation started ...
> 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 ? Alternatively, possibly preferably, wouldn't a guard to tell if the function is being called in strict mode be a good idea here ? 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. 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 > > >
