boost vs ACE C++ 跨平台性能比较？答案

【问题标题】：boost vs ACE C++ cross platform performance comparison?boost vs ACE C++ 跨平台性能比较？
【发布时间】：2009-01-23 22:18:18
【问题描述】：

我参与了一项将一些通信、解析、数据处理功能从 Win32 移植到 Linux 的项目，并且两者都将得到支持。问题域对吞吐量和性能非常敏感。

我对 boost 和 ACE 的性能特征几乎没有经验。具体来说，我们想了解哪个库为线程提供了最佳性能。

谁能提供一些关于两者之间的相对表现的数据——记录在案的、口耳相传的或者可能是一些链接？

编辑

谢谢大家。确认了我们最初的想法——我们很可能会为系统级跨平台的东西选择 boost。

【问题讨论】：

标签： c++ performance boost cross-platform ace-tao

【解决方案1】：

与使用本机操作系统线程工具相比，这两个库都不应该有任何开销。你应该看看哪个 API 更干净。在我看来，boost 线程 API 更容易使用。

ACE 倾向于更“经典的 OO”，而 boost 则倾向于借鉴 C++ 标准库的设计。例如，在 ACE 中启动一个线程需要创建一个从 ACE_Task 派生的新类，并覆盖线程运行时调用的虚拟 svc() 函数。在 boost 中，您创建一个线程并运行您想要的任何功能，这大大减少了侵入性。

【讨论】：

关于启动线程，这根本不是事实。看看： int ACE_Thread_Manager::spawn (ACE_THR_FUNC func, void *arg = 0,...);
没错，我没有使用过那个特定的功能，但即便如此 - 它仍然需要像 void *foo(void*); 这样的函数签名（即 pthreads-esque），所以你必须自己做参数绑定和包装以返回一个 void 指针。
优秀的点，我还添加了 ACE 类和宏使用的疯狂大写，给代码库添加了恶臭。简而言之，ACE 在 10 到 15 年前还不错，今天简直就是垃圾。

【解决方案2】：

帮自己一个忙，避开 ACE。如果你问我，这是一个不应该写的可怕的、可怕的图书馆。我已经工作（或者更确切地说是不得不使用它）3 年了，我告诉你它是一个设计糟糕、文档记录不充分、实现不善的垃圾，使用过时的 C++ 并建立在完全脑死亡的设计决策之上......调用 ACE “C with classes”实际上是在帮它一个忙。如果您查看它的某些构造的内部实现，您通常很难抑制您的呕吐反射。此外，我不能足够强调“糟糕的文档”方面。通常，ACE 记录函数的概念包括简单地打印函数的签名。至于它的参数的含义、它的返回值和它的一般行为，你通常需要自己弄清楚。我厌倦了不得不猜测函数可能抛出哪些异常，哪个返回值表示成功，我必须传递哪些参数才能使函数执行我需要它执行的操作，或者函数/类是否是线程安全的与否。

另一方面，Boost 使用简单，现代 C++，文档非常完善，而且可以正常工作！ Boost 是要走的路，而 ACE！

【讨论】：

谢谢 - 我们甚至在你热情洋溢的言论之前就开始努力了
虽然我不了解 ACE，但我不得不说 Boost 文档非常受欢迎，具体取决于您使用的 Boost 模块。有些很棒，有些很糟糕。

【解决方案3】：

不必担心操作系统抽象层在线程和同步对象上的开销。线程开销实际上根本不重要（因为它只适用于线程创建，与 pimpl 化指针间接的开销相比，这已经非常慢了）。如果您发现互斥操作让您放慢了速度，您最好查看原子操作或重新安排您的数据访问模式以避免争用。

关于 boost 与 ACE，这是“新式”与“旧式”编程的问题。 Boost 有很多仅基于标头的模板的恶作剧（如果您能欣赏的话，使用起来很漂亮）。另一方面，如果您习惯于“C with classes”风格的 C++，ACE 会感觉自然得多。我相信这主要是您团队的个人喜好问题。

【讨论】：

【解决方案4】：

我已将 ACE 用于许多重型生产服务器。它从来没有让我失望过。它坚如磐石，现在已经工作了很多年。尝试学习了BOOST的ASIO网络框架——学不来。虽然 BOOST 是更“现代”的 C++，但它也更难用于不平凡的任务 - 如果没有“现代”C++ 经验和深厚的 STL 知识，则很难正确使用

