> On Feb 27, 2015, at 11:36 AM, Anthony Ferrara <ircmax...@gmail.com> wrote: > > Dmitry, > >>> 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 :) > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
