C++与虚拟机语言在高频金融中的性能比较

Question

C++与虚拟机语言在高频金融中的性能比较

33

我认为C/C++与C#/Java的性能问题已经被广泛讨论过了，这意味着我已经看过足够的证据表明VM语言不一定比"接近硅"的语言慢。这主要是因为JIT编译器可以进行静态编译语言无法完成的优化。

然而，最近我收到了一个人的简历，他声称基于Java的高频交易总是被C++击败，而且他曾经遇到过这种情况。

快速浏览招聘网站确实显示HFT应聘者需要掌握C++知识，而在Wilmott论坛上，所有从业者都在谈论C++。

这是为什么呢？我本以为在现代金融业务变得更加复杂的情况下，带有类型安全、管理内存和丰富库的VM语言会更受欢迎。这样生产力会更高。此外，JIT编译器变得越来越好。它们可以在程序运行时进行优化，所以你会认为它们会利用运行时信息打败非托管程序的性能。

也许这些人正在用C++编写关键部分，并从托管环境中调用它们（P/Invoke等）？这可能吗？

最后，有没有人有这个领域的核心问题的经验，即为什么在这个领域非托管代码无疑比托管代码更受欢迎？

据我所知，高频交易员需要尽可能快地对市场数据做出反应，但这并不一定是一个硬实时要求。如果你反应慢了，那么情况会更糟，但你并不需要保证每个响应的速度，你只需要平均速度快即可。编辑目前有一些很好的回答，但比较笼统（老生常谈）。让我具体说明一下高频交易员运行的程序类型。

主要标准是响应能力。当订单进入市场时，您希望能够第一个对其做出反应。如果你来晚了，别人可能会在你之前拿到它，但每家公司的策略略有不同，所以如果一个迭代较慢，你可能还是可以的。

程序全天运行，几乎没有用户干预。无论每个新市场数据的处理函数如何，都会每秒运行数十次（甚至数百次）。

这些公司通常没有硬件费用限制。

- Carlos

3

说“如果一个迭代比较慢可能还可以”听起来有点一厢情愿。这听起来像是：“我非常想使用C#，你确定不行吗？”一个迭代慢意味着你的收益会减少。这可能“还可以”，但尽可能要避免这种情况发生。几天前，我和一个高频交易开发人员交流时，他非常明确地强调：“如果一个操作需要1毫秒，那就太慢了”。他们确实使用了C#和C++的混合编程，但是如果对方认为1毫秒的延迟是无法接受的，那么很难说服他们使用带有垃圾回收机制的语言来处理时间关键组件。 - jalf

2

你不认为一次慢迭代没关系吗？因为这个东西会运行数百万次。当然，如果你总是比其他人慢，那是不行的。但是，如果你每天要买卖几百万股，平均速度更快才是最重要的。我想知道C ++的需求是历史原因（已有代码库）还是真的有性能优势。 - Carlos

1

也许由GC引起的延迟是你输给使用竞争对手平台编写的非GC语言的其他人交易的决定性因素。我认为这对于活跃交易者来说会产生巨大的影响。 - 5ound

4

@Carlos：但你假设只有一个迭代会"有点慢"。比如说，你每秒获取20,000个价格（这是我跟一位开发者交流时他说他们系统能处理的）。这意味着如果GC花费50毫秒运行一次垃圾回收，你不仅错过了一个单一价格，还错过了很多。而且这不仅仅发生一次，它会定期发生，随着垃圾的积累而加剧。而且我们必须明确，你不是基于“如果我80%的时间能跟得上就可以”的假设进入HFT市场的。你这样做是因为你认为你可以在每一次迭代中跑得比其他人快。 - jalf

1

我认为要记住的一个重要事项是，当即时编译器在编译时无法确定运行平台时，它非常擅长优化。这对于高频交易可能不适用。Java可以利用特定的硬件，但如果你愿意放弃二进制文件的可移植性，C++也可以。 - Niki Yoshiuchi

显示剩余3条评论

15个回答

28

