Hacker News Reader

Comment by reedf1 | Hacker News Reader

> Well, C++ might be “low latency” when it comes to executing code, but it’s definitely not low latency when it comes to rolling out new features or even finding devs who can write it.

Every time one of these articles roll around it's always the same point. At the end of the day some systems actually do need low-latency in real time and you will be steamrolled by competitors if it is not.

View on HN

And every time someone makes this point I ask them what the latency of their destructor chains are and no one seems to have measured.

If you don't live and die by a profiler, they you're flying blind.

I've seen a lot of claims that "our system absolutely requires low latency" and then when you dig, it turns out that there is a whole lot of praying under there.

That doesn't invalidate your point, to be fair. But we keep talking about all these mythical hard-real time applications and every time I explore, that actual space gets smaller and smaller.

edit: just to be clear, I brought up destructor chains because they are a potentially large, potentially unpredictable cost in the code that may profoundly depend on the heap layout that is not immediately visible looking at the code. They are something that you need to carefully think about and measure to understand their true cost.

Is c++ that unusual these days? Its the world I live in so I wouldn't know. I wouldn't expect it to be in web stuff backend or client side, but I figured anything embedded big enough to have an OS instead of just a BSP would be using c++. All those triple A game titles use it I'd assume. And most operating systems and drivers. And probably at least a quarter the native applications for desktop or mobile? The college I went to doesn't teach languages, but they have favored languages for assignments. When I was there it was c or java, but starting a decade ago when Bjarne joined the department c++ was the favored, so all thoae grads are at least familiar with it.

the problem is that low latency is not absolutely defined, and it's a bit of a buzzword so people who don't know about the specific niches just don't get why java won't cut and you need c++ rust or similar to meet targets there.

The most realistic definition of a real-time system that I have heard is: It is a RT system when your results are ready when they need to.

That's it. That's what an RT system is. I don't care if your latency is 1us, 1ms, 1s or 1h. If you can't miss the deadline then your system is a real-time one.

Low-latency then depend on how your strategy works and your particular needs. It's useless to have sub ms timing of stock market data if your results take seconds to calculate.

Of course, your strategy that takes 1s might be more lucrative than one that takes 10ms to calculate. Then it's up to you and your algos.

That’s correct: a real-time system can be slower, if that’s what it takes to be deterministic. And usually that is one of the things it takes.

I have never understood why people might think it ought to be faster.

It is another classic confusion between a definition in technical jargon (maybe even a formal definition) and the vernacular. Real-time for most people means "instantaneous," and definitions of latency are not considered. So it is a shorthand for "low-latency" without a rooted understanding latency at all.

I don't understand all this confusion about what RT means, this is the definition of a RT system. If you can't complete the computation within the given deadline whatever partial result is discarded and the computation starts from scratch.

Decoding video and interactive rendering is a great example of an RT system. If you can't construct a frame within (usually) 16 ms you skip it and start with the next one.

There is a difference between hard real time and soft real time. Hard real time systems mean that missing a single deadline may be a crash, whereas a soft real time system, missing a deadline just causes a degradation. Video is definitely soft real time.

Hard and soft real time depend entirely on the context. An example of hard real time is flight control. The whole sensor - actuator - decision process must happen within the given threshold.

But decoding video in practice isn't usually realtime because you still have to do it when you don't have kernel support and are at the whim of your kernel's scheduler which is basically always.

It's a good example of a problem where a realtime system would be useful but it's not a good example of a real-life realtime application (usually).

You can write low latency Java but by the time you do, the C++ will have taken a similar amount of time.

The time to market argument is really stupid imo.

I really was hopeful that the article would move beyond this point. It even teased with a "In fact, there is good reason to question the idea that C++ is genuinely “faster” or has a “lower latency” than Java at all."

But then it just restates the development time point! (at least acknowledging that is absurd this time)

> First, there’s the (slightly absurd) point that if you have two developers, one writing in C++ and one in Java, and you ask them to write an platform for high-speed trading from scratch, the Java developer is going to be trading long before the C++ developer.

Reply on news.ycombinator.com