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
