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

11–20 of 287 posts

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

#11

Post by dwohnitmok »

I feel like there's a pretty big change in scale that happens over the course of the article. It starts off talking about a field that needs to "gain those few crucial microseconds" and then talks about a GC with an average and max pause rate of hundreds of microseconds.

I mean yeah those GC pause times are extremely impressive, but you're clearly operating against a different set of performance requirements than those teams that care about several microseconds of difference and it's a bit disingenuous to compare your own tech stack to them.

That being said I do appreciate articles like this that show just how far Java performance has come over the last few decades.

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

#12

Post by taion »

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…

There are still a number of players in the HFT space that use JVM languages.

I think as with any space, if you really zoom into the details, you see a lot of diversity. You're obviously right in that people who are still hitting the CPU can't compete with people that do everything on FPGA, but it seems like there's still plenty of money to be made by people who are just a bit less fast than that.

I've heard people argue that they prefer being in that sort of space, too, as it gives them a bit more room to compete on their own alphas, and tends to be a bit less winner-take-all.

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

#13

Post by tormeh »

troist wrote: post #2

I've used Java and C++ in a few low latency applications and I do prefer Java in certain scenarios. The whole ecosystem around Java makes rapid development easier meaning we could make safe changes quicker which is a big benefit in trading systems where you need to react to unpredictable market conditions. The article focuses quite heavily on Zing vs Hotspot but it'd be interesting to see an analysis of a variety of…

If you want something that's as fast as C++, but safer to work with, then there's this new language, has been on HN frontpage once or twice.. I can't remember the name, but I think it had something to do with oxidation of metals.. Something about shellfish as well..

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

#14

Post by ed25519FUUU »

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++.

I don’t think Java was chosen because it had ways to do manual GC. I think the developers were comfortable with Java, so they wanted to find a way to fit it into something “fast”.

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

#15

Post by ISL »

pron wrote: post #4
troist wrote: post #2

I've used Java and C++ in a few low latency applications and I do prefer Java in certain scenarios. The whole ecosystem around Java makes rapid development easier meaning we could make safe changes quicker which is a big benefit in trading systems where you need to react to unpredictable market conditions. The article focuses quite heavily on Zing vs Hotspot but it'd be interesting to see an analysis of a variety of…

ZGC is at 1-2ms max pause time in JDK 16 and is expected to reach <1ms max pause time within a year.

Isn't this architecture dependent?

It is hard to imagine the same performance on a Pentium Pro.

What is the right processor-independent measure for latencies like this? Number of clock-ticks? That seems flawed, too.

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

#16

Post by posnet »

Except that HFT firms don't call themselves HFT any more, they re-branded to ultra-low latency trading.

And FPGAs are the norm now, not the exception.

Sure, Java still has its place, but implying that it is anywhere in the hot loop of a contemporary ULL system is wrong at best and disingenuous at worst.

I mean just read the abstracts from this years STAC conference. https://www.stacresearch.com/spring2020

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

#17

Post by [deleted] »

tormeh wrote: post #13
troist wrote: post #2

I've used Java and C++ in a few low latency applications and I do prefer Java in certain scenarios. The whole ecosystem around Java makes rapid development easier meaning we could make safe changes quicker which is a big benefit in trading systems where you need to react to unpredictable market conditions. The article focuses quite heavily on Zing vs Hotspot but it'd be interesting to see an analysis of a variety of…

If you want something that's as fast as C++, but safer to work with, then there's this new language, has been on HN frontpage once or twice.. I can't remember the name, but I think it had something to do with oxidation of metals.. Something about shellfish as well..

[deleted]

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

#18

Post by dangerbird2 »

ed25519FUUU wrote: post #14
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++.

I don’t think Java was chosen because it had ways to do manual GC. I think the developers were comfortable with Java, so they wanted to find a way to fit it into something “fast”.

That was my assumption, considering how dominant Java is in finance. Also, as the article notes, Java has a pretty great runtime ecosystem, allowing devs to choose between hotspot, azul, graal, etc. depending on their runtime needs, while dotnet devs are more-or-less limited to Microsoft-controlled offerings of Mono, dotnet 4.x and dotnet core/5+.

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

#19

Post by ifdefdebug »

taion wrote: post #12
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…

There are still a number of players in the HFT space that use JVM languages. I think as with any space, if you really zoom into the details, you see a lot of diversity. You're obviously right in that people who are still hitting the CPU can't compete with people that do everything on FPGA, but it seems like there's still plenty of money to be made by people who are just a bit less fast than that. I've heard people ar…

I think GP had that covered mentioning a [fast][smart] continuum.

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

#20

Post by krisgenre »

A sting of nostalgia and coincidence perhaps, was thinking about Java and HFT only a few days ago.

I worked as an offshore employee for E*Trade back in 2010 - 2012. Their desktop app for HFT was written in Java Swing and their web client too was running on the JVM but the 'services' layer the one that interacted with the database was written in C++.

Four years ago heard that they were re-writing the desktop app in JavaFX.

Post reply on HN