Re: [Algorithms] Complexity of new hardware

[Sebastian S. <seb...@gm...>]

On Wed, Apr 22, 2009 at 5:52 PM, Sam Martin <sam...@ge...>wrote:

>
> > Wouldn't that be a tough sell? You'd already be competing with free
> > implementations of LUA, Python, JavaScript and their ilk on the low
> end,
> > and built-in languages like UnrealScript on the high end.
>
> I don't think there's a market for that kind of scripting DSL. A new
> language would need to eat into the remaining C++ development burden
> that isn't suitable to implementing in Lua, say. Which is plenty.
>
> > Doesn't this bring us back full circle? I recall a statement from a
> > month ago saying that we all need to think differently about how we
> put
> > together massively parallel software, because the current tools don't
> > really help us in the right ways...
>
> Another reason to consider pure functional languages. This is a much
> deeper topic that I'm now about to trivialise, but the referential
> transparency of these languages makes them particular suitable to
> parallel evaluation. For example, GHC (arguably the most mature Haskell
> compiler) can compile for an arbitrary number of cores, although it's
> still an active research area as I understand it.


Being a massive Haskell fanboy myself, let me jump in with some other cool
things it does that relates to game development.

1. It's starting to get support for "Nested data parallelism". Basically
flat data parallelism is what we get with shaders now, the problem with that
is that the "per-element operation" can't itself be another data parallel
operation. NDP allows you to write data parallel operations (on arrays)
where the thing you do to each element is itself another data parallel
operation. The compiler then has a team of magic pixies that fuses/flattens
this into a series of data parallel appliacations, eliminating the need to
do it manually.

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.

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.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862