很大程度上，这归结于事实和理论之间的简单差异。人们提出了理论来解释为什么Java应该（或至少可能）比C ++更快。大多数争论与Java或C ++本身关系不大，而是与动态编译与静态编译有关，而Java和C ++只是两种的示例（当然，可以将Java进行静态编译，或者将C ++进行动态编译）。这些人中的大多数都有基准测试来“证明”他们的说法。当对这些基准测试进行检查时，很快就会显而易见地发现，在相当多的情况下，他们采取了相当极端的措施来获得他们想要的结果（例如，在编译Java时启用了优化，但在编译C ++时特别禁用了优化）。

与计算机语言基准测试大赛相比，那里几乎任何人都可以提交条目，因此所有代码往往都被优化到合理的程度（在某些情况下甚至是不合理的程度）。这似乎很清楚地表明，相当多的人将其视为竞争，每种语言的支持者都尽力“证明”他们偏爱的语言最好。由于任何人都可以提交任何问题的实现，特别差的提交对总体结果影响不大。在这种情况下，C和C++成为明显的领导者。

更糟糕的是，如果有什么，这些结果可能显示Java比实际情况要好。特别是，使用C或C ++并且真正关心性能的人可以（而且通常会）使用Intel的编译器而不是g ++。这通常会使速度比g ++快至少20％。

编辑（针对jalf提出的一些观点进行回应，但在评论中实在太长了无法合理适配）：

指针是优化编程者的噩梦，这有点言过其实。指针导致别名可能性，某些情况下会阻止某些优化。但是，在线性化大部分时间可以避免不良影响（即，编译器可以检测是否存在别名，而不总是在假定可能存在的情况下生成代码）。即使代码必须假定存在别名，缓存也可以将性能下降最小化（即，在L1缓存中的数据仅比寄存器中的数据稍微慢一点）。在C++中防止别名会提高性能，但远没有你想象的那么多。
带有垃圾回收器的分配速度更快。确实，许多C++实现中的默认分配器比大多数（当前）垃圾收集分配器提供的要慢。这通过C++中的堆栈分配通常很快来平衡（至少到某种程度上），而在GC语言中，几乎所有分配通常都在堆上。更糟糕的是，在管理语言中，通常为每个对象单独分配空间，而在C++中，您通常为作用域中的所有对象分配空间。

事实上，C++直接支持全局和逐类替换分配器，因此当/如果分配速度真的成为问题时，通常很容易解决。

最终，jalf是正确的：这两个观点无疑有利于"托管"实现。然而，应该保持对改进程度的透彻认识：它们不足以让动态编译实现在大部分代码上运行更快，甚至不能在从一开始就尽可能支持它们的基准测试中运行更快。

编辑2：我看到Jon Harrop试图插入他那两亿分之一美分的价值。对于那些不认识他的人，Jon已经成为了一个臭名昭著的恶意评论者和垃圾邮件发送者多年了，并且似乎正在寻找新的领域来播种杂草。我想详细回复他的评论，但（像他通常做的那样），它仅包含未经资格证明、无支持的概括性陈述，几乎没有实际内容，因此无法做出有意义的回复。我们只能警告旁观者，他以不诚实、自私和最好被忽略而闻名。

- Jerry Coffin

@Dirk：MSVC++？你可以免费获得Express版本。他们在Ultimate版本中还提供了一个可爱的Profile Guided Optimization功能和一个强大的分析器。 - Puppy

1

@DeadMG：你明白Shootout网站似乎是基于Ubuntu Linux服务器的时间吗？因此，你的MSVC++建议缺乏实用性。 - Dirk Eddelbuettel

关于内存分配，你对C++中的堆栈使用是正确的。我的观点只是原始操作“从堆中分配x字节”在C++中更加昂贵。同样，这可以通过使用内存池和自定义分配器或在堆栈上分配对象来补偿。但它显示了托管语言具有的一个优势。我的观点只是双方都有优势，所以它并不像“一个比另一个更快”那么简单。这取决于情况。 - jalf

@jalf：当然，因为C++为你提供了世界上所有的力量，你可以克服这个问题并使用一个池。试着在C#中创建一个不继承自System.Object的对象。 @Dirk：我真的不在乎。问题是对于Windows用户来说，这个站点是无用的，因为它比较的是Linux性能。我不是因为没有比较Windows而攻击它。我只是想说这与我无关。 - Puppy

@DeadMG >> 对于Windows用户来说毫无用处，因为它比较的是Linux性能 << 或许有一天其他人会付出努力，使用现有的win32定制Python测量脚本来测量不同的编程语言实现 http://shootout.alioth.debian.org/demo/benchmark.php?test=all&lang=java&lang2=csc - igouy

