Hacker News Reader

Comment by sirjee | Hacker News Reader

Not sure I understand the relationship between real-time guarantees and performance.

Performance: Computing pi to a billion as quickly as possible

Real time guarantee: When a hook for an event is called it transfers all computation to that call within a time limit predictably and deterministically

Please correct me if I am wrong.

One of the core characteristics of a real time operating system is that it has to service events within guaranteed time.

It has to start servicing events within a guaranteed time, but completing them is another matter. If you have multiple tasks running in parallel and a lot of incoming events, constantly switching to service them will delay completion of your ongoing tasks wrecking their performance, and eventually the scheduler will get overloaded.

So it depends on the cost of context switching, which is typically very high, and the frequency of context switches. Real time OSes are really important for applications where you have lots of lightweight tasks that need to be handled very promptly. If you have long running tasks (long running in CPU world, which can be fractions of a second) constantly getting interrupted and context switched can brutalise performance.

I have a degree in the subject matter and I also run QNX so I know how it works and am well aware of what the trade-offs are, thanks. Before I even graduated from the university, I used to write lots of code which ran inside of interrupt requests on the Commodore 64 and Commodore Amiga where finishing before the next vertical blank was critical, so you could say that I've dealt with the practical even before I graduated in the theoretical. Not only did the code have to respond within the next vertical blank, ALL of it had to finish by the end of it, else I would have been the laughing stock of the scene. And before you cut in again, yes it was computationally expensive, therefore the code had to be really, really fast to get it all computed in time.

When I write something here, I've already done it, and often on multiple occasions in multiple scenarios at multiple companies, therefore I don't need a lesson.

I’m sorry if I offended you, but the question was about performance and event response is only one aspect of it, so I thought I’d expand on that for the benefit of anyone reading the thread.

Fine. Apology accepted.

Real time response/latency and performance/throughout are usually a tradeoff - you can’t have both.

Only if you don't consider metrics like tail latency to be performance metrics.

Reply on news.ycombinator.com