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

181–190 of 287 posts

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

#181

Post by vmception »

dcolkitt wrote: post #75
cashewchoo wrote: post #5

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…

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…

correct, there is a peculiar nuance on financial trading topics where people conflate "computer executed trade" with "high frequency trading"

you may need to rapidly adjust the expected fill price at a high frequency on a multi leg strategy being run in 100 positions, but the actual sending orders to the exchange doesn't need to be high frequency, and it is an important distinction that you wouldn't be competing with others on the frequency at this stage, it doesn't matter if this occurs in 1 millisecond of 500 milliseconds, even a couple of seconds. Very different ballgame than the wishful femtosecond game.

its probably better that people don't understand that, but it is annoying that there are this many roadblocks to a nuanced conversation

either way your servers still have to have all the authentication code, and various algorithms running to monitor the tape.

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

#182

Post by the_only_law »

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…

Do you know of any public examples of how this sort of Java looks? I imagine you lose out on being able to take advantage of much of the JVM ecosystem and I struggle to see what using Java even adds anymore.

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

#183

Post by hawk_ »

bluestreak wrote: post #167
fh973 wrote: post #109

Earlier quoted context omitted.

That's covered in Java by escape analysis and allocation on the stack.

We have written a database in zero GC java and one thing I have not seen any evidence of "escape analysis". @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class EscBenchmark { Rnd rnd = new Rnd(); public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(EscBenchmark.class.getSimpleName()) .warmupIterations(5) .measu…

Which version of Java are you using? And what is Rnd? The class included with JDK is Random. We rely on escape analysis to elide such object creation for us and it works reasonably well. If something this trivial doesn't work for you, file bug with them. We have had success with that as well.

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

#184

Post by erik_seaberg »

immmmmm wrote: post #63

I have a question: When i finished my theoretical Physics PhD, HFT was THE way out of academia for making money in my field. I didn't follow this path as it felt at the time a pretty evil thing to do. Does HFT provide any benefits for our society?

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.

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

#185

Post by accountLost »

cwt137 wrote: post #141

I don't like how the author of the article said that PHP is an interpreted language and thus does not execute anything like Java is executed. I'm not saying PHP executes just like Java, but PHP is more like Java than he realizes. PHP does not execute line by line like an interpreted language. But takes the source and compiles it down to an intermediate representation (IR), just like Java. Java calls it bytecode, PHP…

Maybe the article means that PHP interprets the OPCodes as opposed to java that uses a JIT compiler that produces machine code for part of the bytecodes. Anyway JIT is coming with PHP8 :

https://stitcher.io/blog/new-in-php-8

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

#186

Post by bluestreak »

the_only_law wrote: post #182
benjaminjackman wrote: post #121

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…

Do you know of any public examples of how this sort of Java looks? I imagine you lose out on being able to take advantage of much of the JVM ecosystem and I struggle to see what using Java even adds anymore.

here is one: https://github.com/questdb/questdb. Disclaimer, I work on this project. Main reason we use Java is speed of development (which increased with amount of base libraries written) and ease of testing.

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

#187

Post by [deleted] »

the_only_law wrote: post #182
benjaminjackman wrote: post #121

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…

Do you know of any public examples of how this sort of Java looks? I imagine you lose out on being able to take advantage of much of the JVM ecosystem and I struggle to see what using Java even adds anymore.

[deleted]

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

#188

Post by vips7L »

pron wrote: post #44
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.

I'd like to see C4 be put up against ZGC.

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

#189

Post by dcolkitt »

vaccinator wrote: post #174
dcolkitt wrote: post #61

One thing to keep in mind, is that HFT is not just "one thing". It's a collection of many different strategies that are generally characterized by short holding periods, high portfolio turnover, and latency sensitivity. But depending on the specific strategy, the degree of latency sensitivity could vary by orders of magnitude. A desk trying to gain first queue position at the opening auction is probably running in FP…

isn't true HFT purely latency driven? ie: if you see a sell order for $0.10 and a buy order for $0.11 before anyone else, it is like free money.

A (relatively small) subset of HFT is purely latency driven. But the largest sub-category is probably market making. I.e. leaving open a buy order for $0.10 and a sell order for $0.11, and hoping that both get filled and you net the difference.

You're taking real risk, in the sense that your buy order could get filled, your sell order doesn't, and the market moves down, so now you lose money. Latency is pretty important to market making for two reasons. One is because you want to quickly adjust your quotes before the market moves through you. If you're too slow, opportunists will pick you off in the wrong direction. Two is because exchanges mostly follow price-time priority. E.g. if me and you both enter buy orders for $0.10, the front of the "queue" to get matched, will be whoever's order arrives first at the gateway. Not only is that important for getting more opportunities, but generally orders in the front of the queue are less likely to be trade against "toxic flow", where the market moves through you.

There's definitely a baseline minimum of latency that you need to play the game at all. But there's tons of ways to compete besides just being the fastest. You can build your own signals to internally predict which way the market moves before it does. You can have superior models to tell you when the risk of "toxic flow" is lower. You can use clever tricks to get to the front of the queue when others aren't paying attention.

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

#190

Post by smabie »

vaccinator wrote: post #174
dcolkitt wrote: post #61

One thing to keep in mind, is that HFT is not just "one thing". It's a collection of many different strategies that are generally characterized by short holding periods, high portfolio turnover, and latency sensitivity. But depending on the specific strategy, the degree of latency sensitivity could vary by orders of magnitude. A desk trying to gain first queue position at the opening auction is probably running in FP…

isn't true HFT purely latency driven? ie: if you see a sell order for $0.10 and a buy order for $0.11 before anyone else, it is like free money.

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.

Post reply on HN