3 ms·

I'm in the opinion that real-time desktop is already overdue. I can understand that in the olden days the perf benefit from dropping latency guarantees were wor

by zokier 6y ago

I'm in the opinion that real-time desktop is already overdue. I can understand that in the olden days the perf benefit from dropping latency guarantees were worth it (classic latency vs throughput optimization), especially on servers where current operating systems draw their lineage (NT and UNIX). But these days with beefy, even overpowered CPUs, and 25 years of OS/real-time research later I would imagine that we would be in a place that the tradeoff would look different. Of course just slapping RT kernel in a modern system alone would not do much good. The whole system needs to be thought with RT in mind, starting from kernel and drivers through toolkits/frameworks and services up to the applications themselves. But ultimately the APIs for application developers should be nudging people to do the right things (whatever those would be)

cycloptic 6y ago
We're probably already halfway there with modern apps, if you consider that any program with hardware-accelerated graphics is already performing rendering as a stateless operation in a separate thread pool running on an entirely different processor.
flohofwoe 6y ago
You need to go down to the hardware even, a realtime kernel running on mainstream CPUs and GPUs might not be enough (I wonder if a realtime system can even be built with current mainstream CPUs and GPUs): The video systems in 8-bit home computers only worked because the entire system provided "hard realtime" guarantees. CPU instructions always were the same number of cycles and memory access happened at exactly defined clock cycles within an instruction. Interrupt timing was completely predictable down to the clock cycle, etc etc. Modern computers get most of their performace because they dumped those assumptions and as a result made timings entirely unpredictable (inside the CPU via caches, pipelining, branch prediction, etc etc...), and between system components (e.g. CPU and GPU don't run cycle-locked with each other).

by zokier 6y ago

cycloptic 6y ago

We're probably already halfway there with modern apps, if you consider that any program with hardware-accelerated graphics is already performing rendering as a stateless operation in a separate thread pool running on an entirely different processor.

flohofwoe 6y ago

You need to go down to the hardware even, a realtime kernel running on mainstream CPUs and GPUs might not be enough (I wonder if a realtime system can even be built with current mainstream CPUs and GPUs): The video systems in 8-bit home computers only worked because the entire system provided "hard realtime" guarantees. CPU instructions always were the same number of cycles and memory access happened at exactly defined clock cycles within an instruction. Interrupt timing was completely predictable down to the clock cycle, etc etc. Modern computers get most of their performace because they dumped those assumptions and as a result made timings entirely unpredictable (inside the CPU via caches, pipelining, branch prediction, etc etc...), and between system components (e.g. CPU and GPU don't run cycle-locked with each other).