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