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

241–250 of 287 posts

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

#241

Post by smabie »

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 don't think you have to know someone. Moreover, if all you're looking for is a straight up dev role (vs quant research or trading), I don't think it'll be that hard. Not sure if you'll pull in 400 or 500k, but if you're good, you should do pretty well for yourself.

Just apply for roles, if you're a good dev, I don't think you should have trouble landing interviews.

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

#242

Post by smabie »

tijsvd wrote: post #227
smabie wrote: post #190

Earlier quoted context omitted.

I'm a HFT quant trader and HFT is not purely latency driven. You don't want to be slow, but most firms are increasingly perusing longer and longer term strategies that aren't as latency sensitive. Pure risk free latency arb isn't really a profit center anymore. The speed wars are pretty much over. The industry has consolidated and any player that didn't adapt to the new, more cerebral game is dead.

> The speed wars are pretty much over. The industry has consolidated and any player that didn't adapt to the new, more cerebral game is dead. Except for the one that won the speed war, and keeps investing massively to remain 10ns ahead.

No one "won" the speed wars: the top firms are all competitive with each other and have a gentleman's agreement against spending billions more for nanosecond gains.

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

#243

Post by touisteur »

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…

I had a side project of 'flattening' classes at classloading time into large mappedbytebuffers, removing all allocations needed for ser-des and recursing on belongs-to references, copying buffer slices from sockets to the buffers (and reusing the socket buffers), and using netty for sockets (selector allocates crazy). Very fun project with javassist...

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

#244

Post by stingraycharles »

ValleZ wrote: post #238
stingraycharles wrote: post #236

Earlier quoted context omitted.

To add to this, I know for a fact some people who are really serious about Java + HFT, and they would never ever use a GC. I can’t believe how much this article talks about Zing and other GCs, while the de-facto standard way of doing this is to just always reuse all objects and never deallocate them. I get a very real feeling that the people writing this article have no idea what they’re talking about.

How do you do that? Even when your code has no memory allocations sockets still leak memory.

You use special libraries designed for this purpose, that use a static buffer under the hood themselves. Or you just make sure that memory usage increase is low enough that it isn’t a problem. You sometimes have places where they do for example one GC call a day.

Take a look at https://github.com/OpenHFT to get a taste of what Java + HFT looks like.

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

#245

Post by bywaterstreet »

lkbm wrote: post #85
RankingMember wrote: post #72

Earlier quoted context omitted.

Damn, seems like a good way to have a ton of buggy code in production.

I'm guessing most people are familiar, but if you're interested in this, look up "Knight Capital flash crash". They lost $440MM in about 45 minutes. As I recall, they reused an old feature flag accidentally reviving some old code.

Thanks for the ref. I'll bring this up the next time somebody questions my "let's clean up these flags in prod".

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

#247

Post by merb »

amelius wrote: post #104
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.

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.

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

#248

Post by jstrong »

immmmmm wrote: post #228
erik_seaberg wrote: post #184

Earlier quoted context omitted.

The market is a machine that routes society’s resources into making nearly everything. Making better routing decisions has immense value. When someone can profit from the same decision everyone else would make by doing it 0.000000012 days more quickly, IMHO he’s exploiting a design flaw in the way the market clears. That’s amplifying noise rather than signal.

ok, that was a bit of my original question (not well asked). i understand any civilisation needs funding to grow (do we need growth is another core question), and possibly market to do so. yet any meaningful decision won't be made at the millisecond scale, sure you can train a model to learn short term rules and generate long term profit. but does that profit society as a whole, i doubt it.

a millisecond is a long time in computer terms. many meaningful decisions can be made in a millisecond.

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

#249

Post by Bootvis »

smabie wrote: post #194
krisgenre wrote: post #20

A sting of nostalgia and coincidence perhaps, was thinking about Java and HFT only a few days ago. I worked as an offshore employee for E*Trade back in 2010 - 2012. Their desktop app for HFT was written in Java Swing and their web client too was running on the JVM but the 'services' layer the one that interacted with the database was written in C++. Four years ago heard that they were re-writing the desktop app in Ja…

What do you mean their desktop app for HFT? no one has HFT desktop apps

The GUI that the traders use?

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

#250

Post by ncmncm »

This amounts to explaining that a $20 hammer is better than a $10 hammer when you frame your own deck. It really is, but that tells you nothing about the equipment a contractor needs to operate a construction business.

The majority of programming tasks don't need anything better than Java, and don't need anyone more expensive than the typical Java coder.

Low-latency trading is not one of those tasks. In low-latency trading, as in poker or any other zero-sum game, you either rip the other guy's heart out and stamp on it, or get your own heart ripped out and stamped on. Using any but the best tooling and programmers means you will be that second guy.

So, anybody serious is using C++17, coded by people who understand cache interactions, branch prediction, TLB shootdowns, and core isolation, and who avoid lockless queues because of the cache-line pingponging. If you don't know what all that means, you are not the right person to code low latency trading.

They are not the hardest core: the sharpest players farm the simplest, most time-sensitive operations to FPGAs. But FPGAs take tradeoffs that make them not right for everything, and FPGA coders are not just programmers.

Post reply on HN