Hacker News Reader

You assume that this is being used by a user.

These numbers are meaningless unless accompanies by specific usecases - don't just choose java or C++ just because the benchmark says its fast or the best.

High frequency trading needs that extra milli second, but a batch job or backend computation won't.

View on HN

Also if you want to do high frequency you probably don't won't GC.

...or will you? https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...

Touché :-)

'allows pauseless garbage collection regardless of the Java heap size'. I thought this is not possible.

Clearly it is, since the C4 collector manages to do it. To be fair though, the "pauseless" part does come at the cost of a slight slowdown in normal code execution since it instates read barriers to work its magic. This means the lack of pauses is paid for by significantly higher overall CPU overhead for garbage collection compared to a collector design that does include pauses. It could be worth it for some workloads where it is very important to have low 99th percentile response times though.

I'm pretty sure that Jane Street begs to differ. They're a OCaml company and they do very well on high frequency trading.

Does the ocaml backend do the high frequency trading?

As far as I understand, it does.

Milliseconds are at least 4 orders of magnitude too high for much of HFT.

Reply on news.ycombinator.com