Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84253
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4ee494ad54939f8147b0038a503b88e8@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>
	<CAAyV7nFZGP51J-HHakuHQG0aUK+mS1xQinV8N8MBXE-jqu0_aQ@mail.gmail.com>
	<9977a20c9d756489f41e666d23c89e3f@mail.gmail.com>
	<CAAyV7nGaf_TC9gMvzr_jDveLKOcMHdKfW1PcJXuo8JxJ32i1DA@mail.gmail.com>
	<9656140ae786d42e7b0da11dbd416a61@mail.gmail.com>
	<CAAyV7nERsqLgae2hW5k2QfG0cq-XG_5tO9YmE+ejQLrsK7x+DA@mail.gmail.com>
	<4ee494ad54939f8147b0038a503b88e8@mail.gmail.com>
Date: Tue, 3 Mar 2015 21:17:42 +0400
Message-ID: <CA+9eiLs55vFyWXo=Hya9fbpNs6kRme0R=ghSdvj3b52WQPoVew@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0115f0483b6f8f0510658362
Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced
From: dmitry@zend.com (Dmitry Stogov)

--089e0115f0483b6f8f0510658362
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 3, 2015 at 6:57 PM, Zeev Suraski <zeev@zend.com> wrote:

> > -----Original Message-----
> > From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> > Sent: Tuesday, March 03, 2015 5:44 PM
> > To: Zeev Suraski
> > Cc: PHP Internals
> > Subject: Re: [PHP-DEV] Re: Zend JIT Open Sourced
> >
> > Zeev,
> >
> > On Tue, Mar 3, 2015 at 8:05 AM, Zeev Suraski <zeev@zend.com> wrote:
> > >> So I do apologize to the person. I don't to the code.
> > >
> > > I wanted to verify whether my gut was correct (minimal amount of
> > > output, and stdout is in fact buffered - output shouldn't move the
> > > needle) and asked Dmitry to rerun the C test on the same system, but
> > > this time with the output code completely commented out:
> > > real 0m0.011s  (+- 0.01)
> > > user 0m0.011s  (+- 0.01)
> > > sys 0m0.001s
> > >
> > > Apologies to the code might be in order :)
> > >
> > > The source of the JIT engine's edge is, as Dmitry and Andi said, the
> > > CPU-specific optimizations that gcc -O2 doesn't generate, and
> > > therefore it can actually be faster than a generic native executable
> > > in some (I would guess not all that common) cases.
> >
> > So, let's put that to the test, shall we. I compiled and ran the "JIT"
> > compiler (can we please stop calling it that, it's not). along side PHP
> > 5.5, PHP
> > 7 and GCC -O0 through -O3.
> >
> > I also turned on the ob_start and off (commenting out the ob_start and
> > ob_end_flush lines):
> >
> > https://docs.google.com/spreadsheets/d/1b4yFh0i62haDoQBRf8pOoi63OLr
> > xRbecHSj9sQpD5Nk/edit?usp=sharing
> >
> > With ob_start, the "JIT" was fastest. Without it, it was more than 2x
> > slower
> > (slightly faster than -O0).
> >
> > Raw results (average):
> >
> > GCC -O0: 0.0258
> > GCC -O1: 0.0160
> > GCC -O2: 0.0144
> > GCC -O3: 0.0140
> > "JIT" /w ob_start: 0.011
> > "JIT" /wo ob_start: 0.0238
> > 5.5 /w: 1.273
> > 5.5 /wo: 1.301
> > 7 /w: 1.492
> > 7 /wo: 1.545
> >
> > I used identical code to what Dmitry posted earlier, with the one
> > exception
> > that ob_start was commented out for the "/wo" runs.
>
>
> Anthony,
>
> What you demonstrate here is that direct output slows PHP down (at least
> php-cli), but not that it's the reason that PHP runs faster.
> As we don't really care about the output layers when benchmarking
> Mandelbrot - but rather at how fast the algorithm is executed, eliminating
> output in both tests is the simplest and most accurate to benchmark the raw
> performance of the execution engine.  And the (very experimental) JIT
> engine
> wins here.
>
> > Now, there's something really interesting in those results. The numbers
> > given
> > back from the "JIT" are far more stable than anything else (more than an
> > order of magnitude more stable /wo, and several orders /w ob_start).
> > Something smells off about it. I'm not so sure what off hand, but I'm
> > going to
> > dig further.
> >
> > Now, to the point that "gcc uses output buffering".
>
> Not gcc, glibc's stdout.
>

CLI uses unbuffered write() syscall.

Thanks. Dmitry.


>
> > Yes, it does.
> > However, PHP (including the "JIT") is compiled with GCC. So it will use a
> > similar output buffer unless you disable the buffer. The only place in 7
> > that
> > we do that is sapi/phpdbg/phpdbg.c:881. So either way, you're going to be
> > using the same output buffer on the STDOUT stream.
>
> Actually no, it doesn't, not if you use CLI.  The CLI SAPI uses the
> write(1,
> ...) syscall, which is unbuffered.  You would have been correct if it was
> using fwrite(..., stdout) - but it doesn't.  See
>
> stackoverflow.com/questions/1360021/why-fwrite-libc-function-is-faster-than-write-syscall
>
> So in reality, what Dmitry did by adding the ob_start() call is actually
> make the PHP version (more or less) equivalent to the C version, as opposed
> to giving it an unfair advantage.
>
> If you *really* want to test the raw performance difference, get rid of the
> output code altogether in both the PHP and C versions.  I haven't tried
> that, but as I do believe our output buffering code is a lot more
> complicated than that of glibc's streams - my guess is that the gap between
> the two implementations would actually grow bigger, and in PHP's favor.  We
> already know that the PHP version with the output (using the output
> buffering layer) runs as fast as the C version with no output at all.
>
> Zeev
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0115f0483b6f8f0510658362--