2009-01-23 7 views
20

Ich bin an einem Projekt beteiligt, das einige Kommunikations-, Analyse- und Datenverarbeitungsfunktionen von Win32 nach Linux portiert. Beide werden unterstützt. Die Problemdomäne ist sehr empfindlich gegenüber Durchsatz und Leistung.Boost vs ACE C++ Cross-Plattform-Performance-Vergleich?

Ich habe sehr wenig Erfahrung mit Leistungsmerkmalen von Boost und ACE. Insbesondere möchten wir verstehen, welche Bibliothek die beste Leistung für das Threading bietet.

Kann jemand irgendwelche Daten - dokumentiert oder Mundpropaganda oder vielleicht einige Verbindungen - über die relative Leistung zwischen den zwei zur Verfügung stellen?

BEARBEITEN

Vielen Dank. Bestätigte unsere anfänglichen Gedanken - wir werden wahrscheinlich Boost für plattformübergreifende Sachen auf Systemebene wählen.

Antwort

27

Keine der Bibliotheken sollte im Vergleich zur nativen OS-Threading-Funktion einen Overhead haben. Sie sollten sich ansehen, welche API sauberer ist. Meiner Meinung nach ist die Boost-Thread-API wesentlich einfacher zu benutzen.

ACE neigt dazu, "klassischer OO" zu sein, während Boost eher vom Design der C++ - Standardbibliothek ausgeht. Wenn Sie beispielsweise einen Thread in ACE starten, müssen Sie eine neue Klasse erstellen, die von ACE_Task abgeleitet ist, und die virtuelle Funktion svc() überschreiben, die beim Ausführen des Threads aufgerufen wird. In Boost erstellen Sie einen Thread und führen die gewünschte Funktion aus, die wesentlich weniger invasiv ist.

+0

Schöner Vergleich. –

+0

Über das Starten von Threads, das ist einfach keine Wahrheit. Werfen Sie einen Blick auf: int ACE_Thread_Manager :: spawn (ACE_THR_FUNC func, void * arg = 0, ...); – alexkr

+0

Richtig, ich habe diese spezielle Funktionalität nicht benutzt, aber selbst dann - es benötigt immer noch eine Funktionssignatur wie 'void * foo (void *);' (dh. Pthreads-esque), also müsstest du deine eigenen machen Argument Binding und Wrapping um einen void pointer zurückzugeben. –

2

Threading ist wirklich nur ein kleiner Teil dessen, was Boost und ACE bieten, und die beiden sind insgesamt nicht wirklich vergleichbar. Ich stimme zu, dass Boost einfacher zu verwenden ist, da ACE ein ziemlich schwerer Rahmen ist.

8

Machen Sie sich keine Sorgen über den Overhead einer OS-Abstraktionsschicht in Threading- und Synchronisationsobjekten. Threading-Overhead spielt buchstäblich keine Rolle (da es nur für die Thread-Erstellung gilt, die im Vergleich zum Overhead einer pimplizierten Zeiger-Indirektion bereits enorm langsam ist). Wenn Sie feststellen, dass Mutex-Ops Sie verlangsamen, sollten Sie sich besser atomare Operationen ansehen oder Ihre Datenzugriffsmuster neu anordnen, um Konflikte zu vermeiden.

In Bezug auf Boost vs. ACE, ist es eine Frage von "New-Style" vs. "Old-Style" -Programmierung. Boost hat viele Header-only Template-basierte Shenanigans (mit denen man wunderbar arbeiten kann, wenn man es zu schätzen weiß). Wenn Sie andererseits an "C mit Klassen" -Stil von C++ gewöhnt sind, wird sich ACE viel natürlicher anfühlen. Ich glaube, es ist vor allem eine Frage des persönlichen Geschmacks für Ihr Team.

2

Ich würde nicht ACE "C mit Klassen." ACE ist nicht intuitiv, aber wenn Sie sich Zeit nehmen und das Framework wie beabsichtigt nutzen, werden Sie es nicht bereuen.

