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

boost vs ACE C++ cross platform performance comparison?

提问by Tim

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.

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

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.

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

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.

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

回答by Greg Rogers

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.

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

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 倾向于更“经典的 OO”，而 boost 倾向于借鉴 C++ 标准库的设计。例如，在 ACE 中启动一个线程需要创建一个派生自 ACE_Task 的新类，并覆盖在您的线程运行时调用的虚拟 svc() 函数。在 boost 中，你创建一个线程并运行你想要的任何函数，这显着降低了侵入性。

回答by Greg Rogers

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.

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

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!

另一方面，Boost 使用简单，现代 C++，文档齐全，而且很有效！Boost 是要走的路，与 ACE 一起下降！

回答by Tom

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.

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

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.

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

回答by Bugspy.net

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 用于许多重型生产服务器。它从来没有让我失望。它坚如磐石，并且已经做了很多年的工作。尝试学习 BOOST 的 ASIO 网络框架 - 无法掌握它。虽然 BOOST 是更“现代”的 C++，但它也更难用于非平凡的任务——如果没有“现代”C++ 经验和深厚的 STL 知识，就很难正确使用

回答by Luc Hermitte

Even if ACE is a kind of old school C++, it still has many thread oriented features that boost doesn't provide yet.

即使 ACE 是一种老派的 C++，它仍然具有许多 boost 尚未提供的面向线程的特性。

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。

回答by argmin

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.

在易用性方面，boost 比 ACE 好得多。boost-asio 有一个更透明的 API，它的抽象更简单，可以轻松地为您的应用程序提供构建块。编译时多态性在 boost 中被明智地用于警告/防止非法代码。另一方面，ACE 对模板的使用仅限于泛化，并且几乎从未以用户为中心到足以禁止非法操作。您更有可能在 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.

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

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

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

回答by argmin

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.

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

From what I can tell, after reading Boost's docs, I'd want to use ACE's framework and Boost's container classes.

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

回答by argmin

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.

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

回答by baris.aydinoz

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和boost。ACE 具有更好的通信 API，基于 OO 设计模式，而 boost 具有类似“现代 C++”的设计，并且例如与容器配合良好。

回答by Watnabe

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.

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

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!

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

I can't wait for the day when the last ACE usage in our code is finally replaced with something different.

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