boost 与 ACE C++ 跨平台性能比较？
我参与了一个项目，将一些通信、解析、数据处理功能从 Win32 移植到 Linux，并且两者都将得到支持。 问题域对吞吐量和性能非常敏感。
我对 boost 和 ACE 的性能特征知之甚少。 具体来说，我们想了解哪个库提供了最佳的线程性能。
任何人都可以提供一些有关两者之间相对性能的数据（记录的数据、口碑数据或一些链接）吗？
编辑
谢谢大家。 证实了我们最初的想法——我们很可能会选择 boost 来实现系统级跨平台的东西。
I am involved in a venture that will port some communications, parsing, data handling functionality from Win32 to Linux and both will be supported. The problem domain is very sensitive to throughput and performance.
I have very little experience with performance characteristics of boost and ACE. Specifically we want to understand which library provides the best performance for threading.
Can anyone provide some data -- documented or word-of-mouth or perhaps some links -- about the relative performance between the two?
EDIT
Thanks all. Confirmed our initial thoughts - we'll most likely choose boost for system level cross-platform stuff.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
与使用本机操作系统线程设施相比，这两个库实际上都不应该有任何开销。 您应该看看哪个 API 更干净。 在我看来，boost 线程 API 更容易使用。
ACE倾向于更“经典的OO”，而boost则倾向于借鉴C++标准库的设计。 例如，在 ACE 中启动线程需要创建一个从 ACE_Task 派生的新类，并覆盖线程运行时调用的虚拟 svc() 函数。 在 boost 中，您创建一个线程并运行您想要的任何函数，这明显减少了侵入性。
Neither library should really have any overhead compared to using native OS threading facilities. You should be looking at which API is cleaner. In my opinion the boost thread API is significantly easier to use.
ACE tends to be more "classic OO", while boost tends to draw from the design of the C++ standard library. For example, launching a thread in ACE requires creating a new class derived from ACE_Task, and overriding the virtual svc() function which is called when your thread runs. In boost, you create a thread and run whatever function you want, which is significantly less invasive.
帮自己一个忙，远离 ACE。 如果你问我的话，这是一个非常非常糟糕的库，根本不应该被编写。 我已经工作了（或者更确切地说是不得不使用它）三年了，我告诉你这是一个设计糟糕、文档糟糕、实现糟糕的垃圾，使用古老的 C++ 并建立在完全脑死亡的设计决策之上......调用 ACE “带类的 C”实际上是在帮它一个忙。 如果您研究其某些构造的内部实现，您通常会很难抑制呕吐反射。
另外，我对“糟糕的文档”方面的强调再怎么强调也不为过。 通常，ACE 记录函数的概念包括简单地打印函数的签名。 至于它的参数的含义、它的返回值和它的一般行为，你通常需要自己弄清楚。 我厌倦了必须猜测函数可能抛出哪些异常，哪个返回值表示成功，我必须传递哪些参数才能使函数执行我需要它执行的操作，或者函数/类是否是线程安全的或不。
另一方面，Boost 使用起来很简单，是现代 C++，文档非常齐全，而且很有效！ Boost 是必经之路，用 ACE 打倒！
Do yourself a favor and steer clear of ACE. It's a horrible, horrible library that should never have been written, if you ask me. I've worked (or rather HAD to work with it) for 3 years and I tell you it's a poorly designed, poorly documented, poorly implemented piece of junk using archaic C++ and built on completely brain-dead design decisions ... calling ACE "C with classes" is actually doing it a favor. If you look into the internal implementations of some of its constructs you'll often have a hard time suppressing your gag reflex.
Also, I can't stress the "poor documentation" aspect enough. Usually, ACE's notion of documenting a function consists of simply printing the function's signature. As to the meaning of its arguments, its return value and its general behavior, well you're usually left to figure that out on your own. I'm sick and tired of having to guess which exceptions a function may throw, which return value denotes success, which arguments I have to pass to make the function do what I need it to do or whether a function / class is thread-safe or not.
Boost on the other hand, is simple to use, modern C++, extremely well documented, and it just WORKS! Boost is the way to go, down with ACE!
不必担心操作系统抽象层在线程和同步对象上的开销。 线程开销实际上根本不重要（因为它仅适用于线程创建，与 pimpl 化指针间接的开销相比，线程创建已经非常慢）。 如果您发现互斥操作正在减慢您的速度，那么您最好查看原子操作或重新安排数据访问模式以避免争用。
关于 boost 与 ACE，这是“新式”与“旧式”编程的问题。 Boost 有很多基于标头的基于模板的恶作剧（如果你能欣赏的话，使用它们会很漂亮）。 另一方面，如果您习惯了 C++ 的“带有类的 C”风格，那么 ACE 会感觉更自然。 我相信这主要取决于您团队的个人品味。
Don't worry about the overhead of an OS-abstraction layer on threading and synchronization objects. Threading overhead literally doesn't matter at all (since it only applies to thread creation, which is already enormously slow compared to the overhead of a pimpl-ized pointer indirection). If you find that mutex ops are slowing you down, you're better off looking at atomic operations or rearranging your data access patterns to avoid contention.
Regarding boost vs. ACE, it's a matter of "new-style" vs. "old-style" programming. Boost has a lot of header-only template-based shenanigans (that are beautiful to work with, if you can appreciate it). If, on the other hand, you're used to "C with classes" style of C++, ACE will feel much more natural. I believe it's mostly a matter of personal taste for your team.
我已将 ACE 用于许多重型生产服务器。 它从来没有让我失望过。 它坚如磐石，可以正常工作多年。 尝试学习BOOST的ASIO网络框架-无法掌握它。 虽然 BOOST 是更“现代”的 C++，但它也更难用于重要的任务 - 并且如果没有“现代”C++ 经验和深厚的 STL 知识，就很难正确使用
I've used ACE for numerous heavy duty production servers. It never failed me. It is rock solid and do the work for many years now. Tried to learn BOOST's ASIO network framework-Couldn't get the hang of it. While BOOST is more "modern" C++, it also harder to use for non trivial tasks - and without a "modern" C++ experience and deep STL knowledge it is difficult to use correctly
即使 ACE 是一种老式的 C++，它仍然具有 boost 尚未提供的许多面向线程的功能。
目前我认为没有理由不使用两者（但出于不同的目的）。 一旦 boost 提供了一种简单的方法来实现任务之间的消息队列，我可能会考虑放弃 ACE。
Even if ACE is a kind of old school C++, it still has many thread oriented features that boost doesn't provide yet.
At the moment I see no reason to not use both (but for different purposes). Once boost provide a simple mean to implement message queues between tasks, I may consider abandoning ACE.
就易用性而言，boost 比 ACE 好得多。 boost-asio 具有更透明的 API，其抽象更简单，可以轻松地为您的应用程序提供构建块。 在 boost 中明智地使用编译时多态性来警告/防止非法代码。 另一方面，ACE 对模板的使用仅限于泛化，并且几乎没有以用户为中心，足以禁止非法操作。 您更有可能在运行时发现 ACE 的问题。
我能想到的一个简单的例子是 ACE_Reactor - 一个相当可扩展和解耦的接口 - 但如果您在与创建它的线程不同的线程中运行其事件循环，则必须记住调用它的“自己的”函数。 我第一次花了几个小时才弄清楚这个问题，很容易就花了几天的时间。 具有讽刺意味的是，它的对象模型显示的细节比它隐藏的更多——有利于学习，但不利于抽象。
https://groups.google.com/论坛/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA
When it comes to ease-of-use, boost is way better than ACE. boost-asio has a more transparent API, its abstractions are simpler and can easily provide building blocks to your application. The compile-time polymorphism is judiciously used in boost to warn/prevent illegal code. ACE's uses of templates, on the other hand, is limited to generalization and is hardly ever user-centric enough to disallow illegal operations. You're more likely to discover problems at run-time with ACE.
A simple example which I can think of is ACE_Reactor - a fairly scalable and decoupled interface- but you must remember to call its "own" function if you're running its event loop in a thread different from where it was created. I spent hours to figure this out for the first time and could've easily spent days. Ironically enough its object model shows more details than it hides - good for learning but bad for abstraction.
https://groups.google.com/forum/?fromgroups=#!topic/comp.soft-sys.ace/QvXE7391XKA
线程实际上只是 boost 和 ACE 提供的一小部分，而且两者总体上并不具有可比性。 我同意 boost 更容易使用，因为 ACE 是一个相当重的框架。
Threading is really only a small part of what boost and ACE provide, and the two aren't really comparable overall. I agree that boost is easier to use, as ACE is a pretty heavy framework.
我不会将 ACE 称为“带有类的 C”。 ACE 并不直观，但如果您花时间按预期使用该框架，您将不会后悔。
据我所知，在阅读 Boost 的文档后，我想使用 ACE 的框架和 Boost 的容器类。
I wouldn't call ACE "C with classes." ACE is not intuitive, but if you take your time and use the framework as intended, you will not regret it.
From what I can tell, after reading Boost's docs, I'd want to use ACE's framework and Boost's container classes.
配合使用ACE和boost。 ACE 具有更好的通信 API，基于 OO 设计模式，而 boost 具有类似“现代 C++”的设计，并且可以与容器等配合良好。
Use ACE and boost cooperatively. ACE has better communication API, based on OO design patterns, whereas boost has like "modern C++" design and works well with containers for example.
我们开始使用 ACE，相信它会隐藏 TCP 套接字和 select 调用中 windows 和 unix 之间存在的平台差异。 事实证明，事实并非如此。 Ace 采用的 select（反应器模式）无法在 Windows 上混合套接字和 stdin，并且平台之间有关套接字可写性通知的语义差异仍然存在于 ACE 级别。
当我们意识到这一点时，我们已经在使用 ACE 的线程和进程功能（后者再次没有将平台差异隐藏到我们希望的程度），因此我们的代码现在绑定到一个巨大的库，该库实际上阻止我们的代码移植到 64 位 MinGW！
我迫不及待地等待代码中最后一次 ACE 用法最终被不同的东西替换的那一天。
We started to use ACE believing that it would hide the platform differences present between windows and unix in TCP sockets and the select call. Turns out, it does not. Ace's take on select, the reactor pattern, cannot mix sockets and stdin on windows, and the semantic differences between the platforms concerning socket writablility notifications are still present at the ACE level.
By the time we realized this we were already using the thread and process features of ACE (the latter of which again does not hide the platform differences to the extent we would have liked) so that our code is now tied to a huge library that actually prevents the porting of our code to 64 Bit MinGW!
I can't wait for the day when the last ACE usage in our code is finally replaced with something different.
我已经使用 ACE 多年 (8)，但我刚刚开始研究在我的下一个项目中再次使用 boost。 我正在考虑 boost，因为它有一个更大的工具包（正则表达式等），并且它的一部分正在被吸收到 C++ 标准中，所以长期维护应该更容易。
也就是说，提升将需要一些调整。 尽管 Greg 提到线程支持的侵入性较小，因为它可以运行任何（C 或静态）函数，但如果您习惯使用更类似于 Java 和 C# 线程类（即 ACE_Task 提供的线程类），那么您可以使用一点技巧来获得与提升相同的效果。
I've been using ACE for many years (8) but I have just started investigating the use of boost again for my next project. I'm considering boost because it has a bigger tool bag (regex, etc) and parts of it are getting absorbed into the C++ standard so long term maintenance should be easier.
That said, boost is going to require some adjustment. Although Greg mentions that the thread support is less invasive as it can run any (C or static) function, if you're used to using thread classes that are more akin to the Java and C# thread classes which is what ACE_Task provides, you have to use a little finesse to get the same with boost.