The Next Mainstream Programming Language: A Game Developer's Perspective :: Redux

[Bruno Medeiros]

Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Sean Cavanaugh wrote:
>>
>> I doubt that many class-A games would use garbage collection if they 
>> had the possibility (ie, the language supported it), even if the GC 
>> was a very good one, Java VM like. The need for performance is too 
>> great for that. And yes, maybe an app using a very good GC can be 
>> faster that a normal manually-memory-managed app (Walter's words, not 
>> mine, according to his GC page), but I doubt using any GC could ever 
>> beat a well optimized manually-memory-managed app.
> 
> I think it depends on the app design.  Without garbage collection, 
> sharing data between threads can be quite expensive.  For example, 
> boost::shared_ptr uses an atomic operation to adjust its reference 
> counter, which is typically more than 70 cycles if a LOCK operation is 
> used on x86 (in truth, I think they've optimized it to use a spin-lock, 
> which is more efficient but more complicated to get right).  But I do 
> agree that explicit allocation and deletion only is more efficient than 
> allocation and deletion combined with the occasional GC sweep (for 
> obvious reasons).
> 
>> This has been said countless times, and I think everyone (in D and the 
>> overall programming community) acknowledges that. What happens is that 
>> no one really yet knows how to make parallelism and concurrency easier 
>> to do. So there is really no point in asking for D to be better at 
>> this, if the way *how* to do it is not yet know.
> 
> Well, there are a lot of ways to make it easier than explicit 
> manipulation of mutexes and such--some of the involved research dates 
> back to the early 60s--but even with these alternate methods, 
> concurrency isn't easy.
> 

Hum, like conditional variables?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D