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.
We chose Java for our high-frequency trading application
171–180 of 287 posts
Re: We chose Java for our high-frequency trading application
#172My 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.
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
#173Earlier 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.
Re: We chose Java for our high-frequency trading application
#174One 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…
Re: We chose Java for our high-frequency trading application
#175Does anyone which currently available CPUs are able to run at stably at 5.6GHz? (Presumably with 14 cores each)
Re: We chose Java for our high-frequency trading application
#176Earlier 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…
Re: We chose Java for our high-frequency trading application
#177[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
#178I 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.
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
#179Why 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…
>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
#180Earlier 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…
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.