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

61–70 of 287 posts

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

#61

Post by dcolkitt »

One thing to keep in mind, is that HFT is not just "one thing". It's a collection of many different strategies that are generally characterized by short holding periods, high portfolio turnover, and latency sensitivity. But depending on the specific strategy, the degree of latency sensitivity could vary by orders of magnitude.

A desk trying to gain first queue position at the opening auction is probably running in FPGAs or ASICs and aiming for 100 nanoseconds. A spot market maker needs to respond fast to new level formation, and is aiming for 10 microseconds on a C++ stack. An alpha-driven liquidity taker may be using complex ML models, and is running a Scala stack at 50 microseconds. An ETF market may just need to re-mark their quotes when the underlying shifts, and is fine with 250 microseconds on OCaml.

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

#64

Post by offtop5 »

colinmhayes wrote: post #59
offtop5 wrote: post #25

What's the upper salary cap for HFT engineers. I'm talking cash , not stock. From what I've seen above 200k is exceptionally rare.

If you're at a top firm like citadel you'll start at around 250.

What about an experienced dev in the Fintech space ?

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

#66

Post by winrid »

pak9rabid wrote: post #51

Speaking about JVM garbage collection, why isn't automatic reference counting being used instead of traditional garbage collection? It seems kind of like the best of both words in a automatic memory-managed environment of providing safety as well as performance. Languages like Objective-C and Swift have proven that this is very viable. I wonder what's keeping the JVM from adopting it?

Because allocation is slower with just reference counting, and the JVM is all about throughput. The downside is predictability, but newer memory managers are almost fully concurrent so soon it may not matter.

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

#67

Post by traK6Dcm »

howlin wrote: post #55
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…

> 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 trades and vice-versa there's barely any point in being ultra-fast in the "non-speed-critical" bucket because your alphas last for minutes to hours. Depending on the overall strategy, you can be smart and fast at once. If you have occasional alpha harves…

I think he means smart as in "how long your model prediction takes". If your neural net (haven't actually met anyone who uses these in trading) takes 5ms to make a prediction that'll lock you out of a whole lot of trading opportunities/strategies.

Speed always matters, no matter where on the smartness spectrum you are, but it's relative. If your model prediction takes 5ms you're not getting much ROI out of investing $1M into shaving off 50ns in your data processing. But if your end-to-end latency without prediction is 1ms, you better invest in getting that down.

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

#70

Post by fractionalhare »

jariel wrote: post #39
fractionalhare wrote: post #28

Earlier quoted context omitted.

The person you're replying to is almost certainly not using the word "safe" in the same sense you are. In particular: safety in trading has to do with risk management, strategy correlation, side effects, and correctness. Software security matters, in the abstract, but trading firms don't care about it nearly as much as tech companies do. The other thing is that being as fast as C++ is not compelling enough a reason t…

"Software security matters" I think the responder's version of 'safety' really boils down to 'null pointer safety' - not 'software security'. And even then, people keep talking about it like it's 'the thing'. Java has null 'references' as do most languages frankly and it's just 'a thing' almost never 'the thing' to be concerned about. 'What devs want' is basically something kind of like Java, but that compiles, predi…

That's fair. Instead of saying "software security" I should have been more specific in talking about memory and pointer issues. In that sense, yes Rust does offer some safety guarantees beyond preventing memory corruption vulnerabilities.
Post reply on HN