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

21–30 of 287 posts

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

#21

Post by _lbaq »

pizza234 wrote: post #9

I'd be curious about knowing the technical details, as the article is pretty much an advertisement. Example: the vast majority of the GC section is about GC in general; only a small part is specific about C4, and with little details. Specifically, the C4 looks very interesting, although I'm a bit perplexed because, if it was universally good as it's written, they would have essentially solved one of the major problem…

There are free GC's now that is on par with C4, ZGC and Shenandoah, improving vastly on the latency of the G1 default GC.

Here is a good article on them. https://blogs.oracle.com/javamagazine/understanding-the-jdks...

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

#23

Post by _lbaq »

ISL wrote: post #15
pron wrote: post #4

Earlier quoted context omitted.

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.

Sort of, it you have to have a 64 bit CPU.

Here is a more in-depth article on how it works, using pointer coloring.

https://www.programmersought.com/article/29543432001/

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

#26

Post by Tade0 »

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.

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

#27

Post by cashewchoo »

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…

Yeah absolutely. There's money to be made across the spectrum of fast and smart. My experience is just way on the left side, where the special sauce is only barely statistics-y but extremely technical (both from a software/hardware standpoint and market microstructure saviiness standpoint).

I'm not trying to gatekeep who can call themselves HFTs or not. The main thing I find funny is if you ask 10 firms if they're HFT or quant shops, it will probably not actually line up all that well with exactly how many orders they send or how speed-sensitive they are.

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

#28

Post by fractionalhare »

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

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 to replace C++ for their use cases. If anything, Rust's dependency management story would be the thing to highlight (this is part of what's compelling about the JVM).

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

#29

Post by darksaints »

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 is no singular definition of HFT. The extreme end of low latency is really only applicable for market making systems, but there are plenty of systems in the HFT sphere that do not rely on market making latencies. For example, those microwave links you're talking about? Those are specifically for cross exchange arbitrage. In that domain acceptable latencies go up quite a bit, and general purpose computing is still quite competitive.

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

#30

Post by jariel »

posnet wrote: post #16

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

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 really basic regulation and a few smart queuing algorithms for placing orders.

Post reply on HN