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

91–100 of 287 posts

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

#91

Post by emidln »

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 is use as little of the bottom as you can get away with and control it from as high level as you can.

It would surprise me more to find an HFT that doesn't use Java at some part of their execution lifecycle. Not everything needs to be in microseconds, nanoseconds, or picoseconds, especially if you can factor it out of the critical path and do the work/build some data structures ahead of time.

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

#92

Post by usefulcat »

"An improvement can be discussed in the morning, and be implemented, tested and released in production in the afternoon."

I feel like they've buried the lead here. If the above statement is really as it sounds, I find that way more impressive than the fact that they were able to make java fast.

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

#93

Post by MaxBarraclough »

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…

> programmable nics/fpgas/gpus with access to the nic -> custom hardware

Are GPUs really any use here? Aren't they quite far from the NIC?

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

#94

Post by dcolkitt »

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.

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 C++'s manual memory book-keeping anyway. It's not like "just provision a ton of memory and turn off GC" is a free lunch.

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

#95

Post by otabdeveloper4 »

zarkov99 wrote: post #49
jariel wrote: post #30

Earlier quoted context omitted.

It's an entire industry devoted to wasting enormous energy, resources and intellectual capacity. There are simply no material external gains from HFT etc, it's completely zero-sum other than maybe a 'job creation program'. The site ridiculously talks about 'levelling the playing field' by extending HFT opportunities to other players, which is rich, considering the playing field could be 'levelled immediately' by some…

That is not un an entirely unfair characterization. However in my mind HFT practicioners are model citizens when compared to so many of the bright young minds working in the worlds largest tech companies. HFT is a neutral force in the world, while Ad driven tech is causing harm at a scale that is hard to overstate. History will judge the companies profiting from manipulating the worst in us in a much harsher light th…

Complaining about advertising is like complaining about money.

Business absolutely cannot exist without advertising. The need must be filled one way or another.

The same cannot be said about HFT and stock markets in general.

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

#96

Post by bloat »

Tade0 wrote: post #26

My friend spent two years working for a large bank as a (his words) "trader's bitch". Every day the trader would request a new feature and my friend had at most two hours to implement it. They used a combination of Python and highly GC-tweaked Java. This was six years ago, but I see that similar techniques are still used to this day.

In my experience this is a pendulum. Traders hire a few desk developers who are paid by the business, and who work directly with the traders in the same physical area. They crank out code under a lot of pressure for fast turn around, and eventually it becomes completely unmanageable and / or there is some disaster in production.

At that point the technology organisation starts taking by over, the desk developers are let go or they move into technology and start getting paid by technology instead of by the business. Things are now done in a more normal enterprisey software development way, and things are generally done more safely, with more design up front, and more documentation. Of course it also takes a lot longer to get anything done.

So traders decide to hire a bunch of developers, answerable only to them, and back to the start we go...

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

#97

Post by iAm25626 »

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.

seems pragmatic; remind me of this old story: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

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

#98

Post by Tade0 »

RankingMember wrote: post #72
Tade0 wrote: post #26

My friend spent two years working for a large bank as a (his words) "trader's bitch". Every day the trader would request a new feature and my friend had at most two hours to implement it. They used a combination of Python and highly GC-tweaked Java. This was six years ago, but I see that similar techniques are still used to this day.

Damn, seems like a good way to have a ton of buggy code in production.

Oh yeah. But the traders had just one KPI - money made.

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

#99

Post by unwoundmouse »

dcolkitt wrote: post #75
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…

You're making good points, but one thing I want to emphasize is that latency is not the sole dimension of competition in HFT space. Certain things may just be "table-stakes", but for many strategies table-stakes is the only requirement. Simply being "fast enough" may be fine if you have a smarter model, exploit niche opportunities overlooked by others, or are willing to shoulder certain risks that other HFTs are tryi…

what's your source for the fact that they are not competing on latency?

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

#100

Post by layer8 »

anthonypasq wrote: post #88
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.

why not just use C++ or something and never deallocate memory then?

Malloc is usually slower than GC-based allocation (which basically just increments a pointer). Of course, one can emulate this via custom allocators in C++. My guess is that Java development is just easier and quicker, and the JIT may even result in more effective optimizations than AOT compilation.
Post reply on HN