Earlier quoted context omitted.
Yep and what's worse is many hft firms aren't in the market-making business at all but actually REMOVE liquidity.
What's the mechanism for removing liquidity?
[deleted]
C++ patterns for low-latency applications including high-frequency trading
51–60 of 240 posts
Re: C++ patterns for low-latency applications including high-frequency trading
#52My emphasis:
> The output of this test is a test statistic (t-statistic) and an associated p-value. The t-statistic, also known as the score, is the result of the unit-root test on the residuals. A more negative t-statistic suggests that the residuals are more likely to be stationary. The p-value provides a measure of the probability that the null hypothesis of the test (no cointegration) is true. The results of your test yielded a p-value of approximately 0.0149 and a t-statistic of -3.7684.
I think they used an LLM to write this bit.
It's also a really weird example. They look at correlation of once-a-day close prices over five years, and then write code to calculate the spread with 65 microsecond latency. That doesn't actually make any sense as something to do. And you wouldn't be calculating statistics on the spread in your inner loop. And 65 microseconds is far too slow for an inner loop. I suppose the point is just to exercise some optimisation techniques - but this is a rather unrepresentative thing to optimise!
Re: C++ patterns for low-latency applications including high-frequency trading
#53Earlier quoted context omitted.
This is an excellent slideshow. The slide on measuring by having a fake server replaying order data, a second server calculating runtimes, the server under test, and a hardware switch to let you measure packet times is so delightfully hardcore. I don't have any interest in working in finance, but it must be fun working on something so performance critical that buying a rack of hardware just for benchmarking is econom…
Delightfully hardcore indeed! But of course you don't have to buy a rack of servers for testing, you can rent it. Servers are a quickly depreciating asset, why invest in them?
Why would replaying data for testing be "Delightfully hardcore indeed!". That's how people program in general, they run the same data through their program.
Servers are a quickly depreciating asset, why invest in them?
I don't think they are a quickly depreciating asset compared to the price of renting, but you would want total control over them in this scenario anyway.
Re: C++ patterns for low-latency applications including high-frequency trading
#54Is there any good reason for high-frequency trading to exist? People often complain about bitcoin wasting energy, but oddly this gets a free pass despite this being a definite net negative to society as far as I can tell.
A net negative to society, but a positive for the wealthiest.
Re: C++ patterns for low-latency applications including high-frequency trading
#55Earlier quoted context omitted.
> Warren Buffett proposed that the stock market should be open less frequently This will result in another market where deals will be made and then finalized on that 'official' when it opens. It's like with employee stock. You can sell it before you can...
Not if we disallow it. We have laws in place to try and prevent a lot of natural actions of markets.
Instant biggest black market of all time, corruption skyrockets, only the richest people get fair deals on investments.
Re: C++ patterns for low-latency applications including high-frequency trading
#56Earlier quoted context omitted.
Delightfully hardcore indeed! But of course you don't have to buy a rack of servers for testing, you can rent it. Servers are a quickly depreciating asset, why invest in them?
Why would replaying data for testing be "Delightfully hardcore indeed!". That's how people program in general, they run the same data through their program. Servers are a quickly depreciating asset, why invest in them? I don't think they are a quickly depreciating asset compared to the price of renting, but you would want total control over them in this scenario anyway.
I thought that the hardcore part is taking the data from the switch to account for the network latency.
Re: C++ patterns for low-latency applications including high-frequency trading
#57Is there any good reason for high-frequency trading to exist? People often complain about bitcoin wasting energy, but oddly this gets a free pass despite this being a definite net negative to society as far as I can tell.
It would be trivial (and vastly more equitable) to quantize trade times.
You mean like settling trades every 0.25 seconds or something like that? Wouldn't there be a queue of trades piling up every 0.25 seconds, incentivizing maximum speed anyway?
Re: C++ patterns for low-latency applications including high-frequency trading
#58Earlier quoted context omitted.
Yep and what's worse is many hft firms aren't in the market-making business at all but actually REMOVE liquidity.
What's the mechanism for removing liquidity?
Adding liquidity means to place an order that sits on the book while removing liquidity means to execute against an order that's already resting on the book.
Re: C++ patterns for low-latency applications including high-frequency trading
#59I've got an implementation of a stock exchange that uses the LMAX disruptor pattern in C++ https://github.com/sneilan/stock-exchange And a basic implementation of the LMAX disruptor as a couple C++ files https://github.com/sneilan/lmax-disruptor-tutorial I've been looking to rebuild this in rust however. I reached the point where I implemented my own websocket protocol, authentication system, SSL etc. Then I realized…
I briefly looked over your stock exchange code: - For memory management, consider switching to std::shared_ptr. It won't slow anything down and will put that concern to rest entirely. - For sockets, there are FOSS libraries that will outperform your code and save you a ton of headaches dealing with caveats and annoyances. For example, your looping through FD_ISSET is slower than e.g. epoll or kqueue. - For dependenci…
I did not know std::shared_ptr would not slow things down. I've learned something new today! :)
Yes, I agree, epoll is a lot better than FD_ISSET.
Maybe I can keep moving with my C++ code but do people still trust C++ projects anymore? My ideal use case is a hobbyist who wants a toy stock exchange to run directly in AWS. I felt that C++ has a lot of bad publicity and if I want anyone to trust/try my code I would have to rebuild it in rust.
Re: C++ patterns for low-latency applications including high-frequency trading
#60Earlier quoted context omitted.
It took me about a year to build all of this stuff in C++. So I imagine since I've had to learn rust, it will probably take me the same amount of time if I can save time with dependencies.
In my experience, once you know the problem really well, yes you're right. If you are building a complex prototype from scratch, you'll usually spend more time fighting the Rust compiler than trying out alternate design decisions.
I do know the problem domain well. My second iteration in rust already almost has an order book implemented.
Writing code in rust however is very fun! (At least so far lol)