An Architecture for Millions of Things

> 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.

Their big problem is making a procedural city generator that produces a convincing city at street level. There are lots of floorplan generators and things which produce vaguely reasonable buildings, but nothing good enough to make a video game grade driveable or walkable city down at street level. Unless they crack that problem, their game is going to suck.

- things of roughly similar total chunk sizes (constant + dynamic part) are stored in one "bucket", laid out contiguously in fixed-size slots, with a little leeway for growth inside

- there are buckets for each existing size of a thing

- if a thing outgrows the slot size of its bucket, it simply migrates to the bucket with the next bigger slot size

Isn't this exactly how many (most?) modern malloc implementations work? ... A series of buckets for different sizes of objects, combined with bitfields or free lists to keep track of which slots in each bucket are free?