VC++ / C++ 高性能多线程 GUI 交易注意事项答案

【问题标题】：VC++ / C++ High performance Multithreaded GUI considerations for tradingVC++ / C++ 高性能多线程 GUI 交易注意事项
【发布时间】：2011-02-19 02:30:38
【问题描述】：

我有兴趣了解有经验的开发人员在为 Windows 平台开发高性能多线程 GUI 时会考虑哪些因素。我在开发交易应用程序的背景下提出这个问题，其中 GUI 非常动态且应用程序延迟是一个问题。

您看到过哪些架构，或者您会推荐查看 MFC 文档/视图以在这种情况下实现观察者模式。我相信由于性能问题，不会使用文档/视图。

在 MFC 和 Qt 中，对于在单独线程中更新的 UI 组件/窗口需要进行哪些具体考虑？是否有适用于所有 GUI 库的通用规则？

【问题讨论】：

您真的认为文档/视图会增加不可接受的开销吗？如今，大多数交易 GUI 都是用 .Net 编写的。即使在 2000 年，我也参与了基于 Web 的交易系统，当该系统在交易所站点上同时运行交易所提要时，延迟是难以察觉的。也就是说，我肯定会从 MFC 继续前进，但多年来我没有做过任何 C++ GUI 工作，因此无法评论这些天最好的框架是什么。我知道 Qt 受到了很多媒体的关注。
您能否告诉我们您的 GUI 的复杂程度，比如什么样的图表以及它们的数量，以及它们需要更新的频率等？
@Phil:- 我说文档/视图将是我与城市交易软件公司进行的技术面试的不可接受的开销。
@MusiGenesis：- 基本上是全方位的技术分析图表，例如烛台、移动平均线、相对强度、价格、交易量、自动支撑/阻力位。屏幕还显示实时下达的实际订单，即 2 级数据、新闻提要。就数据的屏幕/视图数量而言，大约为 30。
最大更新频率，250 ms

标签： c++ windows multithreading qt mfc

【解决方案1】：

您正在寻找完全错误的地方。文档/视图架构的“开销”在纳秒范围内（基本上，通过指针访问数据）。

作为比较，您可以有意义地更新屏幕的绝对最大速率是显示器的刷新率，通常为 60 Hz（即每 16.67 毫秒一次）。

为了使这种刷新率有意义，您不能在任何给定的显示器更新中真正改变太多 - 如果您尝试改变太多，用户将无法关注正在发生的事情。

就线程而言，到目前为止，最简单的方法是在一个线程中完成所有实际的窗口更新，并使用其他线程进行计算并为正在更新的窗口生成数据。只要您确保线程不需要进行大量计算等，尽可能快地更新窗口就很容易了。

编辑：就 C++ 与 C# 而言，这取决于。我毫不怀疑您可以从任何一个中获得完全足够的 display 性能。真正的问题是你在这些显示器后面做了多少计算。您提到的主要显示非常接近原始数据（价格、数量等）。为此，C# 可能会很好。我的猜测是，与您交谈过的人所做的计算比这要多得多——这就是 .NET（或几乎在 VM 上运行的几乎任何其他东西）的真正致命弱点。就我所见，对于真正繁重的计算，C# 等并不是很有竞争力。

例如，在不久前的另一个答案中，我提到了一个我最初用 C++ 编写的应用程序，另一个团队用 C# 重写了它，它的运行速度慢了大约 3 倍。自从发布那篇文章后，我很好奇并与他们进行了更多讨论，询问他们是否不能通过一些额外的工作将其速度提高到至少接近 C++ 的速度。

他们的回答本质上是他们已经做了额外的工作，而且不只是“一点点”。 C# 重写花了大约 3 1/2-4 个月。其中，他们用了不到一个月的时间就复制了原作的特征；剩下的全部时间都花在（试图）让它足够快可用。