显示剩余8条评论

14

理论上，JIT编译器可以进行很多优化，但你愿意等多久呢？ C++应用程序可能需要几个小时才能编译完成，因为它是离线完成的，用户不必坐在那里等待。

JIT编译器必须在几毫秒内完成。因此，你认为哪个可以获得最复杂的优化？

垃圾收集器也是一个因素。这并不是因为它比手动内存管理要慢（我相信其分摊成本非常好，绝对可与手动内存处理相媲美），而是因为它不太可预测。它会在任何时候引入停顿，这在需要极其响应的系统中可能是不可接受的。

当然，不同的语言适合不同的优化方式。C++允许你编写非常紧凑的代码，几乎没有内存开销，并且许多高级操作基本上是免费的（例如类构造）。

另一方面，在C#中，你会浪费大量内存。即使你实际的类为空，简单地实例化一个类也会带来相当大的开销，因为基本的Object必须被初始化。

C++允许编译器积极地剥离未使用的代码。在C#中，大部分代码必须存在，以便可以通过反射找到它们。

另一方面，C#没有指针，这是优化编译器的噩梦。在托管语言中进行内存分配比在C++中要便宜得多。

无论哪种方式都有其优势，因此期望得到简单的“选择一个”答案是天真的。根据代码、编译器、操作系统和运行硬件的确切情况，其中一个可能更快。并且根据你的需求，原始性能可能不是第一目标。也许你更感兴趣的是响应能力，避免不可预测的停顿。

一般而言，你典型的C++代码将表现出与等效的C#代码类似的性能。有时更快，有时更慢，但两者之间可能没有显著的差异。

但是，这还取决于具体情况。它也取决于您愿意花多少时间进行优化。如果你愿意花费足够的时间，C++代码通常可以比C#实现更好的性能。只是需要付出很多努力。

当然，另一个原因是，大多数使用C ++的公司已经拥有庞大的C ++代码库，他们不想丢弃它。即使他们逐渐将（一些）新组件迁移到管理语言，他们仍需要它继续工作。

- jalf

2

JIT编译器可以缓存其结果（例如.Net），因此您只会在第一次执行时受到影响。此外，在.Net的情况下，它们可以从单个源代码库对每台机器进行优化 - 这是静态编译器无法做到的。如果Java没有类似的功能，我会感到惊讶。 - Peter M

1

通过执行类似于C++在每种情况下都要执行的操作。C++并不在每种情况下执行复制垃圾收集器。 - J D

1

以下是 .NET JIT 编译器在内联方面的限制示例：http://blogs.msdn.com/b/davidnotario/archive/2004/11/01/250398.aspx。此外，JIT 编译器是以每个方法为单位操作的，因此不执行任何过程内分析。 - jalf

1

此外，静态编译器通常会迭代应用许多优化，以利用早期优化所带来的优化机会。JIT通常会减少迭代次数（可能仅运行单个迭代）。许多优化（例如寄存器分配）都是NP完全问题，因此它们通常被实现为启发式算法，给出“足够好”的近似值。而更多的时间投入则能得到更好的近似值。 - jalf

2

现在，我认为自己浪费时间已经结束了。你可能想要阅读我回答的问题，以及我的实际答案。然后请坐下来问问自己，你是否有任何与此相关的真正问题。我不认为OCaml或C++可怕的编译时间有什么关联，我也不明白为什么我的回答会因为提供每个该死的静态和JIT编译器执行的优化的完整列表而变得更好。 - jalf

显示剩余28条评论

9

这些公司通常没有硬件价格的限制。

如果他们也不在意软件的价格，那么我认为C++当然可以更快：例如，程序员可以使用自定义分配或预分配的内存；和/或他们可以在内核中运行代码（避免环路转换），或在实时操作系统上运行，和/或将其紧密耦合到网络协议栈中。

- ChrisW

啊哈，这听起来像是一些真正的优势。 - Carlos

实际上，我会说帮助内核/用户空间转换的趋势是更多地推向用户空间而不是内核。 - pgast

@pgast 我不明白这是为什么？在用户空间中，你必须先访问内核，所以你有一个额外的“层”要通过吗？将更多内容推入内核中，转换次数就会减少，不是吗？ - intrigued_66

