1樓：Xi Yang
低延遲的關鍵不在於效率優化，而是在於保證最差情況。
我們做音訊開發，實時性要求可能比交易還高，專業程式通常要求在48k Hz的32個（甚至更少）取樣點所對應的時間裡不能超時。這個時間是非常短的，因為現代作業系統的時間片通常都有1毫秒，所以你不能進行任何可能導致自己被切出去的操作：
不能做記憶體分配，因為可能進入和其它程序進行搶占的狀態，自己被切出。
不能用系統級別的鎖。
不能訪問io，比如讀寫磁碟、打log。
為了達到這個目的，你需要：
預先分配好所有的計算快取，計算時直接用。
UI執行緒和實時計算執行緒之間用原子操作通訊。
所有的硬碟資源讀取都放到另乙個執行緒，自己擼乙個無鎖的快取機制。
2樓：
能在編譯期搞定的東西都在編譯期搞定，寧可多耗費編譯時間。
少用鎖。
減少上下文切換開銷，包括函式棧，核間，協議層之間等等。
善用工具，找到瓶頸。
3樓：富察
- 共享記憶體
- 無鎖佇列等無鎖資料結構
- 避免動態分布記憶體
- 避免false sharing
- 盡量fit進cacheline，傳遞的資料越少越好- 少log，甚至不log
- onload或者exablaze
- 核隔離
- interrupt繫結
- 各種book management的trick，可以考慮不同的資料結構，張開想象的翅膀
- 全系統無鎖
2019-03-22 更
國內的「門道」是令人髮指的。。。主要是分析清楚哪個地方是什麼級別的延遲，安排好解決問題的優先順序。
4樓：「已登出」
有些回答的確很扯淡。
執行緒切換，訊號量混洗的時間，都是毫秒級別的，如果真的要求微秒級的反應速度，就必須保證，交易期間不能發生任何執行緒切換，所以各類鎖之類的都不能用。
有人居然說到多執行緒，非同步io，那肯定是不可能達到要求的。
5樓：自由獵手
以上的回答都很好。從計算機專業的角度，還有一點明顯很重要，不知道是不是因為太常識了，還是大家都疏忽了沒提到。
普通的應用訪問網路，是通過底層作業系統Socket API。也就是說，必須從使用者態切換到核心態，然後再轉回來。這個時間開銷是相當大的。
所以據我所知，高頻交易應該都是使用使用者態TCP棧的。這方面的第三方庫有幾個，有興趣的同學可以去github上搜一下。
6樓：技術分子
針對這個問題，除了網路、頻寬、伺服器這些硬體系統面的因素。如果問題主要聚集在C++的軟體實現面，那我來安利一下，主要的效能優化考慮事項：
The Art of Benchmarking
Conducting Time Measurements
Baselines
Strength Reduction
Minimizing Indirections
Eager Computation: Tables vs. Computation
Lazy ComputationMemoization
Computation vs. Tables
Lazy Structuring
Instruction-Level Parallelism
Inlining
Smart Resource Optimizations
Copy Elision
Scalable Use of the STL
Building Structure on Top of Arrays
Large Set Operations and Derivatives
Contention Minimization
這實際上是Facebook開源Folly庫的主創者 Andrei Alexandrescu 10月27日在上海的培訓提綱：《大規模系統軟體效能優化》高階培訓，感興趣的朋友可以看看。
順便安利一下 ，10月28-29日在上海舉辦的「2016 C++及系統軟體技術大會。 C++之父 Bjarne Stroustrup和大神Andrei Alexandrescu都將出席演講。
7樓：
FPGA是給手殘的人用的，嘿嘿。因為很多人用不好強大複雜的硬體和OS，所以只好去用FPGA了。就如同不會開航母的人只好去開小舢板。
首先要夠快拿到資料，你接的switch是不是ECN那邊最快的switch。
其次你能多快的速度在開盤的瞬間處理100w條quote？FPGA，算了吧。想併發的同學可以試試GPU，比FPGA還犀利。一旦併發，你就已經輸了。
第三你要意識到unpredictable delay並不是你的敵人，而是你的朋友。
8樓：
樓上的扯蛋的比較多
算來也在一家比較大的prop幹了不短時間了最近都不說自己搞的是hft，因為很多人都聲稱自己搞hft，能得我們很無奈，所以我現在做的是ultra high frequency.
資料的話，t2o, tick to order, 700nanosecond
FPGA + share memory，很多std的東西都不能用，都是自己的lib， 都是單執行緒，沒有lock，最少IO， log很少， 用C++主要是寫起來簡單，但大部分情況下都是C sytle
9樓：
早上看到，隨便講一點和CPP本身有關的特性。編譯期決定，比如meta programming. 非鎖同步.
cache friendly optimization等等。速度實際上還要調。而不經過核心TCP棧的也是必須的。
同機內通訊用shared memory,集群內用組播
10樓：胡彥
回答問題的有多少是高頻交易員？目前國內最重要的是你能比別人先拿到同一時間戳的Tick資料。搞不定前面毫秒級差異，再是挖空心思優化系統及程式那十幾微秒，都是徒勞。
11樓：
1. 成熟的訊息驅動框架
2. Zero copy/kernel bypass3. CPU isolation
4. 精簡業務層邏輯
有些交易所還嫌這不夠快，在自己的matching engine邊上擺起了機架租給這些做高頻交易的...
12樓：
曾經寫過後端，略知一點點。不要用QuickFix 了，自己琢磨好好寫 fix engine 和 OMS 吧。然後花錢燒硬體吧，把CBOT 樓下的包子鋪給盤下來。
13樓：
kernel bypass，使用專用網絡卡搭配使用者態網路協議棧，比如 openonload。
Update：
其他的軟體層面的優化可以做的還包括使用 realtime scheduler，cpu pinning，memory prefaulting 等等；部署上可以採用 colocation，把機器放在交易所的機房；硬體上，可以採用專用的網路裝置，當然機器配置越高越好。程式本身的優化手段和其它場景並無太多差異。
你交易系統中的盈利核心是什麼？
滴水成河 我的交易之路至今就是一種放棄自我的過程，而現在我似乎把自我放棄的什麼也不剩了！我現在敬畏到不敢揣測市場的意圖 只能亦步亦趨的跟著市場的屁股走。市場面前機械冰冷的系統完勝智慧型的生物！緊緊跟隨長征的步伐，不要掉隊 魔鬼k叔 穩定盈利的核心 完善的交易系統 資金管理 信心 執行力 自律 不斷學...
趨勢交易，以支撐阻力為核心的系統一直虧損，求解惑？
2選1先生 說支撐就代表了趨勢，已經掉頭了。能否再次向上。這個得需要能夠在支撐位支撐住。那麼你可能就說在這個位置上有困惑。大勢已去，能否有生機？這已經代表了趨勢向上的困惑了。所以說從概率上來講也要看環境。 Neil 你是不明原理，上去胡來。你首先要明白它是向上的，還是向下的，如果向上，你在阻力位攔截...
如何確保自己的交易系統是正期望？
星辰巫師 先說結論，沒有人能確保自己的交易系統是必然盈利的，只能確信。而這確信是建立在多年的交易盈利的基礎上的。在長期盈利之前就妄想找到乙個必定盈利的系統，只能是緣木求魚。我認為交易系統並不是純粹客觀的東西，它應該是交易策略 交易者。經過多年的交易實踐，我們的交易策略和我們自身都經過了反覆的修正和磨...