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

251–260 of 287 posts

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

#251

Post by rokobobo »

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…

I come from a place that used Java as the main language for its strategies, and the developers' overall sentiment was very close to yours.

I saw people comment on the "fastsmart" continuum, and in this context, I believe they mean smart=computationally intensive. (An extreme example is a stat arb shop running its portfolio optimizer.) But there's another way to gain an edge, which is to iterate quickly on your "fast" algorithms and develop them so they take advantage of opportunities that are only partially exploited by competitors. Java seemed pretty good for that purpose for about a decade. Things like JVM warmup, GC, individual ultra-low-latency responses whenever necessary, were all dealt with after the fact.

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

#252

Post by exhftdev »

dangerbird2 wrote: post #8

Does anyone know if C#/dotnet is used in HFT to any extent? I'd imagine proper support for user-defined unboxed types (structs) and non-hacky methods for manual memory management (unsafe) could give it major advantage over Java with much of the QoL improvements java has over C++.

I've worked for one of the big trading firms and they used C# including for their ultra-low-latency trading strategies.

I'm a bit surprised by all the chatter about garbage collection because it's not as much an issue as it sounds.

The thing is not to do allocations (i.e. GC) on the _critical path_.

In a trading strategy you react to a stream of market data. It appears constant to the human eye, but in fact it's a series of "blips", sporadic events.

When you get a new message you need to react as fast as possible. The fastest code is, of course, no code, so it doesn't really matter if it's not written in C++, C# or PHP. Here you're just going to do the very minimum required. You will find that generally there is no difference in the code compiled whether it' done by the C# JIT, the Java JIT or a C++ AOT compiler, because the code is simple: you read a few fields from the message and select a pre-computed outcome to decide whether or not to send a (buy|sell) order.

Now, after that event has been handled (and perhaps you sent an order), you need to recompute stuff. You generally have plenty of time (a few milliseconds) before the next event arrives, and that's where you want to do all your fancy calculations, and here a high-productivity language like Java or C# helps, just because it's quicker to iterate and deploy modified trading strategies (typically deployed daily, or at least weekly).

Many people assume that you need to do all your fancy calculations very rapidly right after a message arrives. But you don't have to because the message is not completely random. The order book is not going to change completely after one message. You can pre-compute a few likely scenarios, and when a message arrives and confirms one of those scenarios, you just mechanically go with the precomputed result.

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

#253

Post by hchz »

offtop5 wrote: post #209
smabie wrote: post #206

Earlier quoted context omitted.

It's stressful in the sense that the amount you earn is a linear function on the performance of the strategy. Unlike at other firms, bonus isn't discretionary: its a pure function of strategy performance. When the company loses money, you lose money. This incentivizes everyone to work together and solve problems. Also working with some of the smartest people in the industry can be intimidating: if you're used to bein…

So for my last question, did you have to know someone to get into this field. I'm in fintech right now, and I'm well compensated, I love my job but if I can reach the Pinnacle programming, IE pulling 400 or 500k a year. That would be simply awesome. Would it be easier to target bigger firms and then get into or start my own firm ?

I think it’s easier to hit that level in FAANG due to the number of opportunities and less elitist hiring practices.

I do a lot of intern interviews and I haven’t seen a single non-target resume, or someone without FAANG internships, high placement in global hackathons, math olympiads, etc.

Experience is a way in but it depends what “fintech”.

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

#254

Post by girvo »

merb wrote: post #247
amelius wrote: post #104

Earlier quoted context omitted.

This is similar to how missiles don't need GC. https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

it has, it explodes and the memory is free again. just not for further usage.

The memory is freed all over the target, I suppose

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

#255

Post by girvo »

jayd16 wrote: post #169
btilly wrote: post #133

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 run…

The PHP Wikipedia page seems to argue that the most popular implementation, Zend, is an interpreter. https://en.wikipedia.org/wiki/PHP#Implementations

You can examine and dump the byte code from the runtime with phpdbg — it basically acts as a compiler to byte code on startup.

Of course because it’s also very dynamic, the lines are blurred, imo

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

#256

Post by tormeh »

WJW wrote: post #222
tormeh wrote: post #163

Earlier quoted context omitted.

It has immutability, no null pointers, and error types. It has escape hatches available for everything, but unnecessary use of these should be caught in code review, so I don't think it's a big deal. Not sure what correctness features OCaml could add beyond those, but then again I've never programmed in OCaml, only Scala, so I might be wrong.

This is perhaps the most "blub" comment ever written. There are whole classes of bugs that can be caught with more advanced type systems that the Rust type system + borrow checker will never catch. No null pointers and immutability is the bare minimum. If you're interested, check out https://www.youtube.com/watch?v=10gSoVZ5yXY for an example of the types of compile time guarantees can be had.

Does OCaml have dependent types? I thought that was a Coq and Idris (and Haskell, to a lesser extent) thing.

I am aware that dependent types exist, but quite frankly I've yet to see a popular/ergonomic language implement them. As much as we'd like absence of null pointers, error types, and immutability to be the norm it is not and it will take decades until it is.

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

#257

Post by nicoffeine »

nv-vn wrote: post #179
nicoffeine wrote: post #152

Earlier quoted context omitted.

Money corrupts. Wall Street money corrupts absolutely. In a sane market, there would be no advantage to making an investment and then selling it a few milliseconds later. It introduces unnecessary volatility and incentivizes insider trading and other illegal activity[1]. It defeats the original purpose of the market: to make long term investments. It also leads to some unbelievable waste: Traders’ need for speed has…

This is a really frustrating comment because it has so little to do with the real world of HFT. >In a sane market, there would be no advantage to making an investment and then selling it a few milliseconds later. And yet exchanges (NASDAQ, NYSE, CBOE, LSE, CME, Euronext, etc.) actually _PAY_ HFT firms to do this exact behavior since it provides actual, quantifiable benefit to the exchange and its customers. >It intro…

> Outside of a few bugs (such as the Knight Capital debacle you mention) and the Global Financial Crisis

I don't know anyone who thought the Global Financial Crisis was a "bug." People went bankrupt, lost their retirement, lost their homes, lost their jobs. These are not small stakes.

> It means that you no longer have to wait minutes or hours for your trades to execute and you can usually get the most up to date price very easily.

Warren Buffet was able to build his empire before HFT, because he was investing, not trying to skim market moves. If the point is to have a stock market where people make investments, HFT literally serves no purpose. It's like getting a weather update every second. If you're investing in a company for its merits, those don't change by the second or even by the day.

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

#258

Post by pkulak »

mfontani wrote: post #142
btilly wrote: post #133

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 run…

A tangible example: if you've got a script the likes of: #!/bin/bash echo 'Hi!' sleep 20 echo 'Hello!' ... and runt it ... and while the script is executing the sleep line, modify it so that instead of 'echo "Hello!"' it does something else, like 'echo "Oops!"'... ... once it resumes from the sleep, it'll execute the updated code. Don't ask me how I know... I just wish it were more well-known. Don't modify shell scri…

That is amazing. Bash doesn't even load the script into memory? It just keeps a line pointer and chunks through the open file? There's something comforting about that. :D

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

#259

Post by qeternity »

unwoundmouse wrote: post #99
dcolkitt wrote: post #75

Earlier quoted context omitted.

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?

It’s difficult to compete on latency and remain anonymous.
Post reply on HN