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

[Sean Kelly]

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.

> I read in a recent article (I think it came from Slashdot, but not sure) 
> that a new programming paradigm is needed to make concurrency easier, 
> just in the same way as OO (and class encapsulation) improved on the 
> previous data abstraction paradigm to make code cleaner and easier to 
> write. Just in the same way as structured programming (ie, using 
> functions/scopes/modules) improved on the previous paradigm of 
> sequential/global/goto-using code, so to speak.

This is what I think needs to happen.  Concur and such are an 
improvement, but they still require the programmer to do a lot 
explicitly.  Ultimately, we need a fundamental change in the way we do 
multithreaded programming if we want our applications to scale on future 
architectures.


Sean