2

除了性能之外，使用C++的原因还有很多。存在着大量的C和C++代码库，将所有这些代码都重写为其他语言是不切实际的。为了使P/Invoke等工具正常工作，目标代码必须设计成可以从其他地方调用。如果没有其他办法，你将不得不编写某种包装器来暴露完全的C API，因为你无法P/Invoke到C++类。

最后，P/Invoke是一项非常昂贵的操作。

JIT编译器变得越来越好。它们可以在程序运行时进行优化

是的，它们可以这样做。但是你忘记了任何C++编译器都能够进行相同的优化。当然，编译时间会更长，但是必须在运行时进行这样的优化事实上是额外的开销。管理语言在某些任务上可能会击败C++，但这通常是由于它们的内存模型而不是运行时优化的结果。严格来说，当然你可以在C++中拥有这样的内存模型，例如C#对字符串的处理，但是很少有C++程序员花费像JIT程序员那样多的时间来优化他们的代码。

存在一些性能问题是管理语言的固有缺点，即磁盘I/O。这是一次性的成本，但根据应用程序的不同，它可能非常显著。即使使用最好的优化器，您仍然需要从磁盘加载30MB+的JIT编译器，当程序启动时；而C++二进制文件很少接近那么大。

- Billy ONeal

但你忘了任何C ++编译器都能做出相同的优化。但是，C ++编译器不会像在线配置引导优化这样的操作。 - J D

1

@Jon：大多数JIT也不会这样做。而且你可以离线进行基于配置文件的优化。 - Billy ONeal

2

简单的事实是，C++是为了速度而设计的，而C#/Java则不是。

比如IEnumerable等语言中普遍存在的无数继承层次结构，与std::sort或std::for_each的零开销相比，C++的原始执行速度并不一定更快，但程序员可以设计快速或零开销的系统。即使像缓冲区溢出这样的问题，你也不能关闭其检测。在C++中，你有控制权。从根本上讲，C++是一种快速的语言-你不会为你不使用的东西付费。相比之下，在C#中，如果你使用stackalloc，你就不能不进行缓冲区溢出检查。你不能在堆栈上分配类，也不能连续地分配它们。

此外，还有整个编译时问题，C++应用程序的编译和开发时间都可能更长。

- Puppy

1

C# 的设计目的是不像 Java 那样慢。C# 中结构体的整个意义在于可以将它们分配到堆栈上或者有连续的数组。你还可以获取对象的指针并且不安全地使用它们而不进行边界检查。 - Gabe

@Gabe：我不同意你的观点，因为你是错误的。我提出了一些C#的限制，而你只举出了极少数情况。例如，你可以获取对象的指针，但不能超出当前范围。你可以连续分配结构体，但无法阻止它们从System.Object继承，浪费缓存空间并启用你不想要的转换和函数。在C++中，每种类型都可以是引用类型和值类型，并且在所有情况下都可以通过不安全指针访问。 - Puppy

2

jalf是正确的：C++是为低开销而设计的，而不是为了速度。Fortran是为速度而设计的，这就是为什么在C++中编写比Fortran更快的数值算法很困难。 - Gabe

@Gabe：这个问题明确要求比较C++和VM语言。如果你不是在评论C++和VM语言的性能，那你来这里干嘛？ - Puppy

3

@Gabe: 对不起，我以为你在回答那个问题。 - Puppy

显示剩余5条评论

2

这可能有点偏题，但我几周前看了一个视频，可能会对你感兴趣：http://ocaml.janestreet.com/?q=node/61。这来自一个决定将OCaml作为其交易主要语言的交易公司，我认为他们的动机应该能启发你（基本上，他们重视速度，当然还有强类型和函数式风格，以便更快地增量并更容易理解）。

- Shautieh

的确，F#（微软对OCaml的实现）经常用于此应用程序，因为它的速度更快（比OCaml好：http://flyingfrogblog.blogspot.com/2009/07/ocaml-vs-f-qr-decomposition.html）。 - Gabe

我对F#不是很了解，但如果我记得之前链接的视频没错的话，他们选择了OCaml而不是F#，并且在可预见的未来也不打算转换。其中一个原因是F#运行在.NET上，而.NET并不是专门为函数式语言设计的（因此并不总是像它本应该优化得那样）。 - Shautieh

