> So, yes, it takes time to read from memory. That's why we try to avoid allocations as much as possible.

This whole thing is summed up by some pretty basic physics. What you actually want to minimize is the communication of information between physical cores. Nothing else really matters. Certainly not terminology or clever tricks that effectively try to cheat thermodynamics. The cost of communicating information is almost always much more substantial than the cost of computing over that same information. The ALU is not nearly as power hungry as infinity fabric.

Minimizing core-to-core communication is a nice theory until you actually run workloads with unpredictable access patterns or legacy interfaces bolted on where you can't just flatten and pack everything for optimal cache locality. There's a whole separate world of pain once you start scaling out mutability and pointer-heavy structures: you get play-by-play races between TLB shootdowns, OS-level dirty page tracking and whatever the thread scheduler feels like that day.

In the old Windows NT days, the scheduler still wasn't that clever, so in multiple core servers it would throw processes around thrashing the whole cache and CPU context.

By pinning the processes to specific CPUs, the performance gains were quite visible.

Always wondered if it is possible/useful to model multi core CPU caches as CISC cores where the complex instructions are all the operations you can do with the L1 within the time frame of an L2 access

What the hell do allocations even have to do with time to read from memory...

It seems all of these Rust performance warriors have no understanding of computer architecture fundamentals.