Re: Complexity of new hardware

-------- Original Message --------

Subject: Re: [Algorithms] Complexity of new hardware

From: Sebastian Sylvan <[email protected]>

Being a massive Haskell fanboy myself, let me jump in with some

other cool things it does that relates to game development.

...

2. It has Software Transactional Memory. So when you really need

shared mutable state you can still access it from lots of different

threads at once with optimistic concurrency (only block when there's

an actual conflict). Yes, there are issues, and yes it adds

overhead, but if the alternative is single threaded execution and

the overhead is 2-3x, then we win once we have 4 hardware threads to

spare.

I would like to sound a note of caution on STM. It's quite nice to

program with -- think of it as threads-and-locks, made good. But I've

been to many presentations on STM, from prominent researchers in the

field, and the performance figures have always indicated that it doesn't

scale. Past about two-four threads contending on a piece of

transactional memory, the performance usually ends up worse than one

thread, which is hardly what you want from parallel programming. I

think a message-passing model is more promising, and is equally valid in

Haskell or in C++ (disclaimer: I spend my days doing research into

message-passing concurrency :-), whereas STM in C++ is not as
easy and simple as the Haskell version.

3. Monads! Basically this allows you to overload semi-colon, which

means you can fairly easily define your own embedded DSLs. This can

let you write certain code a lot easier.. You could have a

"behaviour" monad for example, abstracting over all the details of

entities in the game doing things which take multiple frames (so you

don't need to litter your behaviour code with state machine code,

saving and restoring state etc, you just write what you want to do

and the implementation of the monad takes care of things that needs

to "yield").

4. It's safe. Most code in games isn't systems code, so IMO it

doesn't make sense to pay the cost of using a systems programming

language for it (productivity, safety).

5. It's statically typed with a native compiler, meaning you could

compile all your scripts and just link them into the game for

release and get decent performance. Not C-like (yet, anyway!), but

probably an order of magnitude over most dynamic languages.

Agreed on the monads and safety. Having programmed a large system in

Haskell, I have found that the performance is surprisingly good,

especially in terms of memory use. The laziness aspect seems to allow

memory use to remain low, sometimes even lower than the equivalent C

program. But I doubt that the straight-line performance is going to be

as good as C, especially given the amount of garbage collection involved

in Haskell programs.

There was a talk a couple of years ago by Tim Sweeney that made a case

for functional programming in games (the slides can be found here:

http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf ), for anyone that's

interested. I also think that Haskell could benefit game development,

but it does take a little while to get your head round functional

programming, monads, and all the other stuff that Haskell has to offer.

Thanks,

Neil.

P.S. to be pedantic on the issue of the function of type a->a (from

another post), const undefined is also a valid function of that

type, if an unhelpful one :-)

------------------------------------------------------------------------------
Crystal Reports &#45; New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty&#45;free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list