“What the Hardware Does” Is Not What Your Program Does: Uninitialized Memory

Re:“What the Hardware Does” Is Not What Your Program Does: U... by anp on Sunday July 14, 2019 @05:41PM (#20436287)

> The idea that you can ignore the real hardware is particularly unhelpful in Rust, because it's a great fit to low-level problems where the real hardware is a big deal. For example, at work, we have a Rust program where we routinely need to think about NUMA placement and cache coherency protocols. Those don't exist in the Rust abstract machine at all!

If I understand Ralf's overall model here, I think they'd argue that this sort of reasoning must be done within the context of the abstract machine's behavior for std::ptr::{read,write}_volatile, no?

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by twic on Sunday July 14, 2019 @06:26PM (#20436614)

The kind of reasoning we do is "if thread A writes to this location, then next time thread B writes to this location, it will have to take ownership of the cache line, which will take N cycles, so let's not do that". I don't think that kind of performance reasoning maps on to anything in Rust.

[ Parent | on HN ]