On Sat, Feb 28, 2015 at 12:55 AM, Andi Gutmans <a...@zend.com> wrote:
> > 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!! > Completely agree. And have to say that these experiments with JIT leaded us to understanding of real PHP-5 bottleneck, that allowed us to make about 60% improvement on real-life in PHPNG and already near 2 times in PHP7. But LuaJIT without JIT is 4 times faster on Mandelbrot. It's a challenge... Thanks. Dmitry. > > Andi > >
