Re: [Algorithms] Complexity of new hardware
Brought to you by:
vexxed72
Menu
▾
▴
Re: [Algorithms] Complexity of new hardware
|
From: <ne...@tw...> - 2009-04-26 12:17:16
|
<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><br><blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size: 10pt; color: black; font-family: verdana;"><div ><br>
-------- Original Message --------<br>
Subject: Re: [Algorithms] Complexity of new hardware<br>
From: Sebastian Sylvan <seb...@gm...><br>
<br>
Being a massive Haskell fanboy myself, let me jump in with some<br>
other cool things it does that relates to game development.<br>
<br>
...<br>
<br>
2. It has Software Transactional Memory. So when you really need<br>
shared mutable state you can still access it from lots of different<br>
threads at once with optimistic concurrency (only block when there's<br>
an actual conflict). Yes, there are issues, and yes it adds<br>
overhead, but if the alternative is single threaded execution and<br>
the overhead is 2-3x, then we win once we have 4 hardware threads to<br>
spare.<br>
<br></div></blockquote><div ><br>I would like to sound a note of caution on STM. It's quite nice to <br>
program with -- think of it as threads-and-locks, made good. But I've <br>
been to many presentations on STM, from prominent researchers in the <br>
field, and the performance figures have always indicated that it doesn't <br>
scale. Past about two-four threads contending on a piece of <br>
transactional memory, the performance usually ends up worse than one <br>
thread, which is hardly what you want from parallel programming. I <br>
think a message-passing model is more promising, and is equally valid in <br>
Haskell or in C++ (disclaimer: I spend my days doing research into <br>
message-passing concurrency :-), whereas STM in C++ is not as <br>easy and simple as the Haskell version.<br><br></div><blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size: 10pt; color: black; font-family: verdana;"><div >
<br>
<br>
3. Monads! Basically this allows you to overload semi-colon, which<br>
means you can fairly easily define your own embedded DSLs. This can<br>
let you write certain code a lot easier.. You could have a<br>
"behaviour" monad for example, abstracting over all the details of<br>
entities in the game doing things which take multiple frames (so you<br>
don't need to litter your behaviour code with state machine code,<br>
saving and restoring state etc, you just write what you want to do<br>
and the implementation of the monad takes care of things that needs<br>
to "yield").<br>
<br>
4. It's safe. Most code in games isn't systems code, so IMO it<br>
doesn't make sense to pay the cost of using a systems programming<br>
language for it (productivity, safety).<br>
<br>
5. It's statically typed with a native compiler, meaning you could<br>
compile all your scripts and just link them into the game for<br>
release and get decent performance. Not C-like (yet, anyway!), but<br>
probably an order of magnitude over most dynamic languages.<br>
<br></div></blockquote><div ><br>Agreed on the monads and safety. Having programmed a large system in <br>
Haskell, I have found that the performance is surprisingly good, <br>
especially in terms of memory use. The laziness aspect seems to allow <br>
memory use to remain low, sometimes even lower than the equivalent C <br>
program. But I doubt that the straight-line performance is going to be <br>
as good as C, especially given the amount of garbage collection involved <br>
in Haskell programs.<br>
<br>
There was a talk a couple of years ago by Tim Sweeney that made a case <br>
for functional programming in games (the slides can be found here: <br>
<a href="http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf" target="_blank" mce_href="http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf">http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf</a>), for anyone that's <br>
interested. I also think that Haskell could benefit game development, <br>
but it does take a little while to get your head round functional <br>
programming, monads, and all the other stuff that Haskell has to offer.<br>
<br>
Thanks,<br>
<br>
Neil.<br>
<br>
P.S. to be pedantic on the issue of the function of type a->a (from <br>
another post), const undefined is also a valid function of that <br>
type, if an unhelpful one :-)<br>
</div><blockquote webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size: 10pt; color: black; font-family: verdana;">
</blockquote></span></body></html>
|
