# PHP JIT or AOT - Thread: https://externals.io/message/82779 - Original archive: https://news-web.php.net/php.internals/82779 - Started by Dmitry Stogov on 2015-02-16T06:59:31+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #82779 — Dmitry Stogov — 2015-02-16T06:59:31+00:00 URL: https://externals.io/message/82779#82779 On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara wrote: > Dmitry, > > > > […] > and in > > […] > > 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. > > > […] > and > > […] > prototypes > > […] > > 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 --- ## #82781 — Joe Watkins — 2015-02-16T07:16:15+00:00 URL: https://externals.io/message/82779#82781 · In reply to: #82779 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 12:45 AM, Anthony Ferrara > wrote: > > > […] > to > > […] > strict > > […] > > > 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. > > > > […] > > 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. > > > > […] > > 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. > > > > […] > > 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. > > > > > > […] --- ## #82784 — Dmitry Stogov — 2015-02-16T07:32:23+00:00 URL: https://externals.io/message/82779#82784 · In reply to: #82781 > Morning, > > I'm not sure where this conversation started ... > it's a fork from "Salar Type Hints"... > > > […] > > 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 > > > > > […] --- ## #82788 — Netroby — 2015-02-16T07:55:53+00:00 URL: https://externals.io/message/82779#82788 · In reply to: #82784 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 : > > > > […] > > it's a fork from "Salar Type Hints"... > > > > […] > > Even VM just calls a conversion function. > > Alternatively, possibly preferably, wouldn't a guard to tell if the > > […] > > 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. > > > > […] > > 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. > > > > […] --- ## #82789 — Joe Watkins — 2015-02-16T08:00:55+00:00 URL: https://externals.io/message/82779#82789 · In reply to: #82788 It's Monday morning, maybe I'm misunderstanding ... > 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 We'll always know the types of arguments at the call site surely ? It's knowing the types at the location being called that is important, and needed in order to eliminate checks, isn't it ? Cheers Joe > 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 : > > […] > wrote: > > […] > API > > […] > anyway. > > […] > is > > […] > life. > > […] > JIT/AOT > > […] > wrote: > > […] > side > > […] > method > > […] > real > > […] > or > > […] > effect > > […] > generate > > […] > PHP-5.5 > > […] > apps. > > […] > frees > > […] > AVX. > > […] > mentioning, > > […] > the > > […] > sure > > […] > bench.php, > > […] --- ## #82790 — Joe Watkins — 2015-02-16T08:01:47+00:00 URL: https://externals.io/message/82779#82790 · In reply to: #82789 > I would be glad, if later we'll combine our experience and work on JIT/AOT together. This is obviously something I look forward too :) Cheers Joe > It's Monday morning, maybe I'm misunderstanding ... > > > […] > types of passed arguments, then we may eliminate checks at all > > We'll always know the types of arguments at the call site surely ? It's > knowing the types at the location being called that is important, > and needed in order to eliminate checks, isn't it ? > > Cheers > Joe > > > > > […] --- ## #82796 — Dmitry Stogov — 2015-02-16T09:10:20+00:00 URL: https://externals.io/message/82779#82796 · In reply to: #82789 > It's Monday morning, maybe I'm misunderstanding ... > may be I'm too :) > > > […] > types of passed arguments, then we may eliminate checks at all > > We'll always know the types of arguments at the call site surely ? > not always. For "foo(bar())" the type of argument passed to foo() may be unknown at compile-time, similar to foo($a[0]) or foo($a->prop). > It's knowing the types at the location being called that is important, > and needed in order to eliminate checks, isn't it ? > Right, but it's not always possible to know the types at compile time, and in this case hints may be helpful, however, strict and week hints give exactly the same information - they guarantee the type of argument inside the function. Thanks. Dmitry. > > Cheers > Joe > > > > > […] --- ## #82845 — Anthony Ferrara — 2015-02-16T13:47:54+00:00 URL: https://externals.io/message/82779#82845 · In reply to: #82779 Dmitry and Joe, > > > On Mon, Feb 16, 2015 at 12:45 AM, Anthony Ferrara > wrote: > > […] > > > 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. I'm not talking about compiling an entire real-life application. I'm talking about compiling hot-corners. For an application like WP, that may not be possible. But with some light refactoring it may definitely be possible with a large portion of applications. The reason I'm talking about that instead of a generic compiler is that the simpler the intermediary form (the more we can assume and throw away) the more aggressive the optimizations can become. In the long run, I can see a highly optimizing AOT compiler living along side of a local/tracing JIT compiler. The JIT would handle more dynamic 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. Well, not really. It's 2-3 CPU instructions once you have the instructions for dealing with ZVALs. The concept I'm talking is having the AOT compiler not know anything about a ZVAL (except perhaps at an FFI level). So yes, it's 2-3 CPU instructions to check type, but it's also a branch. It's also more memory and values to keep track of. It's far more code to generate. > > […] > > > 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. It's always possible to generate optimal PHP code. But I want to generate optimal ASM code. And for that, I need type guarantees. > 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. Which for generic code, is amazing. And I'm all for optimizing dynamic code. You're going to get an overall big gain doing that. I just see a bigger gain is possible given some preconditions, and would love to see them working together. > > […] > > > 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. Yeah, I'm not sure it's worth it at this stage, but will definitely keep in mind. > Right, but it's not always possible to know the types at compile time, > and in this case hints may be helpful, however, strict and week hints give > exactly the same information - they guarantee the type of argument inside > the function. Well, yes. However it also means that inside the function dynamic types (variables that change type) are fine, and you need to implement the conversion logic. Therefore you need to implement ZVAL abstractions in the compiler. Something I really want to avoid, as it exponentially raises the complexity that you need to handle. > Why do you need to generate conversion logic, why can't you call > Zend API functions ? We definitely can. However there are 2 problems with that. First the compiler must know and use the ZVAL abstraction (including the possibility of type change). The second is that we need to support the error mechanisms and the generated code needs to be aware of the engine state (for example, to implement try/catch, etc). Definitely possible, but also greatly increases complexity... Strict typing makes those cases compile-time errors, and therefore we don't need to handle it at all in the generated code. Thanks Anthony --- ## #82846 — Dmitry Stogov — 2015-02-16T14:12:30+00:00 URL: https://externals.io/message/82779#82846 · In reply to: #82845 > > […] > > Well, not really. It's 2-3 CPU instructions once you have the > instructions for dealing with ZVALs. The concept I'm talking is having > the AOT compiler not know anything about a ZVAL (except perhaps at an > FFI level). So yes, it's 2-3 CPU instructions to check type, but it's > also a branch. It's also more memory and values to keep track of. It's > far more code to generate. > This is code for week type check: cmpb Z_TYPE_P(%edx), IS_LONG je slow_path L1: addl Z_LVAL_P(%edx), %eax .... slow_path: movl %edx, (%esp) call convert_to_long jmp L1 This is code for strict type check: cmpb Z_TYPE_P(%edx), IS_LONG je slow_path L1: addl Z_LVAL_P(%edx), %eax .... slow_path: movl %edx, (%esp) ... call zend_error jmp L1 ; we still have to support E_RECOVERABLE, so we may return back No big difference... > > > […] > > It's always possible to generate optimal PHP code. But I want to > generate optimal ASM code. And for that, I need type guarantees. > Doesn't week type hint make the same guarantee as strong? It just makes conversion on mismatch. > > > […] > https://gist.github.com/dstogov/5f71d23f387332e9d77c > > […] > > Which for generic code, is amazing. And I'm all for optimizing dynamic > code. You're going to get an overall big gain doing that. I just see a > bigger gain is possible given some preconditions, and would love to > see them working together. > I'm looking forward as well :) Just busy with other things now. > > > […] > it's > > […] > case > > […] > so > > […] > > Yeah, I'm not sure it's worth it at this stage, but will definitely > keep in mind. > > > […] > give > > […] > > Well, yes. However it also means that inside the function dynamic > types (variables that change type) are fine, and you need to implement > the conversion logic. Therefore you need to implement ZVAL > abstractions in the compiler. Something I really want to avoid, as it > exponentially raises the complexity that you need to handle. > We had different goals and may misunderstand each other. We tried to make 100% transparent JIT for PHP that would able to run any code. Thanks. Dmitry. > > […] > > We definitely can. However there are 2 problems with that. First the > compiler must know and use the ZVAL abstraction (including the > possibility of type change). The second is that we need to support the > error mechanisms and the generated code needs to be aware of the > engine state (for example, to implement try/catch, etc). Definitely > possible, but also greatly increases complexity... Strict typing makes > those cases compile-time errors, and therefore we don't need to handle > it at all in the generated code. > > Thanks > > Anthony --- ## #82847 — Anthony Ferrara — 2015-02-16T14:21:23+00:00 URL: https://externals.io/message/82779#82847 · In reply to: #82846 Dmitry, > > > […] > > > > This is code for week type check: > > cmpb Z_TYPE_P(%edx), IS_LONG > je slow_path > L1: > addl Z_LVAL_P(%edx), %eax > > .... > > slow_path: > movl %edx, (%esp) > call convert_to_long > jmp L1 > > This is code for strict type check: > > cmpb Z_TYPE_P(%edx), IS_LONG > je slow_path > L1: > addl Z_LVAL_P(%edx), %eax > > .... > > slow_path: > movl %edx, (%esp) > ... > call zend_error > jmp L1 ; we still have to support E_RECOVERABLE, so we may return back > > No big difference... The code I'm talking about generating is: addl %edx %eax No jumps, no type extraction, because it happened at compile time (and strict lets us do that since we can determine types 100% at compile time since dynamic types become errors). So it's a significant difference (1 less conditional jump, 1 less unconditional jump, 1 less comparison, a number less operations, etc). > > […] > > > Doesn't week type hint make the same guarantee as strong? > It just makes conversion on mismatch. No, because I still need to promote back up to ZVAL before calling another function (since the type conversion is allowed). Therefore I cant error on type conversion, I need to generate the code to handle it. > > […] > > > I'm looking forward as well :) > Just busy with other things now. > > > […] > > > We had different goals and may misunderstand each other. > We tried to make 100% transparent JIT for PHP that would able to run any > code. I think the high-level goals are the same, but yes, the low level goals are very different. I see we compliment each other rather than oppose. Which is why I am excited by it :-). Thanks for the discussion :-) Anthony --- ## #82858 — Dmitry Stogov — 2015-02-16T15:56:50+00:00 URL: https://externals.io/message/82779#82858 · In reply to: #82847 On Mon, Feb 16, 2015 at 5:21 PM, Anthony Ferrara wrote: > Dmitry, > > > > […] > or > > […] > more > > […] > back > > […] > > The code I'm talking about generating is: > > addl %edx %eax > > No jumps, no type extraction, because it happened at compile time (and > strict lets us do that since we can determine types 100% at compile > time since dynamic types become errors). > So it's a significant difference (1 less conditional jump, 1 less > unconditional jump, 1 less comparison, a number less operations, etc). > If we know the type at compile-time we don't check it as well. If you don't know it at compile-time you have to check it at run-time to catch the error. > > […] > generate > > […] > > No, because I still need to promote back up to ZVAL before calling > another function (since the type conversion is allowed). Therefore I > cant error on type conversion, I need to generate the code to handle > it. > I see the difference now, but your approach won't work for all cases (like call through zend_call_user_func). It should be explained again by a bit different goals. Thanks. Dmitry. > > > […] > apps. > > […] > mentioning, > > […] > the > > […] > sure > > […] > bench.php, > > […] > > I think the high-level goals are the same, but yes, the low level > goals are very different. I see we compliment each other rather than > oppose. Which is why I am excited by it :-). > > Thanks for the discussion :-) > > Anthony