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

41–50 of 287 posts

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

#41

Post by posnet »

jariel wrote: post #30
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…

Better or worse than Ad tech based companies?

Most traders I've met have been fairly honest about contributing nothing to society, or that the world would probably be a better place is large segments of the finance industry disappeared tomorrow.

I can't say the same for the majority of developers from Facebook or Google I've met.

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

#42

Post by kasperni »

_lbaq wrote: post #21
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...

ZGC and Shenandoah are not on par with C4. ZGC isn't even generational (yet).

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

#44

Post by pron »

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…

> if it was universally good as it's written, they would have essentially solved one of the major problems not just for Java, but for a large amount of languages.

In a way, low-latency GCs like C4 and ZGC have done that, but implementing them requires a large and experienced team, and not many languages even try to target high performance to begin with.

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

#45

Post by muststopmyths »

dangerbird2 wrote: post #18
ed25519FUUU wrote: post #14

Earlier quoted context omitted.

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

Here are my guesses (in addition to your points):

- Until late in it's lifecycle, .net runtime performance was worse than JVM.

- Also, the Windows TCP stack, re-architected with Vista, had severe latency issues, which probably led to wholesale abandonment of that platform for low-latency applications. Some of these problems were fixed in Windows 8, but it was probably too late by then.

(These two points are based on my own experience with Windows/CLR/JVM in the mid/late 2000s and some anecdotes I heard second-hand. So I can't really cite any public sources for them)

I'm sure the fact that you can customize Linux to the extreme and the lack of .Net on Linux in those days probably had a lot to do with the choice of Java, in addition to the above.

However, based on my reading of blogs like Mechanical Sympathy [1] a while ago (~8-10 years), there does seem to have been some demand for .Net-based solutions in the HFT space. They had code for both Java and C# in their public code.

[1]https://mechanical-sympathy.blogspot.com/

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

#46

Post by secondcoming »

taion wrote: post #7

There's a major historically-contingent component to this, too. The Island ECN, later absorbed into NASDAQ's ECN, originally ran its matching engine as one of these low-latency Java processes, writing everything using explicit object pools to avoid doing any GC on the critical path, as this was long before Zing was around. This was a pretty reasonable choice at the time, as this was long before C++11 was around, and…

I bet they used a bit of sun.misc.Unsafe too

https://blogs.oracle.com/javamagazine/the-unsafe-class-unsaf...

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

#47

Post by pjmlp »

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

A language that brings the Gentoo installation experience to external libraries and requires special purpose data structures to compile properly?

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

#49

Post by zarkov99 »

jariel wrote: post #30
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…

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 than they will HFT.

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

#50

Post by jariel »

posnet wrote: post #41
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…

Better or worse than Ad tech based companies? Most traders I've met have been fairly honest about contributing nothing to society, or that the world would probably be a better place is large segments of the finance industry disappeared tomorrow. I can't say the same for the majority of developers from Facebook or Google I've met.

???

I run ads and campaigns for my company and they are an absolutely essential form of communication.

... as almost everyone running and actual business knows.

Yes - it can be very inefficient - but it's not inherently wasteful.

You're making the wrong comparison - the 'Digital Ad Industry' could be compared to 'Digital Banking Industry' perhaps - i.e. useful overall but deficiencies exist.

HFT is one of the ares in which there are no reasonable externalities.

Better/faster tech for CDNs etc. can be developed without the HFT industry.

Post reply on HN