C++ vs. D memory management performance (Was: Faster Virtual Method Dispatch)

[Sean Kelly]

Last follow-up.  I re-ran all tests with a bit less stuff going on in 
the background, and I ran the C++ tests with MSVC as well, including the 
hash table version (though I have no DMC run for this particular app). 
Here are the results.


D version 1 (wc) : the original example
D version 2 (wc2): using malloc for the buffer

C++ version 1 (wccpp2): the original example
C++ version 2 (wccpp3): replaced C++ stream code with C routines
C++ version 3 (wccpp4): replaced std::string with slice<char>
C++ version 4 (wccpp5): replaced std::map with unordered_map


D version 1 (wc):

Execution time: 0.380 s
Execution time: 0.423 s
Execution time: 0.446 s

D version 2 (wc2):

Execution time: 0.659 s
Execution time: 0.424 s
Execution time: 0.377 s

----------

DMC version 1 (wccpp2):

Execution time: 1.656 s
Execution time: 1.652 s
Execution time: 1.656 s

DMC version 2 (wccpp3):

Execution time: 1.230 s
Execution time: 1.257 s
Execution time: 1.290 s

DMC version 3 (wccpp4):

Execution time: 0.674 s
Execution time: 0.729 s
Execution time: 0.697 s

----------

MSVC version 1 (wccpp2):

Execution time: 1.093 s
Execution time: 1.120 s
Execution time: 1.042 s

MSCV version 2 (wccpp3):

Execution time: 0.797 s
Execution time: 0.833 s
Execution time: 0.799 s

MSVC version 3 (wccpp4):

Execution time: 0.761 s
Execution time: 0.744 s
Execution time: 0.726 s

MSVC version 4 (wccpp5):

Execution time: 0.438 s
Execution time: 0.436 s
Execution time: 0.406 s


The most amazing thing here is the dramatic performance difference 
between these D runs and the previous ones.  I won't speculate on why, 
bu the exact same app appears to be running 3 times as fast as it did 
this morning.  Beyond that, we can see that the C++ app using slices and 
a hash table performs similarly to the D implementation, though it's 
difficult to draw any solid conclusions without a test run under DMC. 
Also, I should note for the record that the hash table implementation 
doesn't rehash automatically (it wasn't a feature I needed at the time), 
so I preallocated 4096 buckets before running the word count.  There are 
793875 words in the KJ bible so this results in somewhat long chains, 
but I saw roughly similar results with double the number of buckets so I 
think the bulk of processing at this speed may be taken up by IO.  The 
only other notable difference is that the C++ code uses standard C calls 
for the file operations while the D code uses Windows calls.  I can't 
see this resulting in a noticeable speed difference, but I figured it 
was worth mentioning.

Finally, as these tests were quite informal I don't suggest reading too 
much into them.  However I think a reasonable conclusion would be that D 
is faster than C++ for typical user applications (assuming a use pattern 
similar to the word count application) and while C++ can be quite 
competitive, making it so requires the use of hand-written code over 
standard library code.  C++ will fare a bit better in 2009 when 
unordered_map is an official part of the standard, but that still leaves 
std::string as the suggested way to store string data.  This may not be 
an issue if you're dealing with English text where most words are under 
16 characters, but it could be for other data sets where allocations 
will occur.


Sean