我赶紧提醒一下，1) 这只是一个数据点，2) 我不知道它与您可能做的任何事情有多接近。尽管如此，它确实提供了一些关于当（以及如果）您开始进行真正的计算而不是仅仅将数据从网络传递到屏幕时可能会遇到的减速的想法。同时，快速浏览表明它与Computer Language Shootout 网站上的结果大体一致——尽管请记住结果是针对 Mono 而不是 Microsoft 的实现。

至少对我来说，真正的问题归结为：您对性能的关注是否真的有根据？对于周围 90% 的应用程序而言，重要的是代码能够按照您的意愿进行操作，并且执行速度无关紧要，只要它不会变得剧烈慢（例如，慢数百或数千倍）。如果您的代码属于该（大）类别，C# 很可能是一个不错的选择。如果您确实有充分的理由担心执行速度，那么在我看来选择 C# 将是一个很多更值得怀疑的问题。

【讨论】：

对于这种类型的应用程序，您认为在延迟方面选择 c++ 而不是 c#.net 有什么好的理由吗？我知道我给出的指标非常模糊。出于延迟的原因，伦敦的金融发展圈似乎确实倾向于选择 C++。也许这真的是因为无法证明用 c#.net 重写是合理的。
shootout.alioth.debian.org/demo/…

【解决方案2】：

我从事过交易应用程序的 GUI 方面的工作。基本上，任何本地（即非 Web）都足够快。 C++、C# 或 Java 都可以。使用 C++ 的主要缺点是它消除了计算代码和 UI 之间的天然屏障。我之前的程序员有点马虎，用的是C++，所以计算代码和UI有些交织。这使得 Qt 移植更加困难。

多线程大多与 UI 无关。不过，它应该在自己的线程上运行，这意味着只有计算引擎的接口需要考虑在其他线程上被调用的可能性。

【讨论】：

喜欢你关于强制分离表示层和数据/计算层的观点。

【解决方案3】：

由于您在评论中提到选择 C++ 或 C# 的问题，我将推荐 C#，尤其是 WPF（Windows Presentation Foundation）。从理论上讲，C++ 应用程序比 .Net 应用程序具有更高的性能上限，因为它不需要处理 .Net 框架开销。但它也需要更长的时间来开发（可能）并且更容易出现错误和内存泄漏。

如果您要编写自己的显示控件，WPF（甚至 WinForms）的速度足以处理这种控件负载（如果像使用任何语言/平台一样，它编写正确）。此外，还有大量可用的自定义控件可以执行此类操作（显示股票图表等），这将使构建此应用程序的速度比从头开始自己做所有事情要快得多。

【讨论】：

我同意所有选择 .net 和相关技术的充分理由。为什么你认为伦敦金融城仍然坚持使用 c++ 来开发这些类型的应用程序？我的印象是，这是 C++ 在 Gui 应用程序中首选的少数利基领域之一。
TBH 我曾在伦敦的几家投资银行工作过，似乎到处都在使用 C# 作为 GUI 和 C++ 作为计算。库（以及用于桥接的 COM 或 C++/CLI）。很长一段时间以来，我都没有看到任何 MFC GUI 代码，除了一些无论如何都即将淘汰的古老遗留系统。
很高兴知道。可能只是邀请我面试的公司是那些对我很久以前做的 MFC 感兴趣的遗留系统的公司。也许我应该从简历中删除它。
@Raf：“伦敦金融城”对编程一窍不通，事实上，为伦敦金融城工作的程序员通过使用平台/语言来利用自己的优势这有利于他们自己的工作保障，但却牺牲了他们的雇主。 C++ （通常）非常快，但现在其他所有东西（甚至 Java 和 except RoR）也是如此。我认为开发时间的成本大大超过了软件中的其他一切。如果我真的为要编写的软件付费，C++ 是我最不想使用的东西。
好吧，这有点极端。当然，C++ 有它的位置。我只是不能 100% 确定就是这样。