Python 做高頻交易系統適合哪個層級的延遲？

latency指tick to trade. 可以容許少數核心函數用cython或直接c來實現。

回複內容：

我對 Python 不算熟，不過可以提供一些思路。

首先做一個最基本的測試，連續取兩次系統時間，精度在納秒，看看延遲如何。先來看一段純 C 代碼：

#include uint64_t nanotime(const struct timespec *ts){   return (ts->tv_sec * kT_ns_in_s) + (ts->tv_nsec);}uint64_t    n=50000;uint64_t    sum=0;uint64_t    latency=0;for (i = 0; i < n; i++) {    clock_gettime(CLOCK_REALTIME, &start);    clock_gettime(CLOCK_REALTIME, &end);    sum += nanotime(&end) - nanotime(&start);}printf("Latency: %d ns\n", sum / n);

比較現實的說是1ms層級的，如果你用python現成的library(urlib, request)接收資料至少有100us層級的延遲，一般交易系統需要多線程，python的GIL又會增加延遲，而且交易最忙的時候因為處理大量資料，python的GC更容易發生。用C或Cython寫核心部分不能提高很多，因為python的延遲是因為language design而不是computation造成的。當然這些問題可以改進，比如自己做一套tcp串連程式什麼的，不過這些恐怕並不比寫c++更容易。

另外上面的回答裡的時間測試不一定有代表性，在一個簡單的loop測時間的話compiler和CPU會做很多你想不到的事情，結果會和真實值差很多。

