Games, cores, and functional languages
This month an architect from EA Black Box gave a talk at SFU about parallelism on the modern game consoles. It seems these systems have so many cores and so much parallelism, C++ just can’t cut it. Their findings were that the language is just too damn explicit, and no mere mortal could write C++ code that harnesses all that parallelism. He said they were lucky the Playstation 3 was so much more powerful than the 360, so they could optimize for the 360 and it would be sufficient for the Playstation.
For example, on these systems, you can do 20 CPU operations in the time that it takes to do one memory access1. Programmers think in terms of getting memory, then using memory, so this is a huge waste. They found that they their gurus could improve the performance of important functions by 40-400x, not by changing the algorithm, but by spending a month writing holycrap insane code that fully used all the cores and CPU features. Although that’s useful, when games have a 1-2 year development cycle and thousands of functions, it just can’t scale. He admitted that functional languages2 should be able to solve these problems, but dismissed them because they would make many EA employees’ heads explode.
So what if it makes EA employees’ heads explode? Mop it up and get new employees! Don Stewart says that the functional language Haskell is a great language for handling concurrency3:
This is almost identical to code you would write ignoring concurrency: nothing scary is needed to write parallel Haskell!
I’ve only started learning Haskell this semester, so I don’t have the experience to say this is a practical approach. I also have no idea how much work it would be to get a Haskell environment to take advantage of all the PlayStation 3 has to offer4, but at least it should be possible. It might even be testable on the Xbox with the current tools: XNA lets you develop games using .NET languages, one of which happens to be F#, which is based on OCaml.
Obviously EA isn’t going to fire their veteran C++ programmers and start moving to functional programming this decade. It might just be, though, that a small game development company making the right moves could compete with EA on performance using a lot fewer programmers. Then all we need is procedurally generated art…
- So much for Big-O of CPU cycles being sufficient for analyzing an algorithm. [↩]
- For those out of the loop, functional languages are very popular in academia, but see very limited use in the “real world” due to performance problems and their tendency to make weaker programmers’ heads explode. [↩]
- I realize that a pro-Haskell link would be more compelling if it wasn’t from a .edu domain, but what can you do. [↩]
- I severely doubt the standard PowerPC Haskell compiler would have impressive performance on PS3, and interfacing with C++ libraries like OpenGL would be an interesting endeavour. [↩]
Nov 25 2007
10:35 pm
Massive paralellism was the most interesting part of Prograph to me. It never got there compiler-wise, but it suited the language so well you had to add special hints when it was necessary for operations to execute in a particular order. (It was deterministic, though…)
Nov 26 2007
7:40 am
You should send this blog off to IBM (they did after all develop the processor architecture of all 3 major consoles and programmed the tools to use them to boot).
Currently the best thing they have going is their C/Fortran compiler specifically developed for parallelism for the CELL processor. http://domino.research.ibm.com/comm/research_projects.nsf/pages/cellcompiler.index.html
Nov 26 2007
8:01 am
Steve: too bad Prograph never took off.
Reddit is quite into functional languages, so I submitted this there. Maybe someone there will have some insight.
Nov 26 2007
8:08 am
FWIW, I think C++ is even unsuited to normal computing tasks, as it’s neither safe, clear, nor convenient. It’s just closer to the metal, which we keep on thinking we need (we don’t). Functional is certainly the way to go, as it fits solving actual problems better.
Nov 30 2007
11:52 am
I’m also learning functional programming this semester, and it’s amazing how much of a different way of looking at problems it involves. For me, the approach of just rephrasing and reducing a problem instead of attacking it results in much less time spent debugging my Scheme code than my C++ code.
It seems like the focus of functional languages has historically been expressivity rather than efficiency and optimization, however, so I’m excited about F# as movement towards functional programming being suitable for application development.