> it would violate Rust’s principle of only paying for what you use
I guess I'm glad that Rust developers don't design CPUs, as we wouldn't have memory abstractions like cache coherent NUMA (which doesn't come for free).
Who said anything about "free"? chrismorgan wrote "only paying for what you use". In NUMA systems, pretty much every program uses and benefits from cache coherency.
Well, that depends on the details of the CPU architecture in question. Without knowing those details, I'd say probably yes, but userspace programs will need to ask the kernel to change the memory attributes of the mapped area they want to access non-coherently.
Case in point: a CPU plus a discrete GPU is technically a NUMA system, and low-level APIs like Vulkan explicitly expose the ability to allocate non-coherent memory. I strongly assume that accessing that memory doesn't incur coherency overhead.
But not at the language level, which is what started this thread.
As another example: compare "GC'd versus non-GC'd memory in Rust" to "coherent versus non-coherent memory in CPU architecture"; here Rust gives us just the bare machine, while CPU architects give us quite some abstraction plus a choice.
It is true that you could theoretically write a GC in Rust, but using it from the language itself would probably break ergonomics so much that you'd be better off with another language.
I guess I'm glad that Rust developers don't design CPUs, as we wouldn't have memory abstractions like cache coherent NUMA (which doesn't come for free).