3 ms·

Does this mean realtime doesn't use caches and branch prediction a all? Or worst case of miss for cache or prediction miss is lower than realtime threshold?

by mayama 6y ago

wtallis 6y ago
A lot of hardware designed to support realtime applications will let you opt in or out of some of those features. So you have some ranges of memory that go through the usual cache hierarchy to off-chip DRAM, but you also have some memory that is directly mapped to on-chip SRAM that isn't a cache and therefore cannot suffer the latency penalty of a cache miss. Stuff like branch prediction probably isn't too useful to implement as a switchable feature. Instead, the core is designed so that mispredict latency is still reasonably short (short pipeline, in-order execution or OoO with a short reorder window). This means you won't get as much benefit from speculative work as you would on a desktop-class core, but you're probably not going to be as vulnerable to Spectre-style attacks, either.
jacobush 6y ago
In one application I worked on, the caches were turned off completely. Slower, but more predictable latencies, and most importantly, without the huge latency spikes we would occasionally get with caches enabled. (Because of large cache misses.)
StillBored 6y ago
Its perfectly possible to have realtime requirements and still have variable latency as long as all the variability is bounded. Think video playback or gaming, both of which run on traditional OS's because they tend to be fast enough to meet the frame deadlines. Of course as we all know, the requirements aren't "hard" so dropping a frame/etc is a non critical failure. So, there is a spectrum of realtime and how "hard" it needs to be. There are a lot of cases where simply having a real time OS on a traditional processor is fine as long as everything can be sufficiently bounded.

Does this mean realtime doesn't use caches and branch prediction a all? Or worst case of miss for cache or prediction miss is lower than realtime threshold?

by mayama 6y ago

Does this mean realtime doesn't use caches and branch prediction a all? Or worst case of miss for cache or prediction miss is lower than realtime threshold?

wtallis 6y ago

A lot of hardware designed to support realtime applications will let you opt in or out of some of those features. So you have some ranges of memory that go through the usual cache hierarchy to off-chip DRAM, but you also have some memory that is directly mapped to on-chip SRAM that isn't a cache and therefore cannot suffer the latency penalty of a cache miss. Stuff like branch prediction probably isn't too useful to implement as a switchable feature. Instead, the core is designed so that mispredict latency is still reasonably short (short pipeline, in-order execution or OoO with a short reorder window). This means you won't get as much benefit from speculative work as you would on a desktop-class core, but you're probably not going to be as vulnerable to Spectre-style attacks, either.

jacobush 6y ago

In one application I worked on, the caches were turned off completely. Slower, but more predictable latencies, and most importantly, without the huge latency spikes we would occasionally get with caches enabled. (Because of large cache misses.)

StillBored 6y ago

Its perfectly possible to have realtime requirements and still have variable latency as long as all the variability is bounded. Think video playback or gaming, both of which run on traditional OS's because they tend to be fast enough to meet the frame deadlines. Of course as we all know, the requirements aren't "hard" so dropping a frame/etc is a non critical failure. So, there is a spectrum of realtime and how "hard" it needs to be. There are a lot of cases where simply having a real time OS on a traditional processor is fine as long as everything can be sufficiently bounded.