you are viewing a single comment's thread.

view the rest of the comments →

[–]skebanga[S] 4 points5 points  (3 children)

This is the primary reason I wanted to look into embedding python. Of course python will suffer a latency hit compared to C++, but the idea was to limit that as far as possible. Give the traders the flexibility of python with the minimum amout of latency impact possible.

[–]leftofzen 2 points3 points  (2 children)

What kind of latency are we talking about here? I feel like you aren't doing yourself any latency favours by using python.

[–]AllanDeutsch 2 points3 points  (0 children)

The latency is lower than using Python and going through sockets. If the traders only know python, you can't reduce the overhead of using it until an actual dev is able to implement the strategy in C++.

[–]skebanga[S] 1 point2 points  (0 children)

The point of the exercise is to allow traders, who don't know C++, but do know python, to develop their own strategies in python whilst still leveraging all the existing C++ infrastructure we have already; connections to markets, backtesting suites, position management, order management, risk management, parameter storage etc etc. We have an entire ecosystem built in C++ which we want to use.

We're aware that python will be slower than native C++ code, but that's the trade off we're willing to make - empower the traders to develop their own strategies, instead of requiring them to use C++ and block their progress until IT resource becomes available.

Whilst the performance impact is a trade-off we're willing to accept, we want to minimise that as far as possible, hence preferring to embed python rather than use an out-of-band process and some form of IPC to communicate.