Walter Bright wrote: > My experience in tuning D code for speed is that if you write "C++" > code in D, you will get the same performance as C++. However, D > makes it a *lot* easier to reorganize/refactor code to try and make > it run faster, and this makes for better algorithms and hence > faster code.
Anecdote: Friday, I was asked to justify my decision to use D to a company exec. He pointed me to some benchmarks that had ruby vs python vs php vs C++ and asked how D would stack up. (The benchmark was sorting an array of integers, nothing really fancy.) Of them, Python had the shortest code, but C++ was the fastest, by far. Not really surprising. I first ported C++ to D. Equal lines of code, equal performance. The optimized builds did show D lagging ~20% behind g++ though. But, 20% behind g++ is still about 8x faster than the interpreted languages, so not bad. But, then I made a few minor tweaks. Slicing instead of copying. Array operations and foreach instead of iterator loops, stuff like that. The D code was now the shortest of all - even beating Python by a couple lines - while being just as readable and editable as the "productivity languages". And, to my surprise, the standard compile actually *beat* the optimized C++ build, running twice as fast! I was expecting it to be about equal, but instead, it just spanked it. Shorter code, easier to read code *AND* faster code, it beat all the competition in all the categories. Very pleasing result for everyone involved. Now, I dislike benchmarks as a general rule. Real world code is a lot more complex than these trivial things realize. But hell, when they work /for/ me, I won't complain. (Also, while a weaker comparison, I find this same trend continues to apps as a whole too. My D web app is about 1/8 the size in code of the smallest open source PHP program I found with similar features. 40% faster too. But Perpetually Hideous Programs are, well, perpetually hideous. Beating PHP is no great feat.)