4 ms·

I had the impression, ECS would boost performance mainly by allowing the systems to run in parallel on the entities. Isn't this kinda moot in a single threaded

by k__ 1y ago

I had the impression, ECS would boost performance mainly by allowing the systems to run in parallel on the entities. Isn't this kinda moot in a single threaded runtime?

aapoalas 1y ago
This is definitely the more meaningful/influential performance benefit of ECS in game development, I believe. JavaScript will not allow for that as you point out. Perhaps a sufficiently crazy JIT might claw some of those benefits back, though? Not sure. But: the lesser but still impactful performance benefit of ECS is the usage of Struct-of-Array vectors for data storage. JavaScript can still ruin that benefit by always accessing all parts and features of an Object every time it touches one, but it is a less likely thing to happen. So, there is a benefit that JavaScript code itself can enjoy. Finally, there is one single "true System" in a JavaScript engine's ECS: the garbage collector. The GC will run through a good part of the engine heap, and you can fairly easily write it to be a batched operation where eg. "all newly found ordinary Objects" are iterated through in memory access order, have their mark checked, and then gather up their referents if they were unmarked. Rinse and repeat to find all live/reachable objects by constantly iterating mostly sequential memory in batches. This can also be parallelised, though then the batch queue needs to become shareable across threads. The sweep of the heap after this is then a True-True System where all items are iterated in order, unmarked ones are ignored, marked ones are copied to their post-compaction location, and any references they hold are shifted down to account for the locations of items changing post-compaction.
- k__ 1y ago
  "a sufficiently crazy JIT might claw some of those benefits back" Good point. If you know the data can't be accessed in parallel by the user code, that safety guarantee might allow the JIT to do it anyway.
jasonjmcghee 1y ago
ECS's main performance benefit comes from reducing cache misses. Memory that's accessed together is stored together. So for example, if you're calculating physics in a game, you perform all the needed physics operations on values stored contiguously in memory. Great cache locality means huge reduction in cache misses and performance benefits. If you had millions of entities and are performing each entity's set of operations (rendering, IO, AI, physics, etc) entity by entity, you might be getting a lot of cache misses. There's an entire talk by Bob Nystrom (of crafting interpreters and game programming patterns) arguing you likely don't need to use ECS unless you have the exact problem of high cache miss rate.

by k__ 1y ago

I had the impression, ECS would boost performance mainly by allowing the systems to run in parallel on the entities. Isn't this kinda moot in a single threaded runtime?

aapoalas 1y ago

This is definitely the more meaningful/influential performance benefit of ECS in game development, I believe. JavaScript will not allow for that as you point out. Perhaps a sufficiently crazy JIT might claw some of those benefits back, though? Not sure. But: the lesser but still impactful performance benefit of ECS is the usage of Struct-of-Array vectors for data storage. JavaScript can still ruin that benefit by always accessing all parts and features of an Object every time it touches one, but it is a less likely thing to happen. So, there is a benefit that JavaScript code itself can enjoy. Finally, there is one single "true System" in a JavaScript engine's ECS: the garbage collector. The GC will run through a good part of the engine heap, and you can fairly easily write it to be a batched operation where eg. "all newly found ordinary Objects" are iterated through in memory access order, have their mark checked, and then gather up their referents if they were unmarked. Rinse and repeat to find all live/reachable objects by constantly iterating mostly sequential memory in batches. This can also be parallelised, though then the batch queue needs to become shareable across threads. The sweep of the heap after this is then a True-True System where all items are iterated in order, unmarked ones are ignored, marked ones are copied to their post-compaction location, and any references they hold are shifted down to account for the locations of items changing post-compaction.

k__ 1y ago
"a sufficiently crazy JIT might claw some of those benefits back" Good point. If you know the data can't be accessed in parallel by the user code, that safety guarantee might allow the JIT to do it anyway.

jasonjmcghee 1y ago

ECS's main performance benefit comes from reducing cache misses. Memory that's accessed together is stored together. So for example, if you're calculating physics in a game, you perform all the needed physics operations on values stored contiguously in memory. Great cache locality means huge reduction in cache misses and performance benefits. If you had millions of entities and are performing each entity's set of operations (rendering, IO, AI, physics, etc) entity by entity, you might be getting a lot of cache misses. There's an entire talk by Bob Nystrom (of crafting interpreters and game programming patterns) arguing you likely don't need to use ECS unless you have the exact problem of high cache miss rate.