Sharing in D

[JAnderson]

JAnderson wrote:
> Walter Bright wrote:
>> Sean Kelly wrote:
>>> All that said, I believe it's entirely possible to write 
>>> performance-critical code in D so long as the
>>> programmer is careful about memory allocation.  And as Walter has 
>>> said before, because even
>>> malloc is not time-constrained the same goes for any use of dynamic 
>>> memory--GCs just magnify
>>> the issue.  Server apps in Tango, for example, don't allocate any 
>>> memory at all once initialization
>>> is complete.  This is why they tend to be so blisteringly fast.  It's 
>>> also why Tango is designed the
>>> way it is--not always super-convenient for run of the mill apps 
>>> programming, but quite scalable
>>> for high-end work.  By contrast, I'd argue that Phobos is the opposite.
>>
>> I wrote a version of Empire (the game) in D that does no allocation at 
>> all. Therefore, the gc never runs and there is never any unbounded delay.
>>
>> The gc is never going to pop up out of nowhere and sink your 
>> application. A gc only happens when you request memory from the gc. 
>> For the real time constrained section of code, the idea is to 
>> pre-allocate all the data you'll need first, then do no allocation 
>> within the critical section.
>>
>> In fact, such critical code in C++ does this anyway because there are 
>> no bounded time constraints on C++ new either. C malloc has no bound 
>> constraints, either.
> 
> This is true, new in C++ can seriously degrade performance if not manage 
> properly.  However calling a couple of 100 smallish news in C++ per 
> frame is quite acceptable and has a infindecimal affect on performance, 
> when working on windows.

I should point out that I'm aware of fragmentation however you can still 
call new's in either a way that doesn't fragment, or simply rely on 
paging to fix the problem.  If your not creating a program that needs to 
run longer then a month (ie maybe your game has a maximum time limit of 
30 minutes or something) then the problem is even less of an issue.  If 
you are, make sure you understand fragmentation.

> 
> D however is another kettle of fish.  You can't have any allocations 
> during the active part of the game.  You have to do it all a load 
> points.  Why? Because at some point the memory allocator will runout of 
> free memory and then it will need to clear anything that's unused. 
> Normally this wouldn't be a problem however it takes over a frame to 
> flush; and that leads to a very noticeable stutter.
> 
> Now I haven't tried realtime programming with allocations in the 
> realtime part for a while so things might have changed however that's 
> how it was the last time I was playing around with that stuff.  Also I 
> haven't tried Tangos.
> 
> Also nedmalloc can give a huge performance boost to windows allocation 
> making it almost as good as preallocations. Sometimes its better due to 
> memory locality which reduce cache misses.
> 
> The great thing about D's GC though its that other people can implement 
> there own.  I hope that when someone comes up with a really good one and 
> it will become part of the main distribution (ie not become another 
> windows malloc mess).
> 
> -Joel