Re:An Architecture for Millions of Things
by jdmichal on Thursday July 14, 2016 @02:02AM
(#12091942)
The author clarified on Reddit [0] that the lists are separated per type, so a list will only contain data for a single actor. So the actors are likely looping over lists and processing each entry, which should look to the CPU like any other array-processing code and optimize pretty well. It's a bit deceptive, since actors would typically be isolated. Instead, it seems like the "big idea" here is simply separate different data types into different lists and process them with different threads, using message queues as the concurrency mechanism.
[0] https://www.reddit.com/r/programming/comments/4sp25q/xpost_r...
Re:An Architecture for Millions of Things
by anselm_eickhoff on Thursday July 14, 2016 @08:19AM
(#12093105)
Exactly, and messages are divided into buckets which contain only one kind of (type of message, type of receiver)-combination. If you then iterate over that, you are going to execute very similar code repetitively.
I guess my epiphany was that exactly because actors are isolated, I could manage them like this and do some very primitive fast array iteration, while still using a nice high-level pattern to implement the actual game logic.
> let's have a look at the very few CPU center-of-attention prediction rules:
Modern high-end CPUs have incredibly powerful branch and cache prediction machines that use much more complicated rules than the 3 listed here.
Additionally, the actor model is horrible for cache consistency. Actors only run for short bursts, so both the instruction and data caches are constantly getting blown out by context switches (even lightweight context switches that don't involve the OS). By their very nature, actors are focused on different things. The "loop over lots of objects" paradigm would almost certainly deliver higher cache performance, at the very least because you're running the same code over and over again.
Edit: that's not to say that the actor model gives worse performance in general - just for certain workloads.