D Language 2.0

[bearophile]

Craig Black:

>I would have to agree and this is one of my causes for hesisation in adopting D.  The code I write requires the highest performance possible.  I am concerned that when I port it over to D, I will have to avoid using a lot of D features that use the GC (built-in arrays, closures, standard library features, etc.)  in order to get the best possible performance.  D does not adhere to the C++ zero-overhead principle, and I see this as a risk.  So if/when I end up porting my code to D I may evolve my own dialect of D that uses only the subset of features that tend to provide the best performance.<

The following comments are mostly about D1 :-)

There can be spots in a program where performance is very important, in those parts in D it can be indeed better to manage memory manually, to avoid heap-allocated closures (absent in D1), interfaces and array joining, and most importantly of all to program with a lower level style. 

Doing this I've seen that I am often able to get more performance from D1 code compiled with LDC than from C++ compiled with G++ 4.3.2 (where "often" means more than five times on ten smallish/medium programs). Generally built-in arrays aren't a problem (you just need to use something like an array appender if you want to append items to them, and where performance matters a lot, you have to avoid appends, and keep an index to the last item used).

If you do this and use this style for a significant percentage (well, more than 10-15% of it, unless it's less than 5000 lines long) of your whole program, then you are using C++ in D, and I think it's better for you to avoid using D, and to use C++ or C or asm :-)


>I don't know if the GC will send my code to hell, but if the performance drops by more than 20% by porting it from C++ to D, then I would be disappointed.<

You can try to write D programs that are faster than the C++ ones, instead. +-20% performance difference is not that important, you can aim to a higher difference.


>I got about a 15% performance improvement by switching from the system allocator to nedmalloc, so my code is very sensitive to heap allocation performance.<

Try to use a more custom allocator, like pools, arenas, and so on, they can be much better than nedmalloc. I have seen programs get about twice faster doing this.


>I use dynamic arrays quite a lot, and if I switched all of these to use D's built-in GC-based arrays, I think I would see a tremendous performance drop.<

I am a bit suspicious of this. GC scans can slow down a little, but I'm not seeing this as a big problem so far. You can test and benchmark some of your theories. A problem I've seen is caused by the not precise nature of the GC, wrong pointers keeping dead things alive.

Despite the amount of practice I've had so far with LDC, I can be wrong in many ways, so performing experiments is a good way for you to be sure. Being D2 in alpha stage it can't care too much yet about performance yet. There are things that will be improved. 

Bye,
bearophile