Von was ich sagen kann, nachdem ich Boosts Dokumente gelesen habe, würde ich ACEs Framework und Boost's Container-Klassen verwenden wollen.

20

Tun Sie sich einen Gefallen und vermeiden Sie ACE. Es ist eine schreckliche, schreckliche Bibliothek, die niemals hätte geschrieben werden sollen, wenn du mich fragst. Ich habe 3 Jahre lang gearbeitet (oder vielmehr musste ich damit arbeiten) und ich sage dir, dass es ein schlecht entworfenes, schlecht dokumentiertes, schlecht implementiertes Stück Müll ist, das archaisches C++ verwendet und auf komplett hirntoten Designentscheidungen aufbaut ... ACE anrufend "C with classes" tut es tatsächlich einen Gefallen. Wenn Sie sich die internen Implementierungen einiger seiner Konstrukte ansehen, werden Sie es oft schwer haben, Ihren Würgereflex zu unterdrücken. Auch kann ich die "schlechte Dokumentation" Aspekt nicht genug betonen. Normalerweise besteht ACEs Vorstellung, eine Funktion zu dokumentieren, darin, einfach die Signatur der Funktion zu drucken. Was die Bedeutung ihrer Argumente, ihren Rückgabewert und ihr allgemeines Verhalten anbetrifft, so ist es normalerweise üblich, das herauszufinden.Ich bin es leid, zu erraten, welche Ausnahmen eine Funktion auslösen kann, welcher Rückgabewert Erfolg bedeutet, welche Argumente ich übergeben muss, damit die Funktion das tut, was ich tun muss, oder ob eine Funktion/Klasse Thread-sicher ist oder nicht.

Boost auf der anderen Seite, ist einfach zu bedienen, moderne C++, extrem gut dokumentiert, und es funktioniert einfach! Boost ist der Weg zu gehen, runter mit ACE!

+0

Danke - wir haben schon vor Ihren leidenschaftlichen Bemerkungen mit Boost begonnen – Tim

+9

Während ich nichts über ACE weiß, muss ich sagen, dass die Boost-Dokumentation je nachdem, welches Boost-Modul Sie verwenden, sehr getroffen wird. Manche sind großartig, andere sind schrecklich. –

6

Auch wenn ACE eine Art C++ der alten Schule ist, hat es immer noch viele Thread-orientierte Funktionen, die Boost noch nicht bietet.

Im Moment sehe ich keinen Grund, beide nicht zu verwenden (aber für andere Zwecke). Sobald Boost ein einfaches Mittel zum Implementieren von Nachrichtenwarteschlangen zwischen Aufgaben bereitstellt, kann es sinnvoll sein, ACE aufzugeben.

+0

Ja, für Message Queuing ist es ein toller Rahmen. Wir brauchen diesen Kommunikationsteil jedoch nicht. Nur das Gewinde. – Tim

+0

Nun können Sie immer eine boost :: interprocess :: message_queue mit einem eindeutigen Namen erstellen und nur aus Ihrem Prozess verwenden. Sie können den create_only_t-Konstruktor verwenden, um sicherzustellen, dass dieser Name nicht von einem anderen Prozess verwendet wird, und dann einfach 1, 2, 3 usw. anhängen, bis es erfolgreich ist. Leider unterstützen sie keine anonymen Message_queues (wie Posix ...). Da eine lokale Prozesswarteschlange mit einem Semaphor + Mutex einfach zu implementieren ist, gibt es keinen Grund, warum Sie es nicht einfach selbst tun sollten. –

+0

Nachrichtenwarteschlange wird bereits in Boost unterstützt: http://www.boost.org/doc/libs/1_35_0/doc/html/boost/interprocess/message_queue.html – rjoshi

0

