Speaking about JVM garbage collection, why isn't automatic reference counting being used instead of traditional garbage collection? It seems kind of like the best of both words in a automatic memory-managed environment of providing safety as well as performance. Languages like Objective-C and Swift have proven that this is very viable. I wonder what's keeping the JVM from adopting it?
We chose Java for our high-frequency trading application
51–60 of 287 posts
Re: We chose Java for our high-frequency trading application
#52I'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…
LMAX Disruptor is a really powerful abstraction if you are trying to build something with consistently-low latency. I've been using a variant in .NET Core for purposes of processing UI events.
It was very interesting, I ported it to C++. However, I lost interest when the whole thing could lock up if the RingBuffer size was very small yet still a power of two.
It also uses sun.misc.Unsafe to do the latency critical aspects, so yes it's Java, but most certainly not vanilla Java.
Re: We chose Java for our high-frequency trading application
#53Shameless plug about a latency experiment I recently did using a C++ trading toolkit I have been working on for cryptocurrency exchanges: https://roq-trading.com/posts/latency_experiment/
Re: We chose Java for our high-frequency trading application
#54Earlier quoted context omitted.
It's an entire industry devoted to wasting enormous energy, resources and intellectual capacity. There are simply no material external gains from HFT etc, it's completely zero-sum other than maybe a 'job creation program'. The site ridiculously talks about 'levelling the playing field' by extending HFT opportunities to other players, which is rich, considering the playing field could be 'levelled immediately' by some…
I don't think that's quite right. It's the same way Formula 1 racing contributes to regular automotive industry. Technological innovations could be adopted by more mainstream industries in a few years. For instance SolarFlare NICs used to be almost exclusively used by HFT players and can now be found in most CDNs or latency sensitive cloud providers.
The F1 comparison is not bad, but its not great either. F1's tech innovations are much more publicly visible (HFT shops are extremely secretive) and F1 has the added benefit of providing entertainment value to millions.
Re: We chose Java for our high-frequency trading application
#55I 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…
> 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 trades and vice-versa there's barely any point in being ultra-fast in the "non-speed-critical" bucket because your alphas last for minutes to hours.
Depending on the overall strategy, you can be smart and fast at once. If you have occasional alpha harvesting opportunities that must be acted on quickly (very low latency but also low-ish frequency), then it is possible to spend the time in between trades modeling market context and developing optimal short-term plans for how to react in case of various market triggers.
Re: We chose Java for our high-frequency trading application
#56Earlier quoted context omitted.
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 brings the Gentoo installation experience to external libraries and requires special purpose data structures to compile properly?
Do you prefer the Linux from Scratch installation experience which C and C++ provide?
Re: We chose Java for our high-frequency trading application
#57You'd think that the practice would have changed its name to low-latency trading. Anyone can trade frequently.
Re: We chose Java for our high-frequency trading application
#58Earlier quoted context omitted.
Better or worse than Ad tech based companies? Most traders I've met have been fairly honest about contributing nothing to society, or that the world would probably be a better place is large segments of the finance industry disappeared tomorrow. I can't say the same for the majority of developers from Facebook or Google I've met.
??? I run ads and campaigns for my company and they are an absolutely essential form of communication. ... as almost everyone running and actual business knows. Yes - it can be very inefficient - but it's not inherently wasteful. You're making the wrong comparison - the 'Digital Ad Industry' could be compared to 'Digital Banking Industry' perhaps - i.e. useful overall but deficiencies exist. HFT is one of the ares in…
What sort of targeting do you use for your campaigns, and how privacy-violating are those targetings?
Re: We chose Java for our high-frequency trading application
#59What's the upper salary cap for HFT engineers. I'm talking cash , not stock. From what I've seen above 200k is exceptionally rare.
If you're at a top firm like citadel you'll start at around 250.
Re: We chose Java for our high-frequency trading application
#60Basically all robust HFT shops are using Java, python is great for prototyping but in the end too slow.
All robust HFT shops? What do you mean by robust and how did you come to that (to me) surprising conclusion?