For < 10 µs latency there are hoops in any language, as well as the OS, like thread-pinning, marking CPU cores unusable for OS interrupt handling, all kinds of virtual memory issues, etc. And you can't afford a single network hop or even SSD access.

True! It's not trivial to get 10 us latency even in C++, Rust, etc. You have to do OS-level configuration, and you can't touch network or disk.

But beyond that, the actual code you write is fairly natural for those languages. You can't allocate, and your code and data have to fit in the cache. But you can use normal language constructs, and most of the standard library - neither of which is true for Java.

And yet 90% of time we hear about this latency problems when speaking about a language, it's always about JVM... When it would be equally hard in any other dynamic language... What gives...

I don't know of any other runtime that gives you the tools to tune your latency and the GC other than the JVM.

GHC (Haskell)?

Err Dotnet? :)

Might be a side affect of Java’s dominance/popularity.

>And you can't afford a single network hop or even SSD access.

10µs ? You can't even afford that many function calls.

Seriously, 10µs is not a sensible target for a general purpose OS, maybe not even for a general purpose CPU. Achievable? Perhaps. But sensible? Not really.

That's really insanity to me. 10µs is a goddamn long time for a modern computer. That's 30000 clock cycles for a 3Ghz CPU. Each clock cycle can handle multiple instruction. It should be trivial to handle most light computations in this time as long as you ensure the data is in cache.

That's a very fair point. I suppose I'm too used to the idea that the code which runs with sub-N-µs latency is going to process a "lot" of data, and that there's no way it will all be in the cache (any cache).

I suppose that if you're working on small amounts of data every time your code executes, then this becomes vastly more reasonable.