Parallelizing the Naughty Dog Engine Using Fibers [video]

Fibers is a kind of lightweight thread, also known as coroutine.

It's available in WinAPI since Win16 days and heavily used in MS Word. It's also heavily used in many AAA games that use Lua 5.1/LuaJIT, known as coroutine. And in the Go language its named Goroutine.

http://en.wikipedia.org/wiki/Fiber_(computer_science) , Lua Coroutines http://www.lua.org/pil/9.html , Lua in video games http://en.wikipedia.org/wiki/Category:Lua-scripted_video_gam..., Go Goroutines http://www.golang-book.com/10/index.htm

Triva: Naughty Dog uses a Lisp/Scheme dialect for their scripting language: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp, http://www.quora.com/Does-Naughty-Dog-still-use-lisp-for-mak...

The different types of lightweight threads and thread-like things can differ quite a bit in their implementation and usage.

E.g. some are explicitly cooperative and require the function to Yield() to other coroutines. Others, like goroutines (which are more like threads) automatically yield at certain points (e.g. I/O or function calls).

I think generally coroutines imply that the programmer handles more of the logic of when to switch tasks, while lightweight threads (in Go, Haskell, etc.) imply that there's more stuff "behind the scenes" to manage the concurrency for you like real OS threads. You may have lightweight threads that are multiplexed onto multiple OS threads, but you wouldn't have coroutines that are multiplexed onto multiple OS threads because coroutines implies no parallelism.

It is interesting to see that the techniques they used were in many cases quite similar to techniques that were in use decades ago by game devs who had to struggle with much worse hardware.

For example they discussed how they achieved 60 FPS with a pipeline that essentially works on 3 frames in parallel: 1 frame of logic, the next frame of graphics, and the the next frame in GPU rendering phase.

I remember reading a really interesting book by a dev who had worked on RTS games like Total Annihilation, and Age of Empires and this was a technique that he talked at length about as essential to the performance of those games on the hardware of that time. I learned a lot from that book, including how to make efficient path finding, AI, etc.

It's nice to see that fundamental techniques like that are still useful to this day.

and that book was?

Very similar to how GHC parallelizes work items/sparks/threads onto native threads.