"nonnymouse" <nonny@mouse.com> wrote in message news:f7e9rb$2h8b$1@digitalmars.com...
> Bruno Medeiros 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.
>
> I hate to call you out, but.. I happen to be working for a class-A games' company who are writing their latest title in C#.

Yeah it's not always wise to make broad statements like that.  But I think he's still right if you are talking about most game engine developers.  I've talked with a few of them myself and they are OBSESSED will performance. You would think garbage collection was a four letter word.  That's not to say game developers wouldn't use a scripting language or jitted language for the game itself.  But usually it's a combination of C++ and scripted or jitted code.  Your company may be the exception.  Was your game engine was written entirely in C#?  I'm also curious, what genre is this game?

-Craig 

Craig Black Wrote:

 But usually it's a combination of C++ and scripted or
> jitted code.  Your company may be the exception.  Was your game engine was written entirely in C#?  I'm also curious, what genre is this game?

Sorry. I'm NDA'd. Obviously this is all a bit experimental. And there is some C++ too, but the C# is doing more of the heavy lifting than you might at first expect. Of course, it's really the graphics hardware doing most the real work ;-)

My point stands though. And I suspect we may be at the front of a new wave..

"Sean Kelly" <sean@f4.ca> wrote in message news:f7e2lu$1rrg$1@digitalmars.com...
> Brad Anderson wrote:
>> Bruno Medeiros wrote:
>>> 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.
>>
>> http://www.pragmaticprogrammer.com/articles/erlang.html
>>
>> search for "Concurrency Oriented Programming"
>
> Thanks for the link Brad, this is a great article.  I've never really looked into erlang, but it sounds like it's the type of language I've been thinking we'll end up with (based on message-passing, but a bit evolved from that).  I'm still not convinced that a functional language is required for this, but it is certainly a more natural fit.  Seems like the greatest obstacle for erlang would be getting schools to teach functional programming again--it's a bit of a chicken & egg problem.
>
>
> Sean

Interesting.  I wonder how Erlang scalability and performance compares to other functional languages. 

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

Craig Black wrote:
> 
> "Sean Kelly" <sean@f4.ca> wrote in message news:f7e2lu$1rrg$1@digitalmars.com...
>> Brad Anderson wrote:
>>> Bruno Medeiros wrote:
>>>> 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.
>>>
>>> http://www.pragmaticprogrammer.com/articles/erlang.html
>>>
>>> search for "Concurrency Oriented Programming"
>>
>> Thanks for the link Brad, this is a great article.  I've never really looked into erlang, but it sounds like it's the type of language I've been thinking we'll end up with (based on message-passing, but a bit evolved from that).  I'm still not convinced that a functional language is required for this, but it is certainly a more natural fit.  Seems like the greatest obstacle for erlang would be getting schools to teach functional programming again--it's a bit of a chicken & egg problem.
>>
>>
>> Sean
> 
> Interesting.  I wonder how Erlang scalability and performance compares to other functional languages.

Um, I think it's something like "stupid-good" or other such technical term.  Other than Termite Scheme, I believe it's the only one with such lightweight processes, to the point where you can spawn near a million on one box w/o bogging down.  Some CL dialects have green threads, which are lighter-weight than OS ones, but I'm not sure there's a comparison to Erlang's.  Termite was admittedly not as robust on the distributed side of things, which helps scalability considerably.  However, in subsequent releases they have gotten better.

I got the sense (although I'm not sure yet) that Paul Graham's Arc language hasn't given concurrency as much consideration as I think it needs.  Hopefully that will change...

I would really enjoy a language that had the Lisp look & feel, but with all the concurrency primitives, distributed nature, and fault tolerance of Erlang.  Oh, and the pattern matching a la Prolog.  I don't think I'm asking for much ;)

BA

On Mon, 16 Jul 2007 01:13:35 +0400, Sean Kelly <sean@f4.ca> wrote:

> Brad Anderson wrote:

>>  http://www.pragmaticprogrammer.com/articles/erlang.html
>>  search for "Concurrency Oriented Programming"
>
> Thanks for the link Brad, this is a great article.  I've never really looked into erlang, but it sounds like it's the type of language I've been thinking we'll end up with (based on message-passing, but a bit evolved from that).  I'm still not convinced that a functional language is required for this, but it is certainly a more natural fit.

You can take look to Sign# language in MS Singularity project:

"Language Support for Fast and Reliable Message-based Communication in Singularity OS"
http://research.microsoft.com/os/singularity/publications/eurosys2006_languagesupport.pdf

-- 
Regards,
Yauheni Akhotnikau

on Sun Jul 15 2007, Brad Anderson <brad-AT-dsource.org> wrote:

> Bruno Medeiros wrote:
>> 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.
>
> http://www.pragmaticprogrammer.com/articles/erlang.html
>
> search for "Concurrency Oriented Programming"

Before you get too excited, see http://www.youtube.com/watch?v=uKfKtXYLG78

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com

David Abrahams wrote:
> on Sun Jul 15 2007, Brad Anderson <brad-AT-dsource.org> wrote:
> 
>> Bruno Medeiros wrote:
>>> 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.
>> http://www.pragmaticprogrammer.com/articles/erlang.html
>>
>> search for "Concurrency Oriented Programming"
> 
> Before you get too excited, see
> http://www.youtube.com/watch?v=uKfKtXYLG78


The video is a bit old (that or the people who made it were being silly), but it's really not bad.  From it I learned that Erlang can do realtime programming, can handle errors locally without much explicit coding to do so (or so it seemed), and is dynamically loaded.  Their conclusions at the end also suggest that it's much easier to write such programs in Erlang than in C.  Having worked in that particular field before, I found the demo to be pretty interesting.


Sean

David Abrahams wrote:
> on Sun Jul 15 2007, Brad Anderson <brad-AT-dsource.org> wrote:
> 
>> Bruno Medeiros wrote:
>>> 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.
>> http://www.pragmaticprogrammer.com/articles/erlang.html
>>
>> search for "Concurrency Oriented Programming"
> 
> Before you get too excited, see http://www.youtube.com/watch?v=uKfKtXYLG78
> 

Haha

You had to dig that up, eh?

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