On Tue, Mar 3, 2015 at 6:57 PM, Zeev Suraski <z...@zend.com> wrote: > > -----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. >
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 > >
