4 ms·

there was at least one non-realized research project where the cache was exposed as part of the architecture to be managed by the compiler (ppc lets you do some

there was at least one non-realized research project where the cache was exposed as part of the architecture to be managed by the compiler (ppc lets you do some of that). i think thats a potentially very fruitful approach, but would it have helped the spectre situation in any way? oh, what you're suggesting in an analog for compiler driven speculation? that may have helped, and is also probably worth thinking about

ryanianian 8y ago
> but would it have helped the spectre situation in any way? Presumably a compiler could put cache-lookups and/or cache-waits in non-predictably (perhaps choosing to do so when it suspects a cache-miss anyway).
xenadu02 8y ago
Every single CPU architecture that has decided to lean on "smart compilers" has failed. Intel flushed billions down the drain on Itanium. They lit $100 bills on fire trying to make a smart compiler. It never paid off. Think about that for a minute. No matter how good your compiler I'll put my money on using hardware to solve Spectre. In the future I'd expect caches to gain some kind of exclusive tagging or set-aside a per-core reorder area. Fetches will have to go there until the instruction that performed the fetch is retired successfully, then the entry can be made visible. Other threads or cores won't observe any changes to cache state based on speculative execution. It will be complicated, cost some transistors, and have a minor but measurable performance impact. The perf impact being having to fetch the same memory address multiple times, possibly all the way from RAM, because the instruction that fetched it before you hasn't retired yet. I don't know what impact that will have on cache traffic. If we're all very lucky, it won't be possible to use L3/L2 as side channels and we can ignore them (we probably aren't that lucky).
- pjmlp 8y ago
  I just read Microsoft is having their own go at it. https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10/ https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_w...

ryanianian 8y ago

> but would it have helped the spectre situation in any way? Presumably a compiler could put cache-lookups and/or cache-waits in non-predictably (perhaps choosing to do so when it suspects a cache-miss anyway).

xenadu02 8y ago

Every single CPU architecture that has decided to lean on "smart compilers" has failed. Intel flushed billions down the drain on Itanium. They lit $100 bills on fire trying to make a smart compiler. It never paid off. Think about that for a minute. No matter how good your compiler I'll put my money on using hardware to solve Spectre. In the future I'd expect caches to gain some kind of exclusive tagging or set-aside a per-core reorder area. Fetches will have to go there until the instruction that performed the fetch is retired successfully, then the entry can be made visible. Other threads or cores won't observe any changes to cache state based on speculative execution. It will be complicated, cost some transistors, and have a minor but measurable performance impact. The perf impact being having to fetch the same memory address multiple times, possibly all the way from RAM, because the instruction that fetched it before you hasn't retired yet. I don't know what impact that will have on cache traffic. If we're all very lucky, it won't be possible to use L3/L2 as side channels and we can ignore them (we probably aren't that lucky).

pjmlp 8y ago
I just read Microsoft is having their own go at it. https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_windows_10/ https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_w...