Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84078
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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>
	<56FAF35D-717D-4A88-9A2B-35B0F87BBDE8@zend.com>
Date: Sat, 28 Feb 2015 18:23:56 +0400
Message-ID: <CA+9eiLu0y_c+ZfJrUSta-3uGUm0Op6oHcdnGxP_V2G0cLt5N9A@mail.gmail.com>
To: Andi Gutmans <andi@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, Zeev Suraski <zeev@zend.com>, 
	Jordi Boggiano <j.boggiano@seld.be>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133f0563b5a92051026bc42
Subject: Re: [PHP-DEV] Zend JIT Open Sourced
From: dmitry@zend.com (Dmitry Stogov)

--001a1133f0563b5a92051026bc42
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 28, 2015 at 12:55 AM, Andi Gutmans <andi@zend.com> wrote:

> > On Feb 27, 2015, at 11:36 AM, Anthony Ferrara <ircmaxell@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 littl=
e
> 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 a=
n
> impact on specific algorithmic pieces of code but that=E2=80=99s the exce=
ption not
> the norm. No doubt there are other ways to write JIT including tracing JI=
Ts
> 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 alrea=
dy
> 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 worl=
d
> 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
>
>

--001a1133f0563b5a92051026bc42--