Discussion in 'Automated Trading' started by ppy93, Oct 29, 2021.
If your trading logic in python it is already slow, do you really need to optimize the lower layer?
Bleeding edge stuff aside, unless you have a specific need, +1 on this comment: start with Boost.python.
This isn't a good design pattern, you'll just pay most of your latency communicating to/from redis or rabbitmq.
As others have pointed out, one possibility is to use boost bindings inside your Python application. I've used boost and it is tolerable, but I don't really like maintaining that pattern either.
Why FIX? Don’t they offer other choices?
I belive the OP is thinking of a temp solution using C++ and python.
I highly recommend FIX over a broker's proprietary API. I was stuck with Interactive Brokers for far longer than I otherwise would have been because I didn't want to have to rewrite all my code. Would have been much easier decision if I had used FIX originally. As long as you're not using it to retrieve quotes it's also one of the fastest options.
fIf you do HFT, FIX is not preferred and for HFT guys programming is not an issue.
Obviously code can be designed better so that the lowest layer of connectivity can easily change without touching the business logic. FIX is not a feasible option for hft.
I am not doing HFT yet but I am interested in getting into it. As a result, I might as well plan in advance for the execution part of the code.
Correct. This is a temporary solution before I rewrite everything in C++. My current strategy is not very latency sensitive and Python is fast enough.
Separate names with a comma.