【讨论】：

【解决方案5】：

即使 ACE 是一种老式的 C++，它仍然有许多 boost 还没有提供的面向线程的特性。

目前我认为没有理由不同时使用两者（但用于不同的目的）。一旦 boost 提供了一种简单的方法来实现任务之间的消息队列，我可能会考虑放弃 ACE。

【讨论】：

是的，对于消息队列来说，它是一个很棒的框架。不过，我们不需要那个通信部分。只是线程。
你总是可以创建一个具有唯一名称的 boost::interprocess::message_queue，并且只在你的进程中使用它。您可以使用 create_only_t 构造函数来确保此名称未被其他进程使用，然后只需附加 1、2、3 等，直到成功。不幸的是，它们不支持匿名 message_queue（与 posix...相同）。由于使用信号量 + 互斥锁很容易实现进程本地队列，因此您没有理由不自己动手。
boost 中已经支持消息队列：boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/…
进程间队列听起来有点贵。 ACE 消息队列旨在在同一个进程中进行通信。

【解决方案6】：

在易用性方面，boost 比 ACE 要好得多。 boost-asio 有一个更透明的 API，它的抽象更简单，可以很容易地为你的应用程序提供构建块。编译时多态性被明智地用于 boost 以警告/防止非法代码。另一方面，ACE 对模板的使用仅限于泛化，并且几乎没有以用户为中心来禁止非法操作。您更有可能在 ACE 运行时发现问题。

我能想到的一个简单示例是 ACE_Reactor - 一个相当可扩展且解耦的接口 - 但如果您在与创建它的线程不同的线程中运行它的事件循环，则必须记住调用它的“自己的”函数。我第一次花了几个小时来解决这个问题，而且很容易花几天时间。具有讽刺意味的是，它的对象模型显示的细节多于隐藏的细节 - 有利于学习，但不利于抽象。

https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA

【讨论】：

【解决方案7】：

线程实际上只是 boost 和 ACE 提供的一小部分，两者总体上并没有真正的可比性。我同意 boost 更容易使用，因为 ACE 是一个相当沉重的框架。

【讨论】：

【解决方案8】：

我不会将 ACE 称为“C with classes”。 ACE 并不直观，但如果您花时间按预期使用该框架，您将不会后悔。

据我所知，在阅读了 Boost 的文档后，我想使用 ACE 的框架和 Boost 的容器类。

【讨论】：

【解决方案9】：

使用 ACE 并合作提升。 ACE 具有更好的通信 API，基于 OO 设计模式，而 boost 具有类似“现代 C++”的设计，并且可以很好地与容器配合使用。

【讨论】：

【解决方案10】：

我们开始使用 ACE，相信它会隐藏 TCP 套接字和 select 调用中 windows 和 unix 之间存在的平台差异。事实证明，事实并非如此。 Ace 的 select，reactor 模式，不能在 windows 上混合套接字和标准输入，并且平台之间关于套接字可写通知的语义差异仍然存在于 ACE 级别。

当我们意识到这一点时，我们已经在使用 ACE 的线程和进程特性（后者并没有像我们希望的那样隐藏平台差异），因此我们的代码现在与一个巨大的实际上阻止将我们的代码移植到 64 位 MinGW 的库！

我等不及代码中最后一次使用 ACE 的那一天终于被不同的东西取代了。

【讨论】：

ACE 的最新版本确实支持 32 位和 64 位 Windows 的 MinGW64 没有问题。与标准输入相关的是，reactor 上有一个特殊的方法可以注册一个事件处理程序，该方法可以在 Windows 和所有其他平台上运行。

【解决方案11】：

我已经使用 ACE 很多年了 (8)，但我刚刚开始研究在我的下一个项目中再次使用 boost。我正在考虑提升，因为它有一个更大的工具包（正则表达式等），并且它的一部分正在被 C++ 标准所吸收，因此长期维护应该更容易。也就是说，提升将需要一些调整。尽管 Greg 提到线程支持的侵入性较小，因为它可以运行任何（C 或静态）函数，但如果您习惯使用更类似于 ACE_Task 提供的 Java 和 C# 线程类的线程类，您有使用一点技巧来获得与 boost 相同的效果。

【讨论】：