Arm Announces Cortex-R82: First 64-Bit Real Time Processor

Re:Arm Announces Cortex-R82: First 64-Bit Real Time Processor by kccqzy on Monday September 07, 2020 @06:43PM (#24403568)

Actually realtime doesn't mean "responds faster than the fastest it needs to" but rather it means always responds faster than some predetermined threshold. A lot of the easier ways to make things fast (like caches, or even branch prediction) are inherently probabilistic; if the thing is in the cache you get wonderfully fast performance; if not performance falls off a cliff. A realtime system avoids that, making the average case much slower but the slowest case much faster. It basically flattens the latency distribution.

[ Parent | on HN ]

Re:Arm Announces Cortex-R82: First 64-Bit Real Time Processor by mayama on Monday September 07, 2020 @09:06PM (#24404283)

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?

[ Parent | on HN ]

Re:Arm Announces Cortex-R82: First 64-Bit Real Time Processor by wtallis on Monday September 07, 2020 @10:38PM (#24404762)

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.

[ Parent | on HN ]

Re:Arm Announces Cortex-R82: First 64-Bit Real Time Processor by StillBored on Tuesday September 08, 2020 @11:40AM (#24409473)

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.

[ Parent | on HN ]

Re:Arm Announces Cortex-R82: First 64-Bit Real Time Processor by jacobush on Tuesday September 08, 2020 @04:04AM (#24406198)

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.)

[ Parent | on HN ]