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). 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). 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? > 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. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
