Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84054
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.192.173 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <CAAyV7nFvgMa4N9QADMNxBwXtDJMiW=w8RTuTG3zZet6JdmtSSg@mail.gmail.com>
Date: Fri, 27 Feb 2015 13:55:51 -0800
Cc: Dmitry Stogov <dmitry@zend.com>,
 Zeev Suraski <zeev@zend.com>,
 Jordi Boggiano <j.boggiano@seld.be>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <56FAF35D-717D-4A88-9A2B-35B0F87BBDE8@zend.com>
References: <CA+9eiLv+HzuLrECzV37Q1mnNCGNbUj1OocCH3Q7b7PSyWBPtfg@mail.gmail.com> <CAAyV7nF53g0wt9Gva5MwULvHDxrqNhLQJMsNTiLP2m0wOAHJkg@mail.gmail.com> <ABB24B2E-9456-485E-8510-941076AAAD77@zend.com> <54F08FF3.3040404@seld.be> <CA+9eiLumXUD6SowadcfcbtzKYT96ut9fFt-fy5afrGOU1rZhSA@mail.gmail.com> <CAAyV7nFF_F+k-9cWqSrLp1vUY+GWxqKqfH6ABZZovZj9d4o8jw@mail.gmail.com> <CA+9eiLvZW-myYa9TW6Q0rhLbFRQNLq3iH16FHVyzeThdCUgvGA@mail.gmail.com> <63262a9c0edd51bbf38df2a00c87340e@mail.gmail.com> <CAAyV7nHpf8JT0nAF-M9d-65JQHDbYnK7F+c9CUtoyLkkfRiROg@mail.gmail.com> <CA+9eiLsa6UpK_e_tRESS6MvXYpbJcFo+Oqd0CC4gByPVNzXNJA@mail.gmail.com> <CAAyV7nFvgMa4N9QADMNxBwXtDJMiW=w8RTuTG3zZet6JdmtSSg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Subject: Re: [PHP-DEV] Zend JIT Open Sourced
From: andi@zend.com (Andi Gutmans)

> On Feb 27, 2015, at 11:36 AM, Anthony Ferrara <ircmaxell@gmail.com> =
wrote:
>=20
> Dmitry,
>=20
>>> 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.
>>=20
>>=20
>> Thanks for good words :)
>>=20
>> This work may be adopted for some specific cases.
>> 25-30 times speedup on Mandelbrot allows usage for numeric =
calculation
>> instead of C.
>>=20
>> https://gist.github.com/dstogov/12323ad13d3240aee8f1
>>=20
>> anyone may repeat the language battle :)
>=20
> 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).
>=20
> 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.
>=20
> 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=E2=80=99s 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