Ich benutze ACE seit vielen Jahren (8), aber ich habe gerade angefangen, die Verwendung von Boost für mein nächstes Projekt zu untersuchen. Ich erwäge Boost, weil es einen größeren Werkzeugtasche (Regex, etc) hat und Teile davon werden in den C++ - Standard absorbiert, so dass die langfristige Wartung einfacher sein sollte. Das heißt, Boost erfordert einige Anpassungen. Obwohl Greg erwähnt, dass die Thread-Unterstützung weniger invasiv ist, da sie jede (C- oder statische) Funktion ausführen kann, wenn Sie es gewohnt sind, Thread-Klassen zu verwenden, die den Java- und C# -Thread-Klassen ähnlicher sind, was ACE_Task bietet ein wenig Finesse zu verwenden, um das gleiche mit Boost zu bekommen.

7

Ich habe ACE für zahlreiche Heavy-Duty-Produktionsserver verwendet. Es hat mich nie im Stich gelassen. Es ist felsenfest und macht die Arbeit seit vielen Jahren. Ich habe versucht, das ASIO-Netzwerk-Framework von BOOST zu lernen - ich konnte es nicht verstehen. Während BOOST eher "modernes" C++ ist, ist es auch schwieriger für nicht-triviale Aufgaben zu verwenden - und ohne eine "moderne" C++ - Erfahrung und tiefes STL-Wissen ist es schwierig, es richtig zu benutzen

+0

Ich stimme mit ganzem Herzen zu. ACE funktioniert einfach. – Tim

1

Verwenden Sie ACE und boosten Sie kooperativ. ACE hat eine bessere Kommunikations-API, die auf OO-Entwurfsmustern basiert, während Boost wie "modernes C++" -Design wirkt und beispielsweise gut mit Containern funktioniert.

1

Wir begannen mit ACE zu glauben, dass es die Plattform Unterschiede zwischen Windows und Unix in TCP-Sockets und den Select-Call verbergen würde. Stellt sich heraus, tut es nicht. Ace's select, das reactor pattern, kann Sockets und stdin unter Windows nicht mischen, und die semantischen Unterschiede zwischen den Plattformen bezüglich der Benachrichtigungen über Socket-Schreibbarkeit sind auf der ACE-Ebene immer noch vorhanden.

Als wir das bemerkten, nutzten wir bereits die Thread - und Prozesseigenschaften von ACE (letzteres wiederum versteckt die Plattformunterschiede nicht in dem Maße, wie wir es uns gewünscht hätten), so dass unser Code jetzt an ein gebunden ist riesige Bibliothek, die die Portierung unseres Codes auf 64 Bit MinGW verhindert!

Ich kann nicht auf den Tag warten, wenn die letzte ACE-Nutzung in unserem Code schließlich durch etwas anderes ersetzt wird.

+0

Aktuelle Versionen von ACE unterstützen MinGW64 für 32bit und 64bit Windows ohne Probleme. Im Zusammenhang mit stdin gibt es eine spezielle Methode auf dem Reaktor, einen Event-Handler zu registrieren, der unter Windows und allen anderen Plattformen funktioniert. –

3

Wenn es um Benutzerfreundlichkeit geht, ist Boost viel besser als ACE. boost-asio hat eine transparentere API, seine Abstraktionen sind einfacher und können einfach Bausteine ​​für Ihre Anwendung bereitstellen. Der Kompilierzeit-Polymorphismus wird sinnvollerweise in Boost verwendet, um illegalen Code zu warnen/zu verhindern. Die Verwendung von Templates durch ACE beschränkt sich jedoch auf Verallgemeinerungen und ist selten benutzerzentriert genug, um illegale Operationen zu unterbinden. Sie sind eher in der Lage, Probleme mit ACE zur Laufzeit zu entdecken.

Ein einfaches Beispiel, das ich mir vorstellen kann, ist ACE_Reactor - eine ziemlich skalierbare und entkoppelte Schnittstelle - aber Sie müssen daran denken, seine "eigene" Funktion aufzurufen, wenn Sie seine Ereignisschleife in einem Thread anders als dort erstellt . Ich verbrachte Stunden damit, das zum ersten Mal herauszufinden und hätte leicht Tage damit verbringen können. Ironischerweise zeigt sein Objektmodell mehr Details als es verbirgt - gut zum Lernen, aber schlecht für Abstraktion.

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