# Zend JIT Open Sourced - Thread: https://externals.io/message/83994 - Original archive: https://news-web.php.net/php.internals/83994 - Started by Dmitry Stogov on 2015-02-27T12:10:37+00:00 - Messages: 45 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/83994.md?page=2 - 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 --- ## #83994 — Dmitry Stogov — 2015-02-27T12:10:37+00:00 URL: https://externals.io/message/83994#83994 Hi, With the recent discussions of JIT/AOT and the good progress we made on PHP-7, we decided to open up the JIT experiment we've been working on. https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit You may just clone or pull zend-jit branch and compile/configure according to instruction. Don't merge it with master. It may work today but will stop working tomrrow. Disclaimers: - It's an experiment, and is not in any way ready for anything. In the future we may try to implement JIT quite different from this PoC. - I'm not planning to invest into it in the near future. (PHP-7 takes all my time) Consider it available for academic purposes only at this point. Enjoy! Thanks. Dmitry. --- ## #83996 — Joe Watkins — 2015-02-27T12:38:39+00:00 URL: https://externals.io/message/83994#83996 · In reply to: #83994 Dmitry, Thanks for the opportunity to read, that's cool ;) Cheers Joe > Hi, > > With the recent discussions of JIT/AOT and the good progress we made on > PHP-7, we decided to open up the JIT experiment we've been working on. > > https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit > > You may just clone or pull zend-jit branch and compile/configure according > to instruction. Don't merge it with master. It may work today but will stop > working tomrrow. > > Disclaimers: > > - It's an experiment, and is not in any way ready for anything. > In the future we may try to implement JIT quite different from this PoC. > > - I'm not planning to invest into it in the near future. (PHP-7 takes all > my time) > Consider it available for academic purposes only at this point. > > Enjoy! > > Thanks. Dmitry. --- ## #84010 — Anthony Ferrara — 2015-02-27T15:12:41+00:00 URL: https://externals.io/message/83994#84010 · In reply to: #83994 Dmitry and Zend, Thank you for sharing your code. I look forward to playing with it. Perhaps after 7 stabilizes (and ships) you could write up your thoughts around it? Why decisions were made and the findings that you have? Thanks again Anthony > Hi, > > With the recent discussions of JIT/AOT and the good progress we made on > PHP-7, we decided to open up the JIT experiment we've been working on. > > https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit > > You may just clone or pull zend-jit branch and compile/configure according > to instruction. Don't merge it with master. It may work today but will stop > working tomrrow. > > Disclaimers: > > - It's an experiment, and is not in any way ready for anything. > In the future we may try to implement JIT quite different from this PoC. > > - I'm not planning to invest into it in the near future. (PHP-7 takes all my > time) > Consider it available for academic purposes only at this point. > > Enjoy! > > Thanks. Dmitry. --- ## #84012 — Andi Gutmans — 2015-02-27T15:19:57+00:00 URL: https://externals.io/message/83994#84012 · In reply to: #84010 > > > Dmitry and Zend, > > Thank you for sharing your code. I look forward to playing with it. > > Perhaps after 7 stabilizes (and ships) you could write up your > thoughts around it? Why decisions were made and the findings that you > have? Yes I think we can definitely do that. It is an interesting experiment and clarified also that JIT was less interesting in the short term as we can all observe by the fabulous results of the current PHP 7 runtime. But absolutely worth discussing post 7 as there surely are interesting opportunities. Andi > Thanks again > > Anthony > > > […] --- ## #84013 — Sebastian Bergmann — 2015-02-27T15:22:54+00:00 URL: https://externals.io/message/83994#84013 · In reply to: #84010 Am 27.02.2015 um 16:12 schrieb Anthony Ferrara: > Thank you for sharing your code. I look forward to playing with it. > > Perhaps after 7 stabilizes (and ships) you could write up your > thoughts around it? Why decisions were made and the findings that you > have? What Joe and Anthony said :-) Thanks for sharing this with the community and I'll be looking forward to the promised documentation of decisions etc. --- ## #84021 — Jordi Boggiano — 2015-02-27T15:40:35+00:00 URL: https://externals.io/message/83994#84021 · In reply to: #84012 > > > […] > > Yes I think we can definitely do that. It is an interesting experiment and clarified also that JIT was less interesting in the short term as we can all observe by the fabulous results of the current PHP 7 runtime. But absolutely worth discussing post 7 as there surely are interesting opportunities. Do you have a one line summary of why it's useless for real world applications? Is it just because they don't do enough number crunching compared to I/O or is it a matter of the JIT not kicking in fast enough to improve things in a single request cycle? I am biased but if it improves the bench code so much it still sounds like a potentially good things for specific code like the composer dependency solver :) Cheers --- ## #84023 — Dmitry Stogov — 2015-02-27T15:56:10+00:00 URL: https://externals.io/message/83994#84023 · In reply to: #84021 > > > > […] > > Do you have a one line summary of why it's useless for real world > applications? Is it just because they don't do enough number crunching > compared to I/O or is it a matter of the JIT not kicking in fast enough to > improve things in a single request cycle? > It's not a single request cycle. JIT integrated into opcache, it compiles php script(s) of first access and stores code in shared memory. On following requests precompiled code is executed directly from shared memory. - The first request may be extremely slow (few minutes) - The speed improvement on the following request may be insignificant or even negative. It very depends on application, but from my experience only small apps got significant improvements. This may be explained by huge increase in ICACHE and ITLB misses, but I'm not 100% sure. > I am biased but if it improves the bench code so much it still sounds like > a potentially good things for specific code like the composer dependency > solver :) > Yeah. Probably, if we position this work as a JIT for hotspots only, or even enable it for some functions manually we may get better results. Thanks. Dmitry, > > Cheers --- ## #84025 — Rowan Collins — 2015-02-27T16:20:30+00:00 URL: https://externals.io/message/83994#84025 · In reply to: #84023 Dmitry Stogov wrote on 27/02/2015 15:56: > > > > […] > It's not a single request cycle. JIT integrated into opcache, it compiles > php script(s) of first access and stores code in shared memory. > On following requests precompiled code is executed directly from shared > memory. This reminds me of an idea I had a while ago - with OpCache, and potentially JIT, relying on shared memory for optimisations, command-line scripts (e.g. background processing via cron or supervisord) are getting left behind in terms of performance. So I wonder if it would be possible to implement a "FastCLI" application server similar to FastCGI, which could be sent multiple requests representing POSIX command invocations, and serve them from a threaded environment. So instead of "php composer.phar install", you'd run "php-fastcli --port 55555 composer.phar install", which would "attach" to a running FastCLI server. Has anyone ever looked at such a thing? It seems like it would be useful for other languages as well, in exactly the way FastCGI is. Regards, -- Rowan Collins [IMSoP] --- ## #84026 — Anthony Ferrara — 2015-02-27T16:30:44+00:00 URL: https://externals.io/message/83994#84026 · In reply to: #84023 Dmitry, > It's not a single request cycle. JIT integrated into opcache, it compiles > php script(s) of first access and stores code in shared memory. > On following requests precompiled code is executed directly from shared > memory. > > - The first request may be extremely slow (few minutes) That sounds more along the lines of AOT like I did with Recki rather than a true JIT (which compiles when a function is called). Judging from the jit_init() function, it appears like you're compiling the entire codebase ahead of time. Is that correct? Anthony --- ## #84032 — Dmitry Stogov — 2015-02-27T17:31:11+00:00 URL: https://externals.io/message/83994#84032 · In reply to: #84026 On Fri, Feb 27, 2015 at 7:30 PM, Anthony Ferrara wrote: > Dmitry, > > > > […] > > That sounds more along the lines of AOT like I did with Recki rather > than a true JIT (which compiles when a function is called). > > Judging from the jit_init() function, it appears like you're compiling > the entire codebase ahead of time. > > Is that correct? > Right now it compiles script (php file) at once. So yes, our JIT uses some kind of AOT approach, but completely transparently for the rest of PHP. We also tried few different approaches to collect formation about hot functions and generate code only for them. Unfortunately, this didn't change the picture. Thanks. Dmitry. > > Anthony --- ## #84033 — Zeev Suraski — 2015-02-27T17:39:29+00:00 URL: https://externals.io/message/83994#84033 · In reply to: #84032 > -----Original Message----- > From: Dmitry Stogov [mailto:dmitry@zend.com] > Sent: Friday, February 27, 2015 7:31 PM > To: Anthony Ferrara > Cc: Jordi Boggiano; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > On Fri, Feb 27, 2015 at 7:30 PM, Anthony Ferrara > wrote: > > > […] > > Right now it compiles script (php file) at once. > So yes, our JIT uses some kind of AOT approach, but completely > transparently for the rest of PHP. Just to slightly further clarify - we don't compile the whole codebase at once, but we keep the existing semantics that every file is independent, may change independently of other files, and include() may end up load one file in one flow and another one in another flow. There's isn't any cross-file optimization. > We also tried few different approaches to collect formation about hot > functions and generate code only for them. > Unfortunately, this didn't change the picture. (again, the picture being no performance gains in common Web apps). Zeev --- ## #84035 — Pierre Joye — 2015-02-27T18:16:54+00:00 URL: https://externals.io/message/83994#84035 · In reply to: #83994 hi, > Hi, > > With the recent discussions of JIT/AOT and the good progress we made on > PHP-7, we decided to open up the JIT experiment we've been working on. > > https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit > > You may just clone or pull zend-jit branch and compile/configure according > to instruction. Don't merge it with master. It may work today but will stop > working tomrrow. > > Disclaimers: > > - It's an experiment, and is not in any way ready for anything. > In the future we may try to implement JIT quite different from this PoC. > > - I'm not planning to invest into it in the near future. (PHP-7 takes all > my time) > Consider it available for academic purposes only at this point. Fantastic move! The way to do it! Thanks a lot!. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #84036 — Anthony Ferrara — 2015-02-27T18:55:27+00:00 URL: https://externals.io/message/83994#84036 · In reply to: #84033 Zeev, > > […] > > Just to slightly further clarify - we don't compile the whole codebase at > once, but we keep the existing semantics that every file is independent, may > change independently of other files, and include() may end up load one file > in one flow and another one in another flow. There's isn't any cross-file > optimization. > > > […] > > (again, the picture being no performance gains in common Web apps). Well, I just want to make one clarification here to your point: there's no performance gains to this AOT approach for common web apps. It's not really fair to judge a true JIT implementation based on this because it lacks crucial runtime information that a real JIT compiler would have (such as input types, values, etc). So it would be left generating generic native code instead of specific code. I just want to point out that the results here aren't really applicable to a JIT approach. And that should be made clear when discussing it. That's not to say there's anything wrong with this approach, nor that there isn't a ton we can learn from it. I think it's a fantastic research effort and plan on digging through it myself. Thank you for open sourcing it. Anthony --- ## #84037 — Dmitry Stogov — 2015-02-27T19:20:44+00:00 URL: https://externals.io/message/83994#84037 · In reply to: #84036 On Fri, Feb 27, 2015 at 9:55 PM, Anthony Ferrara wrote: > Zeev, > > > […] > may > > […] > file > > […] > cross-file > > […] > > Well, I just want to make one clarification here to your point: > there's no performance gains to this AOT approach for common web apps. > > It's not really fair to judge a true JIT implementation based on this > because it lacks crucial runtime information that a real JIT compiler > would have (such as input types, values, etc). So it would be left > generating generic native code instead of specific code. I just want > to point out that the results here aren't really applicable to a JIT > approach. And that should be made clear when discussing it. > Nobody talk about JIT in general, only about this PoC. And yes, some other approaches may provide better gain. At least I think so. However, we may just guess, until implement them. > That's not to say there's anything wrong with this approach, nor that > there isn't a ton we can learn from it. I think it's a fantastic > research effort and plan on digging through it myself. Thank you for > open sourcing it. > Thanks for good words :) This work may be adopted for some specific cases. 25-30 times speedup on Mandelbrot allows usage for numeric calculation instead of C. https://gist.github.com/dstogov/12323ad13d3240aee8f1 anyone may repeat the language battle :) Thanks. Dmitry. > > Anthony --- ## #84038 — Anthony Ferrara — 2015-02-27T19:36:07+00:00 URL: https://externals.io/message/83994#84038 · In reply to: #84037 Dmitry, > > […] > > > Thanks for good words :) > > This work may be adopted for some specific cases. > 25-30 times speedup on Mandelbrot allows usage for numeric calculation > instead of C. > > https://gist.github.com/dstogov/12323ad13d3240aee8f1 > > anyone may repeat the language battle :) These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, it's possible. But I don't think it's likely. It really smells to me like bias in the testing methodology. (and the lack of an -O3 result is suspicious as well). And looking at the code, I can see why. The PHP version is writing to an internal buffer, while every other version has to write to `STDOUT` on every single iteration. So you are intentionally not benchmarking the output in the PHP version (you even explicitly call `ob_start()`) but are benchmarking it in every other version. So in fact, the PHP code does something different than the rest of the code. Sneaky sneaky. Also completely fake. A proper methodology would have explicitly disabled any buffer so that the tests all tested the same thing. Or even better, build up an internal buffer in all of the implementations. That way you can compare the computation and not rely on `STDOUT` (terminal) response. Anthony --- ## #84039 — Dmitry Stogov — 2015-02-27T19:57:13+00:00 URL: https://externals.io/message/83994#84039 · In reply to: #84038 On Fri, Feb 27, 2015 at 10:36 PM, Anthony Ferrara wrote: > Dmitry, > > > […] > > These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, > it's possible. But I don't think it's likely. It really smells to me > like bias in the testing methodology. (and the lack of an -O3 result > is suspicious as well). > No. it true, but of course it's not 100% fair. gcc compiles files for x86 or x86_64 platform in general. When we compile in run-time we may relay on knowledge of our CPU. In this case LLVM generates AVX instructions, while gcc SSE2. Looking into assembler code, you may see that PHP even not inferred type of all variables and makes few unnecessary check in the loop, but modern CPU are so smart that the code looking mach worse work with the same speed as (gcc -O2). Unfortunately it works in the other direction as well. gcc -O2 -mavx will outperform us :) > > And looking at the code, I can see why. The PHP version is writing to > an internal buffer, while every other version has to write to `STDOUT` > on every single iteration. > > So you are intentionally not benchmarking the output in the PHP > version (you even explicitly call `ob_start()`) but are benchmarking it > in every other version. So in fact, the PHP code does something > different than the rest of the code. > > Sneaky sneaky. Also completely fake. A proper methodology would have > explicitly disabled any buffer so that the tests all tested the same > thing. Or even better, build up an internal buffer in all of the > implementations. That way you can compare the computation and not rely > on `STDOUT` (terminal) response. > this also may make some difference, but I think PHP stream layer is not as good as C. just profile it with Linux perf, oprofile, callgrind, ... perf record perf report -n Thanks. Dmitry > > Anthony --- ## #84040 — Anthony Ferrara — 2015-02-27T20:21:24+00:00 URL: https://externals.io/message/83994#84040 · In reply to: #84038 Dmitry, > Sneaky sneaky. Also completely fake. It's been brought to my attention that some people have taken what I said completely out of context and insinuated it as a direct insult to you. I assure you that was not the intent (I called the benchmark sneaky and fake, which it is). So if you interpreted it as an insult, I apologize sincerely. I did not intend to insult you personally at all with that remark. It was only meant as a comment about the code that was posted. Anthony --- ## #84041 — Dmitry Stogov — 2015-02-27T20:22:51+00:00 URL: https://externals.io/message/83994#84041 · In reply to: #84038 On Fri, Feb 27, 2015 at 10:36 PM, Anthony Ferrara wrote: > Dmitry, > > > […] > > These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, > it's possible. But I don't think it's likely. It really smells to me > like bias in the testing methodology. (and the lack of an -O3 result > is suspicious as well). > > And looking at the code, I can see why. The PHP version is writing to > an internal buffer, while every other version has to write to `STDOUT` > on every single iteration. > > So you are intentionally not benchmarking the output in the PHP > version (you even explicitly call `ob_start()`) but are benchmarking it > in every other version. So in fact, the PHP code does something > different than the rest of the code. > > Sneaky sneaky. Also completely fake. Please, be polite. We opened sources, and the sources of benchmarks. Anyone can repeat this. Smart people may analyze results themselves before claiming others. I think you are smart person, and I respect the things you are doing. Thanks. Dmitry. A proper methodology would have > explicitly disabled any buffer so that the tests all tested the same > thing. Or even better, build up an internal buffer in all of the > implementations. That way you can compare the computation and not rely > on `STDOUT` (terminal) response. > > Anthony --- ## #84042 — Dmitry Stogov — 2015-02-27T20:25:36+00:00 URL: https://externals.io/message/83994#84042 · In reply to: #84040 On Fri, Feb 27, 2015 at 11:21 PM, Anthony Ferrara wrote: > Dmitry, > > > […] > > It's been brought to my attention that some people have taken what I > said completely out of context and insinuated it as a direct insult to > you. I assure you that was not the intent (I called the benchmark > sneaky and fake, which it is). > > So if you interpreted it as an insult, I apologize sincerely. I did > not intend to insult you personally at all with that remark. It was > only meant as a comment about the code that was posted. > Not a problem. I wouldn't even notice this because my bad English knowledge allows me to filter this :) Dmitry. > Anthony --- ## #84044 — Zeev Suraski — 2015-02-27T20:36:28+00:00 URL: https://externals.io/message/83994#84044 · In reply to: #84040 > -----Original Message----- > From: Anthony Ferrara [mailto:ircmaxell@gmail.com] > Sent: Friday, February 27, 2015 10:21 PM > To: Dmitry Stogov > Cc: Zeev Suraski; Jordi Boggiano; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > Dmitry, > > > […] > > It's been brought to my attention that some people have taken what I said > completely out of context and insinuated it as a direct insult to you. Anthony, I'm not sure how calling what Dmitry did sneaky (adj. furtive, stealthy; deceptive, deceitful) and fake (ajd. counterfeit, false) is not an insult. You could have picked wrong, problematic, inadequate, poor - or a dozen other adjectives that don't literally claim that Dmitry did it intentionally to give an unfair advantage to the PHP implementation (which, just in case anybody's wondering, you also wrote literally, using the word 'intentionally' in the previous sentence. You're not clairvoyant and you have no idea whether Dmitry did it intentionally or not, and the adjectives you used mean negative intent. If you apologize, apologize for real and not with disclaimers that it was taken out of context. It wasn't. And I have no idea why I had to bring it to your attention. If somehow you slipped, you should have fixed it yourself immediately. Zeev --- ## #84045 — Zeev Suraski — 2015-02-27T20:48:01+00:00 URL: https://externals.io/message/83994#84045 · In reply to: #84038 > -----Original Message----- > From: Anthony Ferrara [mailto:ircmaxell@gmail.com] > Sent: Friday, February 27, 2015 9:36 PM > To: Dmitry Stogov > Cc: Zeev Suraski; Jordi Boggiano; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > And looking at the code, I can see why. The PHP version is writing to an > internal buffer, while every other version has to write to `STDOUT` on every > single iteration. Except stdout is buffered too (www.turnkeylinux.org/blog/unix-buffering). Perhaps there's some difference there, but it's not nearly as obvious as you claim (let alone the other stuff in the other email, but let's leave that aside). Personally, my money would be on glibc stdout's buffering being more efficient than our output buffering layer. But you're welcome to test. Zeev --- ## #84046 — Anthony Ferrara — 2015-02-27T20:53:33+00:00 URL: https://externals.io/message/83994#84046 · In reply to: #84044 Zeev, > > […] > > Anthony, > > I'm not sure how calling what Dmitry did sneaky (adj. furtive, stealthy; > deceptive, deceitful) and fake (ajd. counterfeit, false) is not an insult. > You could have picked wrong, problematic, inadequate, poor - or a dozen > other adjectives that don't literally claim that Dmitry did it intentionally > to give an unfair advantage to the PHP implementation (which, just in case > anybody's wondering, you also wrote literally, using the word > 'intentionally' in the previous sentence. > > You're not clairvoyant and you have no idea whether Dmitry did it > intentionally or not, and the adjectives you used mean negative intent. > > If you apologize, apologize for real and not with disclaimers that it was > taken out of context. It wasn't. > > And I have no idea why I had to bring it to your attention. If somehow you > slipped, you should have fixed it yourself immediately. I had intended it as a remark about the code. Not about him personally, not about you, not about Zend. The presence of the explicit buffering code indicates that it wasn't an accident. Whether it was intentional for extra speed or not, it's still an intentionally different codepath between the rest of the implementations. One that in practice can have non-trivial differences over outputting directly. If you took that as an insult against him, you or Zend, then I'm sorry. I still believe the benchmark is very subtly broken, and hence the results are invalid. I apologized to any insult that may have been misdirected at the person. Please, can we talk about code separately from the person? A good person can produce bad code. That happens. I know, I produce a lot of it. I don't take insult when people call my code bad. And I hope we can call code bad. Because if we can't, we can never grow or move on as people or as a project. So I do apologize to the person. I don't to the code. Anthony PS: Dmitry accepted my apology. Can you please? --- ## #84048 — Dmitry Stogov — 2015-02-27T21:06:07+00:00 URL: https://externals.io/message/83994#84048 · In reply to: #84046 On Fri, Feb 27, 2015 at 11:53 PM, Anthony Ferrara wrote: > Zeev, > > > > […] > said > > […] > insult. > > […] > intentionally > > […] > case > > […] > you > > […] > > I had intended it as a remark about the code. Not about him > personally, not about you, not about Zend. The presence of the > explicit buffering code indicates that it wasn't an accident. Whether > it was intentional for extra speed or not, it's still an intentionally > different codepath between the rest of the implementations. One that > in practice can have non-trivial differences over outputting directly. > > If you took that as an insult against him, you or Zend, then I'm > sorry. I still believe the benchmark is very subtly broken, and hence > the results are invalid. I apologized to any insult that may have been > misdirected at the person. > > Please, can we talk about code separately from the person? A good > person can produce bad code. That happens. I know, I produce a lot of > it. I don't take insult when people call my code bad. And I hope we > can call code bad. Because if we can't, we can never grow or move on > as people or as a project. > > So I do apologize to the person. I don't to the code. > > Anthony > > PS: Dmitry accepted my apology. Can you please? > yes. please. we all have good expectancies anyway. (even if we can't agree on some topics) Dmitry. --- ## #84052 — Zeev Suraski — 2015-02-27T21:21:14+00:00 URL: https://externals.io/message/83994#84052 · In reply to: #84046 > -----Original Message----- > From: Anthony Ferrara [mailto:ircmaxell@gmail.com] > Sent: Friday, February 27, 2015 10:54 PM > To: Zeev Suraski > Cc: Dmitry Stogov; PHP Internals > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced > > Zeev, > > > > […] > insult. > > […] > > I had intended it as a remark about the code. Not about him personally I read the email again and again, and I don't see any possibility to read what you wrote in any other way other than blaming the code author (Dmitry) for being sneaky and intentionally faking the test. Sneaky code would either be code that performs something very different from what one would expect (that's not our case here), or code that was written by the author with the intent of doing something sneaky. >, not about you, not about Zend. I'm not sure why it even needs to be brought up, this has nothing to do with anybody but Dmitry. Which made it worse in my book, as he's is one of the most honest people I've ever bumped into. > PS: Dmitry accepted my apology. Can you please? Yes. Zeev --- ## #84054 — Andi Gutmans — 2015-02-27T21:55:51+00:00 URL: https://externals.io/message/83994#84054 · In reply to: #84038 > > > Dmitry, > > > […] > > These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, > it's possible. But I don't think it's likely. It really smells to me > like bias in the testing methodology. (and the lack of an -O3 result > is suspicious as well). > > And looking at the code, I can see why. The PHP version is writing to > an internal buffer, while every other version has to write to `STDOUT` > on every single iteration. > > So you are intentionally not benchmarking the output in the PHP > version (you even explicitly call `ob_start()`) but are benchmarking it > in every other version. So in fact, the PHP code does something > different than the rest of the code. We actually discussed this at the time of the results. IIRC it really has nothing to do with the output mechanism, etc.. The benchmark does enough iterations and very little output that the impact there is negligible (you can test this yourself to see if I am right but I am pretty sure I am). It is due to the fact that at runtime LLVM can optimize better to the architecture than a static standard gcc build. Constraining gcc with the right architecture dependent switches upfront will also improve the gcc results. Anyway, still pretty cool to see this although it has very little impact (if any) on real world apps ala Magent, WordPress, Drupal, ... I think the important learning is that faster synthetic benchmarks have very little impact on overall application performance. Sure it can have an impact on specific algorithmic pieces of code but that’s the exception not the norm. No doubt there are other ways to write JIT including tracing JITs etc. but I do think we found that we are more bound by I/O and memory/caches than the quality of the machine code as the engine is already quite tight. And with apps consuming more and more Cloud services the I/O bottleneck issue looks grimmer than ever! :) That also comes across consistently in benchmarks of PHP 7 vs. hhvm on real-world apps - you see a JIT and non-JIT platform pretty much head to head on performance and actually on the complex stuff PHP 7 is often faster. Anyway, definitely makes sense to continue to look at these kind of opportunities down the road but PHP 7 is such a huge step-up on real world application performance I think getting that out the door is the biggest possible short-term win when it comes to performance. Looking forward to seeing folks dig into the code and have ideas down the road!! Andi --- Next page: https://externals.io/message/83994.md?page=2