> -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@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 <z...@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. > 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
