Yah, that was my thought exactly. Its probably not just the language choice, but the chosen algorithm. I expect a word frequency counting algorithm to run at cl

Yah, that was my thought exactly. Its probably not just the language choice, but the chosen algorithm. I expect a word frequency counting algorithm to run at close to the speed of sequential main memory read speeds. So the bottleneck in real situations is likely how fast the I/O subsystem can get it into RAM. (a quick glance at the C version tells me all I need to know with the scanf, strdup, etc. This is sorta like those C vs Java benchmarks which boil down to the fact that the default (glibc/etc) C malloc() isn't really optimized for perf, and what your really bench marking is how terrible it is for frequent tiny allocations. I think there _IS_ a diffrence between the code written by someone who lives C in a system programming context, and people who dabble in it from a higher level language.). PS: Say using a hash to track a words frequency, likely works OKish but the need to keep it small, while still avoiding collisions would cause problems if the algorithm were parallelized in a long running system (rather than batching, where you would just run each thread against its own copy of the frequency tables, and then merge them at the end). But I'm still fairly certain that "your doing it wrong" if the overall algorithm can't run at a significant fraction of main memory bandwidth.