4 ms·
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
by adwn 5y ago
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.
- amelius 5y agoIn short, CPU designers gave us the choice, whereas Rust only gives us "the Rust way or the highway".
- adwn 5y ago> Rust only gives us "the Rust way or the highway" What are you even talking about? Rust gives you plenty of choice, it even lets you create as many "non-free" abstractions as you'd like.
- amelius 5y agoBut 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.