Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We chose Java for our high-frequency trading application

medium.com

Post reply on HN
Print view View original

111–120 of 287 posts

Re: We chose Java for our high-frequency trading application

#111

Post by liuliu »

emidln wrote: post #91

All HFTs I'm aware of have a continuum along developer_speed to execution_latency. On the developer_speed end we have things like Python (or Perl, Ruby, etc) -> Java/C# -> C++/C/assembly -> programmable nics/fpgas/gpus with access to the nic -> custom hardware. At each part of the path development gets much harder, dev times go up, talent gets harder to find, and the whole thing becomes much more expensive. The trick…

I am trying Swift in the hope of integrating developer speed while with not too terrible performance. Julia would be another interesting choice in this space. Of course, as you get to nanoseconds, any language choice is irrelevant.

Re: We chose Java for our high-frequency trading application

#112

Post by tzs »

Several commenters have brought up garbage collection.

I'm curious. How much heap memory do HFT applications typically allocate in a day?

I'd expect them to be doing most of the work, or at least most of what actually needs low latency, in locally allocated primitives which would be on the stack. If that's the case, you might be able to turn off garbage collection and just stick enough RAM in your computer that it takes a day to fill up with garbage. Once a day, reboot.

Re: We chose Java for our high-frequency trading application

#114

Post by motives »

dangerbird2 wrote: post #8

Does anyone know if C#/dotnet is used in HFT to any extent? I'd imagine proper support for user-defined unboxed types (structs) and non-hacky methods for manual memory management (unsafe) could give it major advantage over Java with much of the QoL improvements java has over C++.

This is definitely an area of recent improvements, and I don't think modern .net (.net core 3.1 - .net 5) is comparable to older school .net here. Whilst GC isnt quite on JVM level yet (no serious custom GC's afaik), the .net team is clearly paying attention to performance(https://devblogs.microsoft.com/dotnet/performance-improvemen...). As you mention, increased ease of use for structs in the form of Span is having quite significant impact in a lot of common .net libraries, aswell as the recent availability of hardware intrinsics for more performance sensitive tasks. I can certainly say F# has had a pretty decent impact in the finance sector in London and likely elsewhere (not sure about HFT however), mostly as a result of this attention to both performance and developer experience.

Re: We chose Java for our high-frequency trading application

#115

Post by hinkley »

oppositelock wrote: post #74
cashewchoo wrote: post #5

I think I actually saw these folks present at JavaOne a couple years ago? Either that or there's more than one shop branding itself as "HFT" that uses Java. I worked in the industry and it's always a little funny to see who calls themselves HFTs vs quants. Basically, there's a bit of a spectrum of fast vs smart. In general it's hard to do incredibly smart stuff fast enough to compete in the "speed-critical" bucket of…

I discovered something amazing when working with some people who were writing HFT software. Why do you need 1TB of RAM in these machines? Because when you're Java based, you want to avoid stop-the-world GC pauses. These trading systems only have to be up from 9:30AM-4:30PM EST, so they simply disable GC altogether! At the end of a trading day, restart the app or reboot the system.

I wonder if it would be cheaper for them to have a hot standby system, and swap them every few hours.

Re: We chose Java for our high-frequency trading application

#116

Post by u10 »

didip wrote: post #113

This is off tangent, I am surprised that the largest of FAANGM companies aren't trying to muscle into HFT or Quant industries. It seems right on their wheelhouse: highly technical and makes a lot of money.

It used to make a lot of money, there are now enough players that margins are actually relatively thin.

Re: We chose Java for our high-frequency trading application

#117

Post by paulfurtado »

dcolkitt wrote: post #94
oppositelock wrote: post #74

Earlier quoted context omitted.

I discovered something amazing when working with some people who were writing HFT software. Why do you need 1TB of RAM in these machines? Because when you're Java based, you want to avoid stop-the-world GC pauses. These trading systems only have to be up from 9:30AM-4:30PM EST, so they simply disable GC altogether! At the end of a trading day, restart the app or reboot the system.

Even if you completely disable GC, Java is still allocating tons of ephemeral objects on the heap. Which in turn is leading to expensive and unpredictable page faults. In contrast, C++'s default is to allocate objects on the heap unless you knowingly call new/malloc. Of course, it's possible to write Java in such a way to minimize this type of heap-thrashing. But by that point, you're already doing the equivalent of…

If you add -XX:+AlwaysPreTouch to the JVM arguments, the JVM will pre-touch the entirety of the heap at startup time to avoid unpredictable page faults through the life of the application.

I'd imagine other HFT companies may also pay for the Azul JVM which goes even further and comes with a kernel module that the JVM coordinates with for memory allocation. The kernel module pre-reserves x% of system memory at the time it is loaded.

Re: We chose Java for our high-frequency trading application

#118

Post by rch »

deepGem wrote: post #105
oppositelock wrote: post #74

Earlier quoted context omitted.

I discovered something amazing when working with some people who were writing HFT software. Why do you need 1TB of RAM in these machines? Because when you're Java based, you want to avoid stop-the-world GC pauses. These trading systems only have to be up from 9:30AM-4:30PM EST, so they simply disable GC altogether! At the end of a trading day, restart the app or reboot the system.

I guess what you mean is the no-op garbage collector which is available in Java 11 http://openjdk.java.net/jeps/318 Even this isn't fail proof right ? Last-drop latency improvements. For ultra-latency-sensitive applications, where developers are conscious about memory allocations and know the application memory footprint exactly, or even have (almost) completely garbage-free applications, accepting the GC cycle might…

Depends if your returns are based on writing faster code or shipping correct code faster. Once the advantages of the former are eliminated, optimize for the latter.

Re: We chose Java for our high-frequency trading application

#120

Post by MaxBarraclough »

tzs wrote: post #112

Several commenters have brought up garbage collection. I'm curious. How much heap memory do HFT applications typically allocate in a day? I'd expect them to be doing most of the work, or at least most of what actually needs low latency, in locally allocated primitives which would be on the stack. If that's the case, you might be able to turn off garbage collection and just stick enough RAM in your computer that it ta…

> you might be able to turn off garbage collection and just stick enough RAM in your computer that it takes a day to fill up with garbage. Once a day, reboot

Assuming the code can be made not to allocate much, this approach could probably be made to work, [0] but I imagine it would make more sense to just configure the GC to run once a day.

[0] https://openjdk.java.net/jeps/318

Post reply on HN