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

211–220 of 287 posts

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

#211

Post by whizzter »

bluestreak wrote: post #186
the_only_law wrote: post #182

Earlier quoted context omitted.

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.

Would you do it again? Coming from C/C++ first, Java then and coming to C# it just feels so much more pragmatic with f.ex. struct(s), slices and stackalloc (and unsafe blocks with pointers in a pinch) allowing for GC less programming w/o resorting to turning pointers to integers and using function calls for memory access all around. (Noticed that you do i guess query compilation via the ASM toolkit?)

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

#212

Post by usefulcat »

slotrans wrote: post #208
usefulcat wrote: post #92

"An improvement can be discussed in the morning, and be implemented, tested and released in production in the afternoon." I feel like they've buried the lead here. If the above statement is really as it sounds, I find that way more impressive than the fact that they were able to make java fast.

This is just normal software development. If you avoid overloading yourself with unnecessary complexity, and you as an engineer spend time understanding the problem/business domain, there's no reason why this speed of turnaround should be unattainable. I have frequently had the experience of sitting in a meeting with (internal) customers and/or a product manager, and shipping discussed changes during that meeting . I…

I have been doing HFT for many years now, so I have an acute appreciation for exactly what is likely to be involved in doing what they claim to be able to do. If you want to put an algorithm in control of large amounts of real money, then some very thorough testing is required to ensure that it's not going to blow up due to some corner case that no one thought of (of which there are typically a surprising number).

I suspect there are some significant caveats to the claim, and even considering that I still think that's a far more impressive accomplishment than just making java fast enough.

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

#213

Post by apalmer »

whizzter wrote: post #203
jacques_chester wrote: post #158

Earlier quoted context omitted.

> 1TB of RAM is cheap though, versus spending engineering hours. It's not about the amount of RAM, it's how fast and predictable the overall system is. Note in particular the remark about cache locality; that can be the difference between nanoseconds and microseconds.

What the GP is referring to (Misc.Unsafe) is basically going back to manual pointer reads/writes (IE writing more or less C code in Java), the benefit is you get C speed/memory layout/cache-locality but with the downside of writing it in a less suited language (Java). HOWEVER If you DO _allocate_ much then 1TB seems like a great choice since GC pauses are killers w.r.t. latency in comparison to cache issues. A cache…

Can you explain why you would code java this way instead of dropping down to C?

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

#214

Post by nv-vn »

jamisteven wrote: post #33

Basically all robust HFT shops are using Java, python is great for prototyping but in the end too slow.

Maybe to some extent? The teams doing proper HFT are all dealing with C++ or hardware. This is true across the industry AFAIK at places like HRT, Citadel Securities, Jump, etc. Some of these might use some Java for things that don't require low latency but those aren't really considered HFT.

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

#215

Post by kanox »

mschuster91 wrote: post #201
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…

The key difference between Java and PHP is the lack of a compilation step. I can change a line of code, press cmd+r and I see the change - whereas in Java more often than not I have to wholly restart the application container as hot-reloading is a complicated mess and tough to set up. Also, in Java it is easy to end up with resource leaks whereas PHP always starts from a clean slate for each request. Way less headach…

> Also, in Java it is easy to end up with resource leaks whereas PHP always starts from a clean slate for each request. Way less headache for operations.

That assumes you're running a new separate PHP processes for each request and an application built this way is unlikely to scale terribly well.

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

#216

Post by [deleted] »

Spinnaker_ wrote: post #81
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…

Nice overview. The fast vs smart comparison is apt. But something that gets missed in these conversations is what trading system architectures actually look like. The part where latency is measured in nanoseconds is just the tip of the iceberg. Java and 2007 tech is absolutely acceptable for most of the architecture. Another thing is the structure of Equity and Derivative markets vs FX. The former is fairly standardi…

[deleted]

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

#217

Post by gpsx »

nv-vn wrote: post #157
gpsx wrote: post #129

Earlier quoted context omitted.

I'm not an economics or finance expert, so I may not have a very extensive view of this, but I think there is a meaning to the expression of providing value. If a product has more value to a person than the price of the product, assuming they have correct knowledge, that is the creation of value. In high frequency trading, or stock trading in general, people may be willing to pay more than the listed price, but I don…

I disagree. Trading may seem zero sum on a short timescale, but over the long term markets (empirically) trend upwards. Thus, simply being invested in diverse indices should yield some positive return in the long run. This makes sense as long as we assume GDP growth over time, which is an assumption that has kinda been baked into government/economics to my understanding. At a short time scale, yes there tends to be a…

Regarding the short term versus long term, I agree with you here. I meant to differentiate between getting profit by investing, which certainly has a lot of value and is the whole point of capital markets, and from getting profit from fluctuations in the current price not tied to an inherent value of the company, which is where I think you have the winner and loser, even if the trades involve multiple parties. Clearly this is what is being done in high frequency trading.

I can buy the idea of high frequnecy trading serving as market making even if it is not something I can fully appreciate. But it still seems like these high frequency traders (and others invovled in investing based on fluctations) are mainly skimming money from the market without providing value.

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

#218

Post by whizzter »

nobleach wrote: post #135
paulfurtado wrote: post #117

Earlier quoted context omitted.

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)

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

What Azul does is to make the pages in question invalid for reading/writing so any access to them would page-fault and then proceeds to move the objects without worrying about other threads. Since the hardware provides the page-fault "for-free" this protection doesn't cost anything in terms of runtime performance in the common case (compared to the new ZGC made by Oracle that has read-write barriers that steals some mutator performance), worst case if another thread tries to read/write memory that is being moved a specialized page-fault handler detects if this was an page that was in motion and can then do a slower read-write but ONLY in the seldom cases where this occurs (compared to all the time of f.ex. ZGC)

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

#219

Post by whizzter »

pdpi wrote: post #176
bluestreak wrote: post #167

Earlier quoted context omitted.

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…

Scalar replacement has several requirements, and escape analysis is only part of the story. One of the restrictions with scalar replacement for arrays is that indexing has to be constant at JIT time, which your example clearly isn't.

The point would be that escape analysis could have proven that the array was not used outside of the function and allocated it fully on the stack, thus not providing any GC pressure. Scalar replacement isn't the point of interest really.

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

#220

Post by [deleted] »

pdpi wrote: post #176
bluestreak wrote: post #167

Earlier quoted context omitted.

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…

Scalar replacement has several requirements, and escape analysis is only part of the story. One of the restrictions with scalar replacement for arrays is that indexing has to be constant at JIT time, which your example clearly isn't.

[deleted]
Post reply on HN