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

[Craig Black]

"Sean Kelly" <sean at f4.ca> wrote in message 
news:f7e1mh$1ogd$1 at digitalmars.com...
> 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

It may very well be true that we need something that isn't available yet. 
However, I don't think we should wait for something better than Concur. 
Concur in it's current form is way better than anything offered by today's 
OOP languages.  I think we should pursue implementing these abstractions 
now.  If something better presents itself, then we can leverage that as 
well.

-Craig