3 ms·
That's true, I'm very familiar with tuning Java to be cache aware. I've played around with FlatBuffers[1] in my spare time to good effect which seems to be the
by vvanders 10y ago
That's true, I'm very familiar with tuning Java to be cache aware. I've played around with FlatBuffers[1] in my spare time to good effect which seems to be the only sane way of doing cache aware layout in Java.
That said the amount of restrictions you have makes it really painful(needing to use pre-allocated wrappers if you want to read more than intrinsic types, not being able to grow/shrink anything). There's sun.misc.Unsafe, but that isn't available on every JVM implementation.
A GC is going to by nature introduce pauses if since at some point it's going to need to do work on the memory you hold. There's a set of tunable tradeoffs but it will impact latency.
I guess my meta point is if throughput and latency are paramount to you then you should really consider a language suited for it. For me today that would be Rust or C++ depending on how risk-adverse the organization you're working with is.
[1] https://google.github.io/flatbuffers/ https://google.github.io/flatbuffers/
- desdiv 10y ago>There's sun.misc.Unsafe, but that isn't available on every JVM implementation. There's also talk about the possible removal of sun.misc.Unsafe in Java 9¹. ¹ http://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disaster-in-the-making/ http://blog.dripstat.com/removal-of-sun-misc-unsafe-a-disast...
- stickfigure 10y agoJeeezus... I've been writing Java since before many HNers were born, and somehow I never noticed that class. The Oracle people are right about this one. Rip it out and sterilize the wound with fire.
- needusername 10y agoOracle backpedaled from that pretty quickly.
- eggy 10y agoPersonally, I am looking to Rust or Pony, but both are too young, and the tooling is quite there, not to mention recruitment potential. Erlang/LFE/Elixir are great for certain distributed HFT tasks, but not the core for speed and latency. The JVM is in HFT in because of sheer inertia; it has been worked on for so many years to shoehorn it in, and some smart people have made it work. The tooling is mature, and there are alternative syntaxes close to it like Kotlin that remove a lot of the noise for code review and maintenance. The JVM is the reason I stayed away from Clojure, even though I like Lisp/Scheme syntax and the semantics. Where is Clojure-clr nowadays?
- Gibbon1 10y agoThere was an article on HN talking about the improvements go has made to their gc over the last few releases. Umm... here https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06eb7#.qssombjyp https://blog.twitch.tv/gos-march-to-low-latency-gc-a6fa96f06... It sort of looks like language developers are finally getting the point that while you can easily deal with a throughput problem by just throwing faster processors, more processors, and or memory at at it, working around long gc pauses is just pain all around.