Zeev, On Tue, Mar 3, 2015 at 10:57 AM, 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.
It wins on uneven ground. Which was the very initial point that I made. One writes to interactive output within the loop (even if buffered, it's flushed 69 times), and one doesn't. Apples-to-oranges. And the test that I just made proves that. > 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. GCC at -O1 and higher will run in 0 seconds. Because the loop will be dead-code and hence eliminated. It is idempotent (no side effects) and the result of the program doesn't depend on it, so it's eliminated. You'd need to make the computation meaningful with a result that you can return for it to be live code. Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