当我在开发HLVM时，我问过他们这个问题，他们说符号性能对他们来说和数字性能同样重要。F#通常具有更好的数字性能，但其符号性能要差得多（通常比OCaml慢5倍左右），因为.NET的GC没有针对此进行优化。 - J D

谢谢更新，但是“5×”应该是多少呢？;) - Shautieh

LOL。×是表示“×”的HTML代码。 - J D

2

我们的大部分代码最终需要在数千台机器的网格上运行。

我认为这种环境改变了争论的方向。例如，如果C++和C#的执行速度差异为25％，则其他因素将发挥作用。当此代码在网格上运行时，编码方式可能无关紧要，因为一旦整个过程分散在多台计算机上，问题可能会得到解决，或者通过分配或购买更多计算机来解决。最重要的问题和成本可能变成“上市时间”，在这种情况下，C#可能是更快的选择和获胜者。

C++和C#哪个更快？

C#快六个月......

- AnthonyLambert

1

你不能简单地说C#比某个时间段更快。在C++中，优秀的开发人员可以像C#开发人员一样快速编码，除非你雇佣了糟糕的C++开发人员和优秀的C#开发人员。 - Raindog

我认为那是用笑话来说明一个观点。我已经编写 C++ 超过20年，C# 也有5年了...C#的某些特性使得开发更加容易和快速。通过反射，可以在编辑器内检查已编译的C#代码，并提供编辑时语法检查和更广泛的智能提示。标准类库（.NET）比C++的STL更为全面且协同。如果你花一些时间使用最新版本的Visual Studio和Resharper，你就会明白我的意思。 - AnthonyLambert

2

我认为使用C#，更多的开发人员将被归类为优秀，因为它更容易掌握。我认为一直以来很难找到优秀的C++开发人员，因为它更难掌握。 - AnthonyLambert

1

这不仅仅是编程语言的问题，硬件和操作系统也将起到关键作用。
要获得最佳整体性能，您需要使用实时操作系统、实时编程语言和高效的编程。

因此，在选择操作系统和编程语言方面，您有相当多的选择。有C语言、实时Java、实时Fortran等等。

或许，在编程FPGA/处理器方面会获得最佳结果，从而消除了操作系统的成本。

您需要做出的最重要选择是，在选择一种简化开发并运行更稳定的编程语言之前，将忽略多少可能的性能优化。这是因为您可以减少错误，提高系统的可用性。这一点不容忽视。与那些因为一些难以寻找的小错误而每隔一段时间就崩溃的其他应用程序相比，开发一个比任何其他应用程序快5%的应用程序没有胜利可言。

- Tobias P.

1

在高频交易中，延迟比吞吐量更为重要。由于数据源中固有的并行性，您总是可以将更多的核心投入到问题中，但是您无法通过更多的硬件来弥补响应时间。无论语言是预编译还是即时编译，垃圾回收都可能破坏您的延迟。存在具有保证垃圾回收延迟的实时JVM。这是一项相当新的技术，调整起来很麻烦，而且价格昂贵，但如果您有足够的资源，就可以做到。随着早期采用者资助正在进行的研发工作，它可能会在未来几年变得更加普及。

- Chris

2

总有下一个版本会非常快。Java开发人员已经这样说了15年;-) - Dirk Eddelbuettel

据我所知，实时垃圾回收在吞吐量方面的代价非常高（如50%）。 - J D

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- pgast · Accepted Answer

首先，在高频交易中，1毫秒就像是与交易所相距100英里。如果您认为这不是这样，那么最好再多读一些相关领域的资料。（吞吐量和延迟深度交织在一起，任何基本排队论教材中的公式都可以告诉您这点。同样的公式也会显示出抖动值（如果网络结构正确且核心配置足够，CPU队列延迟的标准偏差通常会占主导地位）。

高频交易套利的一个问题是，一旦你决定获取价差，就要实现盈利的两条（或更多）腿。如果你未能达成所有腿部，你可能会留下一个你真的不想要的头寸（以及随后的亏损），毕竟你进行的是套利而不是投资。

