Live data from Hacker News

We chose Java for our high-frequency trading application

medium.com

171–180 of 287 posts

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

#171
post #154

Earlier quoted context omitted.

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

This was a great read, thanks for that! Never heard of The Daily WTF before.

Congratulations!

https://xkcd.com/1053/

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

#172
post #26

My friend spent two years working for a large bank as a (his words) "trader's bitch". Every day the trader would request a new feature and my friend had at most two hours to implement it. They used a combination of Python and highly GC-tweaked Java. This was six years ago, but I see that similar techniques are still used to this day.

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

When you do HFT, nobody cares about that. The only thing that matters is to make money.

I also worked on HFT software written in Java (not the one in this article), and the mindset was completely different from other industries. F QA, F unit tests, F your F-ing AbstractProxySingletonFactory, just write the code that makes it work, see you after lunch to deploy.

Yes, in a lot of ways it is awful, but OTOH it is really great intense bootcamp to learn how to write very modular, easy to change and to read code. No time to over engineer, no time to build these fancy generic abstractions to support the one use case you have and the dozen hypothetical use cases product never asked for.

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

#173
post #109

Earlier quoted context omitted.

Even if you completely disable GC, Java is still allocating tons of ephemeral objects on the heap. Which in turn is leading to expensive and unpredictable page faults. In contrast, C++'s default is to allocate objects on the heap unless you knowingly call new/malloc. Of course, it's possible to write Java in such a way to minimize this type of heap-thrashing. But by that point, you're already doing the equivalent of…

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

The JVM does scalar replacement, not stack allocation. The former is much more limited in functionality, and much more finicky. You also have about zero control over it, compared to, say, C# structs.

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

#174

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.

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

#176
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…

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.

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

#177
I wish there were some better open source pauseless GCs. To me, the main value proposition of Rust is memory safety without GC pauses[1]. But the complexity tax you pay for the borrow checker is enormous. If pauseless GC is possible (and Azul seems to demonstrate that it is, or close enough) then I would much prefer to just use GC.

[1] I'm aware of many other benefits, but this is the one most unique to Rust and the one I care about most by far.

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

#178
post #150
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…

I can't count how many times I have seen someone effectively say "My thing is better than your/that thing" but they have not actually researched what the other thing is or how it works, they just simply like their own thing so much that they automatically assume it's better or this case different.

Often in corporate environments people are asked to justify a choice of technology, and an approach to a problem. It is quite natural for the people making the decision to choose technology they're most familiar and comfortable with, and positioning it in a favorable light. I imagine this is what happened here.

The actual merit of the competing technology is simply not part of the evaluation. This is at least a step up from government procurement processes where the procurement officer, who has zero technical knowledge, procures based on a checklist he or she is unable to correctly assess bidder responses to, and of course price.

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

#179

Why are we still building high frequency trading apps ? Wasn’t it part of the old world we meant to change ?

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 introduces unnecessary volatility and incentivizes insider trading and other illegal activity[1].

The firm mentioned (Trillium) is not a player in HFT, they are a day trading proprietary trading firm where the firm basically gives individual traders (borrowed) money to use however they want. In this case, some of the traders decided to break the law because there is no real oversight at this kind of firm. When looking at reputable proprietary trading firms (i.e. the kind that don't just hire random people and give them money to play with) this type of behavior simply does not happen. I agree that these types of places are extremely scummy (and are probably responsible for a ton of insider trading crap & the like), but they are not representative of the HFT industry at all.

As for the comment on volatility, the idea behind HFT is actually to help reduce volatility. Outside of a few bugs (such as the Knight Capital debacle you mention) and the Global Financial Crisis, it seems like volatility is trending downwards in part due to HFT. In the same vein, liquidity has exploded thanks to HFT (which is why exchanges pay for HFT). 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.

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

#180
post #106

Earlier quoted context omitted.

What sort of targeting do you use for your campaigns, and how privacy-violating are those targetings?

If you have to ask the question I would encourage you to take $50, open a FB ad account, same for Google, and run some ads to drive some traffic to your blog or whatever. Running an ad campaign, or having to 'get the word out' for something possibly meaningful can be an enlightening and transformative experience for so many people who live adjacent to, but otherwise 'totally outside' the ostensibly opaque world of ma…

>but the nature of the industry is not wrong or evil, it's actually beneifical.

Can you prove how? Thats what the previous poster was asking.

>'Good ads' are a win for everyone.

Again, how? I don't like ads. I think they're annoying. They're not good for me.

I think you're drinking the koolaid.

Post reply on HN