5 ms·

Just a small nit: > Another scenario, say you are working on 3D game, you have some trick physics math where you need to crunch numbers, maybe adding realistic

Just a small nit: > Another scenario, say you are working on 3D game, you have some trick physics math where you need to crunch numbers, maybe adding realistic building physics to Minecraft. But separate threads are already handling procedural generation of new chunks, rendering, networking, and player input. If these are keeping most of the system’s cores busy, then parallelizing your physics code isn’t going to help overall. Generally game engines have been migrating towards work-stealing based tasks architectures. Having monolithic thread based systems(one per physics, rendering, gameplay, etc) were great for migrating from the single-threaded games of old, however it leads quite often to idle threads. This was even more critical in the PS3 era where you had SPUs with just ~256kb of RAM. Overall it leads to an architecture that scales well to whatever platform you end up targeting since the CPU/compute capabilities of various platforms can be pretty disparate.

yazaddaruvala 10y ago
This is actually a really amazing talk about parallelizing game engines. http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh...
- vvanders 10y ago
  Yup, this type of stuff is exactly what I was referring to , ND are top of their class when it comes to engine design.
  - kedean 10y ago
    Like the time they wrote their own lisp dialect to run on PS2. https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
stcredzero 10y ago
Generally game engines have been migrating towards work-stealing based tasks architectures. How are Golang goroutines for implementing work-stealing?
- vvanders 10y ago
  From what I understand of goroutines the language is already handling distribution of running them so there's no work-stealing to implement. For a game engine where task based structure is important Go would be a pretty poor choice. You don't want a GC in your inner engine loop. In addition Go has pretty poor semantics for explicit memory layout, something that can be critical for performance. It's very common to issue cache prefetches for the next task as one is spinning down for instance.
  - stcredzero 10y ago
    For a game engine where task based structure is important Go would be a pretty poor choice. I have a game server written in Go. You don't want a GC in your inner engine loop. Why not? I expect my typical GC pause times to be 1 or 2 ms under Go 1.7. But if my server had pause times of 20ms, I wouldn't care, so long as it didn't happen more often than once a second or so. It's very common to issue cache prefetches for the next task as one is spinning down for instance. Yeah, I've had Go guys say I should give every agent its own goroutine. As it turns out, this can cost 150-300 microseconds every time one of them wakes up. I have a traditional game loop right now.
    - vvanders 10y ago
      > I have a game server written in Go. Game engine != game server. > Why not? I expect my typical GC pause times to be 1 or 2 ms under Go 1.7. But if my server had pause times of 20ms, I wouldn't care, so long as it didn't happen more often than once a second or so. We're talking about client-side latency here. You've got 16.6ms to do everything in a game engine. Even 2ms is 1/8th of your frame and a significant amount of work. 20ms is two missed frames which is really bad. The types of engines where work stealing and task based architecture are prevalent are usually of the AAA variety, where performance is critical and the scenes are either very complex or very large. In this space GC based languages have been limited in scope to gameplay scripting and even then are usually very fast(Lua or equivalent).
      - 10y ago

yazaddaruvala 10y ago

This is actually a really amazing talk about parallelizing game engines. http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh...

vvanders 10y ago
Yup, this type of stuff is exactly what I was referring to , ND are top of their class when it comes to engine design.
- kedean 10y ago
  Like the time they wrote their own lisp dialect to run on PS2. https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

stcredzero 10y ago

Generally game engines have been migrating towards work-stealing based tasks architectures. How are Golang goroutines for implementing work-stealing?

vvanders 10y ago
From what I understand of goroutines the language is already handling distribution of running them so there's no work-stealing to implement. For a game engine where task based structure is important Go would be a pretty poor choice. You don't want a GC in your inner engine loop. In addition Go has pretty poor semantics for explicit memory layout, something that can be critical for performance. It's very common to issue cache prefetches for the next task as one is spinning down for instance.
- stcredzero 10y ago
  For a game engine where task based structure is important Go would be a pretty poor choice. I have a game server written in Go. You don't want a GC in your inner engine loop. Why not? I expect my typical GC pause times to be 1 or 2 ms under Go 1.7. But if my server had pause times of 20ms, I wouldn't care, so long as it didn't happen more often than once a second or so. It's very common to issue cache prefetches for the next task as one is spinning down for instance. Yeah, I've had Go guys say I should give every agent its own goroutine. As it turns out, this can cost 150-300 microseconds every time one of them wakes up. I have a traditional game loop right now.
  - vvanders 10y ago
    > I have a game server written in Go. Game engine != game server. > Why not? I expect my typical GC pause times to be 1 or 2 ms under Go 1.7. But if my server had pause times of 20ms, I wouldn't care, so long as it didn't happen more often than once a second or so. We're talking about client-side latency here. You've got 16.6ms to do everything in a game engine. Even 2ms is 1/8th of your frame and a significant amount of work. 20ms is two missed frames which is really bad. The types of engines where work stealing and task based architecture are prevalent are usually of the AAA variety, where performance is critical and the scenes are either very complex or very large. In this space GC based languages have been limited in scope to gameplay scripting and even then are usually very fast(Lua or equivalent).
    - 10y ago