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

131–140 of 287 posts

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

#131

Post by Androider »

benjaminjackman wrote: post #121
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.

Speaking from experience with JVM HFT applications (we used Scala). There are a lot of tricks though to not require 1TB. And allocation in general is a bad idea even if you don't collect because it scatters stuff all over memory and messes up cache locality. You really, really don't want to allocate in a performance sensitive jvm application if you can avoid it. It's the opposite of a lot of what I was told and taugh…

1TB of RAM is cheap though, versus spending engineering hours.

Reminds me of the classic WTF "That would've been an option too" https://thedailywtf.com/articles/That-Wouldve-Been-an-Option...

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

#133

Post by btilly »

I had to laugh at one line.

PHP or Perl are called interpreted because the interpreter (installed on the destination machine) compiles each line of code as it goes.

Yeah, that hasn't been true of most "interpreted languages" in decades. The most common interpreted languages that I can think of where you parse as you go are shells like bash.

Languages like Perl and PHP are called interpreted because an interpreter runs the script. But the interpreter actually compiles the code first and then runs off of the compiled representation. Which is byte code - just like the JVM. If you put energy into it, you can use all the same techniques that the JVM does. As a practical example, both nodejs and pypy (a fast variant on Python) have a JIT. Julia regularly hits speeds for numerical calculations that is fully competitive with C++ and FORTRAN.

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

#134

Post by fractionalhare »

troebr wrote: post #31
tormeh wrote: post #13

Earlier quoted context omitted.

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

I was surprised there was no mention of it in the article. Maybe it's not used commonly in the trading space?

If I said Rust is rarely used in trading I'd be still overstating its adoption. There is approximately no Rust code in buy side finance. It exists in the sense that you could find something written in it somewhere, even it it's just an infra tool used by one of the software engineers. But I would be very surprised to hear of any trading firm that uses it in the hot path.

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

#135

Post by nobleach »

paulfurtado wrote: post #117
dcolkitt wrote: post #94

Earlier quoted context omitted.

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…

If you add -XX:+AlwaysPreTouch to the JVM arguments, the JVM will pre-touch the entirety of the heap at startup time to avoid unpredictable page faults through the life of the application. I'd imagine other HFT companies may also pay for the Azul JVM which goes even further and comes with a kernel module that the JVM coordinates with for memory allocation. The kernel module pre-reserves x% of system memory at the tim…

Is the Azul JVM open source? I thought it was just the support which costed money. (I'm just not familiar enough with it)

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

#136

Post by cogman10 »

proverbialbunny wrote: post #126

I'm surprised this article doesn't talk about the common issue with writing a trading bot in Java, which is the floating point types. I worked on a trading bot in Java over a decade ago when it was common in the industry to do so. We wrote a fixed precision decimal library which was about 4x faster than the alternative BigDecimal type. It worked out quite well, but Java doesn't allow operator overloading, so the whol…

Does rust buy much for HFT?

I mean, if you leak memory or have a use after free issue, it's not the end of the world since this isn't exposed to untrusted input.

Though, I'm sure the language features like async/await and safe concurrency are probably appreciated.

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

#137

Post by proverbialbunny »

cogman10 wrote: post #136
proverbialbunny wrote: post #126

I'm surprised this article doesn't talk about the common issue with writing a trading bot in Java, which is the floating point types. I worked on a trading bot in Java over a decade ago when it was common in the industry to do so. We wrote a fixed precision decimal library which was about 4x faster than the alternative BigDecimal type. It worked out quite well, but Java doesn't allow operator overloading, so the whol…

Does rust buy much for HFT? I mean, if you leak memory or have a use after free issue, it's not the end of the world since this isn't exposed to untrusted input. Though, I'm sure the language features like async/await and safe concurrency are probably appreciated.

From Java to C++ it was more about messing up the logic, because it was so difficult to read. This was a while ago, but there was a Perl script where you could write a kind of psuedo code and it would convert it into the Java syntax, so we could look at the math behind it in a clear way.

>Does rust buy much for HFT?

Going from C++ to Rust is low priority. It may not ever be finished. That low of a priority. It's more about refreshing the code base.

One thing that surprised me is Rust can be faster than C++ at certain tasks.

The big benefit is if you have a new dev coming on and they try to modify something that would introduce a bug, the compiler is all over it. Currently acceptance tests are all over it and work fine and C++ can be pretty strict so it works, but Rust is more ideal for this.

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

#138

Post by nv-vn »

eshyong wrote: post #127
mumblemumble wrote: post #35

One bit of useful background knowledge: The technical demands for high frequency trading can vary wildly depending on both what kind of trading strategies you're using, and what market you're in. This translates into real-time needs that vary considerably, depending on context. At one firm I used to work at, the spread was several orders of magnitude. On one end, people were counting nanoseconds, and even C++ wasn't…

What language was the team counting in nanoseconds using?

Probably a hardware team using FPGAs. Software tends to be way less predictable than hardware, so to even get to the point where you can reasonably count nanoseconds it often requires hardware

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

#139

Post by oppositelock »

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?

You generally choose the language which has the libraries and ecosystem which solves your problem. For instance, you'd be silly to use anything but Java to work with Hadoop. This is the pragmatic choice.

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

#140

Post by mathieubordere »

layer8 wrote: post #100
anthonypasq wrote: post #88

Earlier quoted context omitted.

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.

in C++ they could also try using Profile-guided optimization to optimize hot code paths.
Post reply on HN