除非您的策略预测（非常短期！）未来（信不信由你，这确实已经被成功地实现了），否则您不希望有任何持仓。如果您离交易所还有1毫秒，那么你提交的订单中有相当大的一部分都不会被执行，而您想要的则会被吃掉。最有可能的是，已经执行了其中一条腿的订单最终会成为输家，或者至少不盈利。

无论您的策略是什么，举个例子，我们假设它最终取得了55%/45%的胜/负比率。即使胜负比率的微小变化也可能对盈利产生重大影响。

关于“运行数十个甚至数百”的说法似乎存在数量级上的错误。即使考虑每秒20,000个tick，但这可能是他正在观察的金融工具集的整个交易日的平均值。

每秒钟看到的速率有很高的变异性。我将举一个例子。在我的一些测试中，我查看7只场外股票（CSCO，GOOG，MSFT，EBAY，AAPL，INTC，DELL），在一天中间，这个流的每秒速率可以从0 mps（非常罕见）到几乎2000次报价和交易的峰值秒。（明白为什么我认为上面的20,000是低估的了。）

我为这个领域建立基础设施和测量软件，我们谈论的数字是每秒十万和百万级别的。我有C++生产者/消费者基础设施库，可以在生产者和消费者之间推送近5000000（5百万）条消息/秒，（32位，2.4 GHz核心）。这些是64字节的消息，生产者端使用new、construct、enqueue、synchronize，消费者端使用synchronize、dequeue、touch every byte、run virtual destructor、free。现在可以承认这只是一个简单的基准测试，没有Socket IO（socket IO可能很丑陋），就像终点管道阶段的终点一样。它们是全部自定义同步类，仅当为空时同步，自定义分配器，自定义无锁队列和列表，偶尔使用STL（带有自定义分配器），但更常见的是使用自定义侵入式集合（我有一个重要的库）。不止一次，我给这个领域的供应商提高了四倍（甚至更多）的吞吐量，而没有增加套接字端点的批处理。

我有OrderBook和OrderBook::Universe类，平均每22,000个工具包括新建、插入、查找、部分填充、查找、第二次填充、擦除、删除序列所需的时间不到2微秒。基准测试在插入第一个填充和最后一个填充之间按顺序遍历所有22,000个工具，因此没有使用任何廉价的缓存技巧。相同订单簿的操作通过访问22,000个不同的订单簿来分离。这些非常不是真实数据的缓存特征。真实数据在时间上更加局部化，连续的交易经常命中同一本书。

所有这些工作都涉及到对所使用的算法成本中的常数和缓存特性进行仔细考虑。（有时候似乎KO(n) KO(n*log n)等等等等中的K被轻率地忽略了）

我在市场数据基础设施方面工作。对于这项工作，甚至想使用Java或托管环境都是难以想象的。当你可以通过C++获得这种性能时（我认为在托管环境中很难获得每秒百万以上的性能），我无法想象任何重要的投资银行或对冲基金（对于一位顶尖的C++程序员来说，25万美元的薪水微不足道）不选择C++。

有人真的能从托管环境中获得2000000+/mps的性能吗？我知道这个领域的一些人，但从未向我炫耀过。我认为在托管环境中达到2mm的性能也值得炫耀。

我知道一个主要参与者的FIX订单解码器每秒处理12000000个字段解码（3 GHz CPU）。它是用C++编写的，该作者几乎向任何人发起挑战，要求用托管环境创造出即使只有一半速度的同等解码器。

技术上，这是一个有趣的领域，存在许多有趣的性能挑战。考虑期权市场当基础证券发生变化时 - 可能会有6个未解决的价格点，其中包括3或4个不同的到期日。现在，对于每笔交易，可能会有10-20个报价。这些报价可能会触发期权价格的变化。因此，对于每个交易，可能会有100或200个期权报价的变化。这只是一大堆数据 - 不像“大型强子对撞机”探测器那样多，但仍然是一个挑战。这与处理按键输入有所不同。

即使在FPGA的争论也在继续。许多人认为，在3GHZ通用硬件上运行的良好编码分析器可以击败500MHz FPGA。但即使略微慢一些（并不是说它们是），基于FPGA的系统往往具有更紧密的延迟分布。（请注意，“往往”-这不是一项全面的声明）当然，如果您拥有一个优秀的C++解析器，并将其通过Cfront推送，然后将其通过FPGA图像生成器推送......但这又是另一场辩论......