Notes
Lecture 6
---------
comments on journal
Show & Tell
concurrency in game engines & godot
using gdb with godot (to debug the engine)
Journal comments
- many of you are making good progress
- but many of you seem to be very undecided in terms of project directions
- many seem a bit ambitious
It is important to really understand what you want to do, but you
need to have reasonable goals
Strategy: work on a piece of a grand vision
- key differentiation
- technically interesting
May not be too fun on its own
Concurrency
- notice we saw that godot has lots of threads running
- we need them to use multiple cores
- but threads make life very difficult, because concurrency
with lots of transistors, we get many cores
can be general purpose (CPU) or special purpose (GPU, tensor cores, etc)
most of the special computational units are SIMD-ish
- single instruction, multiple data
- so, inherently parallel
Some tasks are more straighforward to parallelize
- rasterization of 3D graphics
Other tasks aren't
- game AI, game logic
So, what do we do with all the cores?
- how do we coordinate activity?
well, why not just have different threads work on shared data?
- race conditions will lead to non-deterministic bugs
We can solve race conditions with locks
- when a thread accesses a data structure, it "locks" it, and only unlocks
it when done
- this is mutexes, semaphores, etc
- you can't just use regular variables to do synchronization & locking
- BUT YOU DON'T WANT TO DO THIS
You want a mutithreaded-friendly architecture, not mechanisms
- otherwise, uncontrolled parallelism actually leads to slower code
- or it will be buggy
Godot is very smart about multithreading
https://godotengine.org/article/why-does-godot-use-servers-and-rids
Basically, servers are how you run a thread
- a server has a particular set of functionality
Servers interact via messages
Shared data is possible, but it has a clear thread (server) owner, and is shared
via special references (RIDs), where, I think, access is by default read only
Note that you don't have to think about multithreaded code in Godot most of the time, but you should be aware
- don't expect variables to be instantly shared across nodes
- instead, use messages (signals) to communicate changes in state