> It wins on uneven ground. Without the output buffering code it's a LOT more uneven, as the PHP version is flushing every byte - approx. 6,000 such flushes.
> 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. I don't see how it proves that. Flushing a few dozen times is negligible on 6K of output. You can add ob_end_flush(); ob_start(); on every line to make it 100% equivalent (or hack the SAPI write callback to use fwrite() instead of write(), which would be even more comparable); But I still maintain that saying it's Apples and Oranges is not a very realistic view of things. Both versions are buffered. Without the output buffering code - the PHP version would be *completely* unbuffered when run in CLI mode, which is why it was added in the first place. The C version is also buffered - a touch less than the PHP version - but using a much simpler buffering system (glibc streams, vs. our much more complex multi-layer output buffering system) and therefore probably at least slightly faster. Of course, adding 'full' output buffering to the C version (that would also buffer newlines) is way beyond the scope of such a simple test. The two versions are very much comparable, and are the reasonable implementations one would use without giving one platform or the other an unfair advantage or disadvantage (as removing the ob_() calls does, given that CLI uses unbuffered write()'s). It's perhaps the difference between a 200gr apple and a 205gr apple, but certainly not apples and oranges, and it's absolutely not the reason for why the PHP JIT version was faster. > > 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. So just get rid of the newline prints, but keep everything else. That means zero flushing, full buffering for the C version. How fast does that run? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
