views:

5675

answers:

9

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.

+15  A: 

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
Nice Comparison.
Hassan Syed
About starting threads, thats simply not truth.Have a look at: int ACE_Thread_Manager::spawn (ACE_THR_FUNC func, void *arg = 0,...);
AlexKR
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
+1  A: 

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.

+7  A: 

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
+1  A: 

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.

+3  A: 

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
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
+4  A: 

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
Yes, for message queueing it is a great framework. We don't need that communications part though. Just the threading.
Tim
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
message queue is already supported in boost: http://www.boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/message_queue.html
rjoshi
Interprocess queues sound a bit expensive. ACE message queues are meant to communicate within a same process.
Luc Hermitte
A: 

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.

+4  A: 

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
I wholeheartedly agree. ACE just works.
Tim
A: 

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_a