高频交易软硬件是怎么架构的？

这个链接给出了大量信息。 When Milliseconds Make Millions: Why Wall Street Programmers Earn the Big Bucks -- Application Development Trends

但问题是这里的信息覆盖了所有可能。从FPGA,GPU到C/C++到Java/.NET到Erlang/Haskell。有意思的是有人在回复中说高盛被偷走的主要是Erlang代码。

很显然，不同公司的方案大不相同。但让我费解的是，不同消息来源暗示的关注点完全不同。比如说，有消息来源说只有性能关键的少数部分是C++，而也有消息来源说latency已经达到了nanosecond级别，而且至少都是us级别。
latency达到nanosecond级别是非常疯狂的，因为航空航天的realtime只能到几十us的程度。这意味着任何操作系统都将成为累赘，甚至baremetal的软件也达不到此要求，唯一可能是把逻辑全部写在FPGA里。无法想象能用FPGA实现极其复杂而且高度变化的数学模型。
好吧，假设有这样的硬件存在并可商用，那么如此辛苦得来的高效如何与C++甚至Java并存呢？别说软件，哪怕是memory bus都将成为瓶颈。而又有消息指出被广泛使用的操作系统是Linux。Linux最多介入下软实时，这还都是得在mainstream上单独打patch才能勉强过关，在比硬实时还高一个级别的场景里不可能用的上。
还有些信息来源指出FP的广泛应用，这可以理解为对程序正确性的要求，但在密集浮点计算领域根本没FP什么事，占统治地位的还是FORTRAN。不知道有没有把FP编译成CUDA目标的编译器存在？

诛心之论，是高频交易界故意模糊视线并人为抬高门槛。哪怕高频交易中的经济和数学模型再天外飞仙，在软硬件架构上还是得落地，因为目前技术极限在这摆着，再加上相互矛盾的信息来源也暗示了故意搅浑水的可能性。

但我的这些想法全都没有确凿证据，隔行如隔山。希望有专业人士指点一二。谢谢。

------------------------------
update 2013.10.31
------------------------------

看了几位的回答后，意识到有不少概念没讲清楚，连问题本身也没有明确。遂更新如下。

1. 具体在问什么
标题其实很清楚，就是想知道一个实际运行的高频交易系统的软件和硬件架构。其中应该包括网络拓扑，硬件资源，软件结构等等等等。
但我还顺便掺入了我对HFT报道的怀疑，也就是到底HFT采用的硬件和软件是不是跟广告中说的那么神奇。

2. 对latency的定义
按原文中的描述，是"ultra low latency trading"，并且是"wire-to-wire"的。我的理解是，一个HFT的计算节点，有能力在几百ns内处理完一个网络上接收到的信息包，并将结果返回到网络上。
这个信息包从物理上来说是一个IP packet，所谓的“接受”和“返回”，指的是从直接连接这个计算节点的router的角度来观测的。

3. FP指的是Functional Programming。因为那篇文章反复提到了Erlang/OCaml/Haskell/Lisp。我之所以会提到编译器，是因为文章同时反复提到了CUDA，因此我猜测既然又要利用FP逻辑不容易出错的特性，又要利用CUDA的SIMD/SIMT特性，那这个接口工作交给编译器是不是更方便些。

4. realtime
在这里我语焉不详并混淆了概念。确实，软实时还是硬实时指的是任务完成是否有guarantee或者说上限。我真正要表达的意思是，以我的了解，不用硬件解决方案不可能达到ns数量级。（下面会补充说明）

5. 为什么我理解HFT的逻辑是复杂并多变的
因为首先做HFT的都是理论物理，数学方面的博士教授甚至菲尔兹奖得主。所以其逻辑肯定是非常复杂的。其次，从文章以及其它描述HFT码农的文章来看，HFT码农面对持续的高压，并且要快速做出修改，甚至是online的修改，所以我猜测软件需要实现的逻辑需要持续的修改。

6. 关于现在工业上的network stack能做到多快，我有一些第一手的资料
我个人提交了两个feature的补丁给DPDK并被接受，所以我还是比较了解DPDK的。
另外我还propose了一些Intel 10G NIC driver的补丁。
并且我也实际测试过DPDK+10G PCIE的thruput和latency。
结果很不妙。关键不在DPDK或者网卡或者cache或者CPU或者bus，而在Linux。
只要是跑在Linux上的-无论usr space还是kernel module，都注定达不到ns的latency，甚至连us都达不到。这都归咎于无处不在的soft irq和sched。是的，我知道affinity和cpuisol，没用，真的。
虽然我没接触过连PCIe都嫌弃的方案，连DMA都订制的方案，但我认为瓶颈不在那，根据Amdahl那些改动没有用。
另外，这还没考虑HFT自己的逻辑，按那篇文章的介绍，不管是FPGA还是GPU实现的浮点计算，那么光是数据从网卡到bus再到GPU然后再回来，加上GPU计算--这都还没考虑CPU的调度带来的损耗--能在1000个cycle内跑完就算很不错了。

ok，废话可能太多了点。总之我想说的是，从文章（SO上也有类似问题及回答）来看HFT有一些不差钱的解决方案，但这些不差钱的方案却又不是整个系统的瓶颈所在，相反，HFT还为了向正确性/可维护性妥协而采用了大量减慢系统的方案。这是怎么一回事？到底是因为HFT就是这样（是的我就是钱多，我吃一碗倒一碗），还是HFT的宣传全是不符合事实的？

zhu xiaojie · 2018-10-16 00:01:31

个人不是做软件的，觉得硬件上FPGA+直接光纤开关驱动，据我所知几年前投行就有兴趣了。算法上区别不大，再差的算法用NB的FPGA照样跑起来，不过就是多用硬件资源罢了。除非真是烂到极点的算法，把所有LE都用完了，还要pipeline输出的
另外通讯上，PCI-E 级别的latency 在uS， USB 和ETHERNET在10s us，呵呵，还没跑到算法呢，就已经us去了，还要响应输出等等。FPGA简单暴力。