WordCount performance

[Walter Bright]

I did a little checking.

D's and DMC's isspace(c) checks to see if the input character c is 
ascii. gcc's does not. So there's a little slowdown there, buying 
robustness.

What the real difference is, however, is that D's and DMC's getchar() is 
synchronized for multiple threads. This means that there's a lock/unlock 
going on for *every* single character read.

gcc may not synchronize stdin for multiple threads, or may have found a 
way to avoid the locking if the start-new-thread function in the library 
is never called.

For the Digital Mars stdio library, the way to do fast I/O from the 
synchronized streams is to do it in chunks, not character-by-character. 
Several functions in std.stdio are available to do this - I bet you'll 
get a dramatic speed boost by using one of them.

In other words, from examining the generated asm for dmd and gcc it's 
pretty clear that the observed speed difference has essentially 
*nothing* to do with either the language or the back end optimizer, and 
everything to do with the I/O strategy.

This is why it is crucial to figure out why one is getting certain 
results from a benchmark, instead of just assuming.

P.S. In general, it's just a bad idea to do compute performance 
benchmarks using I/O, because the performance will be dominated by the 
relatively slow I/O.

P.P.S. Back in the 80's, my compiler would regularly beat the tar out of 
other compilers on magazine I/O speed benchmarks. It's because my 
library used a large disk buffer, which made a HUGE difference when 
reading files from a floppy disk. My competitors never did figure that 
out until about 10 years later <g>.