Live data from Hacker News

We chose Java for our high-frequency trading application

medium.com

281–287 of 287 posts

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

#281
post #179

Earlier quoted context omitted.

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

I didn't mean to call the GFC a bug, I'm saying that the instances where volatility has significantly and immediately spiked have been:

1. The GFC which wasn't caused by HFT

2. Certain instances where HFT bugs led to "flash crashes"

>If the point is to have a stock market where people make investments, HFT literally serves no purpose

This is patently false. Imagine a situation where the price of AAPL suddenly plummets because of an influx of sellers. If you want to close a long position with AAPL to lock in your gains, there will simply not be enough buyers for your shares to sell most of the time. The purpose of market makers is to make this sale possible because they are still able to profit or nearly break even from buying your shares (and are often contractually obligated to do so). Without someone taking the risk that market makers take, the stock would just free fall indefinitely and nobody would be able to take a profit off their investment.

A similar situation is options market making. People/institutional investors like Warren Buffet hedge their bets by purchasing options to protect them when their expectations fail to pan out. In such a situation, it is imperative that options are able to be purchased for a fair price and due to volatility the price from 10 minutes ago is almost certainly wrong. Likewise, it's important that a contract even exists for your desired purposes.

The purpose of HFT isn't just to give the most recent update, but rather to provide the essential pricing of various derivative instruments which depend on immediate values like the price, volatility, etc. of the underlyings. The immediate ability for your order to execute also protects you from the market's volatility, since you can essentially lock in your price as soon as you see the market moving. The blatant truth is that many modern portfolios consist of more than just unhedged long positions in a variety of stocks and as such a lot more complexity is required than "investing by a company's merits," even in the world of "value investing."

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

#282

Earlier quoted context omitted.

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

It is commercial, and sadly their GC algorithms are patented. I'm really anxious for those patents to start running out because the functionality is quite clever. Basically one main reason you need to stop the world in common GC's right now (and thus cause pauses) is because if you want to compact memory a GC thread has no idea if other threads reads/writes to an object while moving leading to worst case corrupt/lost…

Hey thanks. That was a fantastic explanation.

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

#283

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…

Flexibility in code is important. When markets change it is good to be able to quickly rework your code. Sometimes depending on the market this is more important than pure speed.

Market data is the slow monster - especially in the options market - not order entry. This is where the fpgas come in to help.

Often I have seen trading groups throw money at infrastructure when it was really just that a competitor (a virtu or citadel) has a better way of internalizing order flow or managing risk so they can pay more for the same trade.

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

#284

Earlier quoted context omitted.

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

> ...a new intern named Bob. Bob raised a finger and said "Yes, I have a question...

Damn those smart-ass interns!

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

#285
post #13
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 should not be named.

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

#286

Earlier quoted context omitted.

It is commercial, and sadly their GC algorithms are patented. I'm really anxious for those patents to start running out because the functionality is quite clever. Basically one main reason you need to stop the world in common GC's right now (and thus cause pauses) is because if you want to compact memory a GC thread has no idea if other threads reads/writes to an object while moving leading to worst case corrupt/lost…

why does the hardware provide page-fault for free again?

Page-faults aren't for free (actually kinda expensive) but rather the paging functionality is giving "free" read/write-barriers instead of those being instruction sequences being inside the main program (ie read/write barriers are handled as page-faults by the paging system that the OS already provides to avoid requiring every read/write of the user-code to be aware of moving pointers).

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

#287
post #267

Earlier quoted context omitted.

Probably because they started out in Java and don't want a full rewrite once they've gotten this far (might be that they don't have many C++ devs anyhow). I remember working on similar codebases 10 years back when J2ME games were still a thing (J2ME runtimes usually had horrible GC's and some people really went overboard in trying to avoid them) and it wasn't that fun at all (Even if the questDB codebase that is link…

JNI replacement is called Panama it doesn't have anything to do with GraalVM. GraalVM is the new name of MaximeVM one of the JVM meta-circular JVMs. Other well known ones being JikesRVM and SquawkVM. What Oracle and others in the Java community are doing is reducing the need to drop down to C with support for value types and more fine grained control over native memory. Java 16 will have the first preview release of…

The meta-circularity is part of the impl details, cross-language calling (Java/JS/LLVM) seems to be the main selling point of it, so if you want GC-less logic then Clang->LLVM then running on the JVM is an option, no idea if it also simplifies native bindings though (that is more of a Panama issue and improving that is a good idea aswell).
Post reply on HN