This is basics for those who start creating anything HFT.
Your project is a nice start. It has a lot of things waiting to be added and improved. I’d also add it looks like a 1-2 week project (excluding benchmarks) in my company for people who just started doing trading systems, and it reminds me of the project that is given to people that have finished C++ training and need something to exercise on.
While it is a good start, I’d add you may find a lot of interesting ideas in QuantLib (https://www.quantlib.org/).
Please also be careful with double for price and quantity especially in HFT and especially with asset types like BTC. The precision issues may lead to some confusion and eventual losses here and there. I noticed that you use fuzzy floating point comparisons, even in tests. That may not be suitable for important use cases.
Please also add some examples for specific trading strategies. Let’s say if you have back testing and some simple historic data in JSON a good example could be a comparison of two trading strategies and the difference compared to most optimal trading strategy possible.
Yea, there is lot to be added, that's by design. I'm not aiming for one-pass toy, this is foundational infra, not a weekend simulator.
FP numbers wrapper are planned. Sharing strategies is not a priority, maybe I will add some just for demo. And for sure I'm not sharing backtesting engine.
Combined with HFT CppCon talk that emphasizes the impact of node-based STL containers you may benefit from using some optimized hash maps on top of vectors, if you aim at top-performance in runtime. Also, abseil has some flat sets/maps implementation. All of this could be a nice addition if you experiment with performance (I figured that from std::pmr use in your project).
100% agreed, stl containers should be replaced. The problem here is that I'd like to keep the core dependency-free... However, functionality first, squeeze maximum later. I'll definitely give a try for non-stl containers and if measurements beat - make the usage of container implementation controllable by compilation options, keeping things configurable as much as possible.
Thank you for your ideas and advice! Great and valuable feedback
Related video for those who are interested: “When Nanoseconds Matter: Ultrafast Trading Systems in C++ - David Gross - CppCon 2024” https://youtu.be/sX2nF1fW7kI?si=komqKuZ0-eOH2v4V
This is basics for those who start creating anything HFT.
Your project is a nice start. It has a lot of things waiting to be added and improved. I’d also add it looks like a 1-2 week project (excluding benchmarks) in my company for people who just started doing trading systems, and it reminds me of the project that is given to people that have finished C++ training and need something to exercise on.
While it is a good start, I’d add you may find a lot of interesting ideas in QuantLib (https://www.quantlib.org/).
Please also be careful with double for price and quantity especially in HFT and especially with asset types like BTC. The precision issues may lead to some confusion and eventual losses here and there. I noticed that you use fuzzy floating point comparisons, even in tests. That may not be suitable for important use cases.
Please also add some examples for specific trading strategies. Let’s say if you have back testing and some simple historic data in JSON a good example could be a comparison of two trading strategies and the difference compared to most optimal trading strategy possible.
Appreciate your interest.
Yea, there is lot to be added, that's by design. I'm not aiming for one-pass toy, this is foundational infra, not a weekend simulator.
FP numbers wrapper are planned. Sharing strategies is not a priority, maybe I will add some just for demo. And for sure I'm not sharing backtesting engine.
Goal to build infra - not give away alpha.
On that angle - I like the project structure, overall, CMake use and documentation. It was helpful to understand, high level, before diving into code.
I also recall the discussion here related to fast associative containers, like unordered map/set. This is the implementation - https://github.com/martinus/unordered_dense
Combined with HFT CppCon talk that emphasizes the impact of node-based STL containers you may benefit from using some optimized hash maps on top of vectors, if you aim at top-performance in runtime. Also, abseil has some flat sets/maps implementation. All of this could be a nice addition if you experiment with performance (I figured that from std::pmr use in your project).
100% agreed, stl containers should be replaced. The problem here is that I'd like to keep the core dependency-free... However, functionality first, squeeze maximum later. I'll definitely give a try for non-stl containers and if measurements beat - make the usage of container implementation controllable by compilation options, keeping things configurable as much as possible.
Thank you for your ideas and advice! Great and valuable feedback