Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84039
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nFvgMa4N9QADMNxBwXtDJMiW=w8RTuTG3zZet6JdmtSSg@mail.gmail.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>
Date: Fri, 27 Feb 2015 23:57:13 +0400
Message-ID: <CA+9eiLt6S=4ss+GF+v3qMJKW6ZBXW+XotYjfvH16uFHT02DhMQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, Jordi Boggiano <j.boggiano@seld.be>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0115f04852dbb4051017460b
Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced
From: dmitry@zend.com (Dmitry Stogov)

--089e0115f04852dbb4051017460b
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 27, 2015 at 10:36 PM, 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).
>

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 <command>

perf report -n

Thanks. Dmitry


>
> Anthony
>

--089e0115f04852dbb4051017460b--