我认为C/C++与C#/Java的性能问题很容易理解，这意味着我已经阅读了足够的证据表明VM语言不一定比“接近硅”的语言慢。主要是因为JIT编译器可以执行静态编译语言无法执行的优化。
但是，我最近从一个人那里获得了一份简历，该人声称基于Java的高频交易总是被C++击败，而他一直处于这种情况。
快速浏览工作站点确实表明HFT申请人需要C++知识，而Wilmott论坛则显示了所有谈论C++的从业者。
发生这种情况有什么特殊原因吗？我以为随着现代金融业务的复杂化，将首选具有类型安全性，托管内存和丰富库的VM语言。这样，生产率就更高了。另外，JIT编译器越来越好。他们可以在程序运行时进行优化，因此您会认为他们使用该运行时信息来击败非托管程序的性能。
也许这些人正在用C++编写关键位并从托管环境(P/Invoke等)中调用它们？那可能吗？
最后，是否有人对这个中心问题有经验，这就是为什么在这个 Realm 中，毫无疑问，托管代码比托管代码更受青睐吗？
据我所知，HFT人员需要对传入的市场数据做出最快的 react ，但这并不一定是hard realtime的要求。可以肯定的是，如果速度缓慢，情况会更糟，但是您不必保证每个响应都具有一定的速度，您只需要快速的平均即可。
编辑
是的，到目前为止，有几个很好的答案，但是很笼统(很好的基础)。让我指定HFT家伙将运行哪种程序。
主要标准是响应能力。当订单进入市场时，您想成为第一个对此使用react的人。如果您迟到了，其他人可能会在您之前采取措施，但是每个公司的策略都略有不同，因此如果一次迭代有点慢，则可能会没事。
该程序全天运行，几乎不需要用户干预。无论处理什么功能，每条新的市场数据都会每秒运行数十次(甚至数百次)。
这些公司通常对硬件的价格没有限制。
最佳答案
首先，1 ms是HFT中的永恒。如果您认为并非如此，那么最好再阅读一下有关该域的内容。 (这就像离交换机100英里。)吞吐量和等待时间都深深地缠绕在一起，因为任何基本排队理论教科书中的公式都会告诉您。相同的公式将显示抖动值(如果网络结构正确并且您没有配置足够多的内核，则通常由CPU队列延迟的标准偏差决定)。
HFT套利的问题之一是，一旦您决定获取价差，就有两条腿(或更多条腿)可以实现获利。如果您未能全力以赴，那么您可能会遇到一个自己确实不想要的职位(以及随后的损失)-毕竟，您在套利而不投资。
您不希望有职位，除非您的策略是预测(非常近期!!!) future (而且，不管您信不信，这都做得非常成功)。如果您距离交换还有1毫秒，那么您的订单中有很大一部分将不会执行，您想要的将被提取。那些执行过一条腿的人很可能最终会失败，或者至少没有赢利。
不管您采用哪种策略，都是为了争辩而说，最终赢/输比是55％/45％。即使获利/亏损比率的微小变化也可能导致盈利能力的重大变化。
回复:“运行几十(甚至几百)”似乎是数量级的。即使看了20000滴答，似乎也很低，尽管这可能是他正在看的一整天的平均值。
在任何给定的秒中看到的速率都有很大的差异。我举一个例子。在我的一些测试中，我观察了一天中的7种OTC股票(CSCO，GOOG，MSFT，EBAY，AAPL，INTC，DELL)，该流的每秒速率范围从0 mps(非常罕见)到每峰值每秒几乎有2000条报价和交易。 (请参阅为什么我认为上面的20000很低。)
我为此 Realm 构建了基础架构和测量软件，我们讨论的数字是每秒10万和数百万。我有C++生产者/消费者基础结构库，可以在生产者和消费者(32位，2.4 GHz内核)之间每秒推送近500万(500万条)消息。这些是64字节的消息，在生产者端带有 new，构造，排队，同步，而同步，出列，触摸每个字节，运行虚拟析构函数，在消费者端免费。现在公认的是，这是一个简单的基准测试，没有在端点管道阶段的端点使用Socket IO(并且Socket IO很难看)。所有自定义同步类仅在为空时进行同步，自定义分配器，自定义无锁队列和列表，偶发的STL(具有自定义分配器)，但更常见的是自定义侵入式集合(我有一个重要的库)。我已经多次给这个 Realm 的供应商提供四倍(甚至更多)的吞吐量，而不会增加套接字端点的批处理。
我有OrderBook和OrderBook::Universe类，它们在22000多种工具上求平均值时，用于新，插入，查找，部分填充，查找，第二填充，擦除，删除序列的时间少于2us。该基准测试在插入的第一个填充和最后一个填充之间按顺序遍历所有22000种仪器，因此不涉及廉价的缓存技巧。同一本书的操作由22000本书的访问分开。这些并不是真实数据的缓存特性。实际数据在时间上更加本地化，并且连续交易经常击中同一本书。
所有这些工作都需要仔细考虑所使用集合的任何算法成本中的常量和缓存特性。 (有时候，KO(n)KO(n * log n)等，等等等等中的K看起来有点过于模糊了)
我从事Marketdata基础架构方面的工作。甚至无法想到使用Java或托管环境来完成这项工作。而且，当您可以使用C++获得这种性能，而我认为在托管环境下获得百万/mps的性能非常困难时，我无法想象任何重要的投资银行或对冲基金(其薪水为25万美元)顶尖的C++程序员一无所获)不使用C++。
有没有人能从托管环境中真正获得2000000 +/mps的性能？我认识这个舞台上的几个人，没有人向我吹牛。而且我认为在托管环境中使用2mm的产品将具有吹牛的权利。
我知道一个主要播放器的FIX顺序解码器每秒执行12000000个字段解码。 (3Ghz CPU)是C++，编写它的人几乎向任何人提出了挑战
在一个甚至只有一半速度的托管环境中。
从技术上讲，这是一个有趣的 Realm ，面临许多有趣的性能挑战。当基础证券发生变化时，请考虑期权市场-可能会有6个未定价的价格点，具有3或4个不同的到期日期。现在每笔交易大概有10-20个报价。这些报价可能会触发期权价格变动。
因此，对于每笔交易，期权报价可能会有100或200个变化。它只是大量数据，而不是像大型强子对撞机碰撞检测器那样的大量数据，但仍然是一个挑战。这与处理按键有所不同。
甚至有关FPGA的争论还在继续。许多人认为，运行在3GHZ商品硬件上的经过良好编码的解析器可以击败500MHz FPGA。但是，即使基于FPGA的系统稍微慢一点(不是说它们确实如此)，其延迟分布也会趋于紧密。 (请读“tend”-这不是一个笼统的声明)当然，如果您有一个很棒的C++解析器，您可以将其插入Cfront，然后再将其插入FPGA图像生成器中……但这又是一场争论……
关于.net - C++与虚拟机语言在高频财务中的性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3175072/