19

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.

Tim
  • 20,184
  • 24
  • 117
  • 214

11 Answers11

27

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.

Greg Rogers
  • 35,641
  • 17
  • 67
  • 94
  • About starting threads, thats simply not truth. Have a look at: int ACE_Thread_Manager::spawn (ACE_THR_FUNC func, void *arg = 0,...); – alexkr Oct 04 '10 at 11:28
  • True, I haven't used that particular functionality, but even then - it still requires a function signature like `void *foo(void*);` (ie. pthreads-esque), so you'd have to do your own argument binding and wrapping to return a void pointer. – Greg Rogers Oct 05 '10 at 23:47
  • 7
    Excellent points, I would have also added the insane capitalization that ACE classes and macros use add a foul stench to ones code base. In short ACE was good 10-15 years ago, its nothing but rubbish today. –  Jan 02 '11 at 02:19
20

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!

  • Thanks - we were going with boost even before your passionate remarks – Tim May 08 '09 at 14:12
  • 9
    While I don't know about ACE, I have to say that the Boost documentation is very hit and miss depending on which Boost module you're using. Some are great, others are horrible. – Robert S. Barnes Jun 28 '10 at 09:07
8

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.

Tom
  • 10,689
  • 4
  • 41
  • 50
7

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

Bugspy.net
  • 71
  • 1
  • 1
6

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.

Luc Hermitte
  • 31,979
  • 7
  • 69
  • 83
  • Yes, for message queueing it is a great framework. We don't need that communications part though. Just the threading. – Tim May 08 '09 at 19:45
  • Well you can always create a boost::interprocess::message_queue with a unique name, and only use it from your process. You can use the create_only_t constructor to make sure that this name is not being used by another process, and then just append 1, 2, 3, etc until it succeeds. Unfortunately they do not support anonymous message_queue's (same as posix...). Since a process local queue is easy to implement with a semaphore + mutex, there is no reason you shouldn't just do it yourself. – Greg Rogers Mar 07 '10 at 02:02
  • message queue is already supported in boost: http://www.boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/message_queue.html – rjoshi May 04 '10 at 18:08
  • Interprocess queues sound a bit expensive. ACE message queues are meant to communicate within a same process. – Luc Hermitte May 04 '10 at 23:11
3

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

argmin
  • 77
  • 4
2

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.

2

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.

1

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.

baris.aydinoz
  • 1,902
  • 2
  • 18
  • 28
1

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.

Watnabe
  • 11
  • 1
  • Recent versions of ACE do support MinGW64 for 32bit and 64bit Windows without problems. Related to stdin, there is a special method on the reactor to register an event handler that than works on Windows and all other platforms. – Johnny Willemsen Oct 28 '13 at 12:43
0

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.