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.
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.
The talk about the tagged allocators and fibers kinda reminds me of Erlang. :)
EDIT: The use of atoms and per-process stacks which are rapidly returned to the operating environment is kinda similar to how this presentation handles the allocation of the data for jobs/"frames".
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.
Most of the technical stuff about Direct X is obviously hopelessly outdated now, but it was pretty cool stuff back in 2000 or so when teenage me wanted to learn coding by playing around writing games. :P
Triple buffering is also advantageous to minimize graphics driver overhead, one part is updated by multiple cpu tasks, one is transferred to the gpu, one is used to render.
I've been working with golang for too long. Everytime I watch stuff like this it just looks like they're re-inventing goroutines, channels, and the go scheduler.
11 comments
[ 3.2 ms ] story [ 28.5 ms ] threadIt'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...
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.
http://www.slideshare.net/naughty_dog/statebased-scripting-i...
EDIT: The use of atoms and per-process stacks which are rapidly returned to the operating environment is kinda similar to how this presentation handles the allocation of the data for jobs/"frames".
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.
http://www.amazon.com/Real-Time-Strategy-Programming-Wordwar...
Most of the technical stuff about Direct X is obviously hopelessly outdated now, but it was pretty cool stuff back in 2000 or so when teenage me wanted to learn coding by playing around writing games. :P