Moving to D

Walter Bright newshound2 at digitalmars.com
Wed Jan 5 11:53:16 PST 2011


bearophile wrote:
> Adrian Mercieca:
> 
>> How does D square up, performance-wise, to C and C++ ? Has anyone got any
>> benchmark figures?
> 
> DMD has an old back-end, it doesn't use SSE (or AVX) registers yet (64 bit
> version will use 8 or more SSE registers), and sometimes it's slower for
> integer programs too.

The benchmarks you posted where it was supposedly slower in integer math turned 
out to be mistaken.

> I've seen DMD programs slow down if you nest two
> foreach inside each other. There is a collection of different slow
> microbenchmarks.
> 
> But LDC1 is able to run D1 code that looks like C about equally fast as C or
> sometimes a bit faster.
> 
> DMD2 uses thread local memory on default that in theory slows code down a bit
> if you use global data, but I have never seen a benchmark that shows this
> slowdown clearly (an there is __gshared too, but sometimes it seems a
> placebo).
> 
> If you use higher level constructs your program will often go slower.

Rubbish. The higher level constructs are "lowered" into the equivalent low level 
constructs.


> Often one of the most important things for speed is memory management, D
> encourages to heap allocate a lot (class instances are usually on the heap),
> and this is very bad for performance,

That is not necessarily true. Using the gc can often result in higher 
performance than explicit allocation, for various subtle reasons. And saying it 
is "very bad" is just wrong.


> also because the built-in GC doesn't
> have an Eden generation managed as a stack. So if you want more performance
> you must program like in Pascal/Ada, stack-allocating a lot, or using memory
> pools, etc. It's a lot a matter of self-discipline while you program.

This is quite wrong.


More information about the Digitalmars-d mailing list