boost vs ACE C ++ comparaison de performances multi-plateformes?

Question

Je suis impliqué dans une entreprise qui portera certaines fonctionnalités de communication, d'analyse, de traitement des données de Win32 à Linux et les deux seront prises en charge. Le domaine problématique est très sensible au débit et aux performances.

J'ai très peu d'expérience des caractéristiques de performance de boost et de ACE. Plus précisément, nous voulons savoir quelle bibliothèque offre les meilleures performances pour le threading.

Quelqu'un peut-il fournir des données - documentées ou de bouche à oreille ou peut-être quelques liens - sur les performances relatives entre les deux?

EDIT

Merci à tous. Nous avons confirmé nos réflexions initiales: nous choisirons probablement boost pour des éléments multiplates-formes au niveau du système.

Answer 1

Aucune des deux bibliothèques ne devrait avoir de temps système supplémentaire comparé à l’utilisation d’installations de threads OS natives. Vous devriez regarder quelle API est plus propre. À mon avis, l’API du thread boost est beaucoup plus simple à utiliser.

ACE a tendance à être plus "classique OO", tandis que boost a tendance à s’inspirer de la conception de la bibliothèque standard C ++. Par exemple, le lancement d'un thread dans ACE nécessite la création d'une nouvelle classe dérivée de ACE_Task et le remplacement de la fonction virtuelle svc () appelée lors de l'exécution de votre thread. Dans boost, vous créez un fil de discussion et exécutez la fonction de votre choix, qui est nettement moins invasive.

Answer 2

Faites-vous plaisir et évitez ACE. C'est une bibliothèque horrible, horrible qui n'aurait jamais dû être écrite, si vous me le demandez. Cela fait 3 ans que je travaille (ou plutôt que je DOIS travailler dessus) et je vous dis que c'est un morceau de bric-à-brac mal conçu, mal documenté, mal implémenté qui utilise du C ++ archaïque et qui repose sur des décisions de conception totalement mortes à mort ... appelant ACE "C avec classes" est en train de faire une faveur. Si vous examinez les implémentations internes de certaines de ses constructions, vous aurez souvent du mal à supprimer votre réflexe nauséeux. De plus, je ne saurais trop insister sur la "mauvaise documentation". aspect assez. Généralement, l'idée de documenter une fonction utilisée par ACE consiste à simplement imprimer la signature de la fonction. En ce qui concerne la signification de ses arguments, sa valeur de retour et son comportement général, il vous reste généralement à le découvrir vous-même. J'en ai assez de devoir deviner quelles exceptions une fonction peut générer, quelle valeur renvoyée indique succès, quels arguments je dois passer pour que la fonction fasse ce dont j'ai besoin ou si une fonction / classe est thread-safe ou pas.

Boost, en revanche, est simple à utiliser, en C ++ moderne, extrêmement bien documenté, et ça marche! Boost est la voie à suivre avec ACE!

Answer 3

Ne vous inquiétez pas de la surcharge d'une couche d'abstraction de système d'exploitation sur les objets de thread et de synchronisation. La surcharge de threading n'a littéralement aucune importance (puisqu'elle s'applique uniquement à la création de threads, qui est déjà extrêmement lente comparée à la surcharge d'un pointeur indéterminé pimplé). Si vous constatez que les opérations de mutex vous ralentissent, vous feriez mieux de regarder les opérations atomiques ou de réorganiser vos modèles d'accès aux données pour éviter les conflits.

En ce qui concerne boost vs ACE, il s’agit du "nouveau style" vs " old-style " la programmation. Boost a beaucoup de manigances basées sur des modèles avec en-tête (il est beau de travailler avec, si vous pouvez l'apprécier). Par contre, si vous êtes habitué à "C avec les classes" style de C ++, ACE se sentira beaucoup plus naturel. Je pense que c'est principalement une question de goût personnel pour votre équipe.

Answer 4

J'ai utilisé ACE pour de nombreux serveurs de production lourds. Cela ne m'a jamais manqué. Il est solide et fait le travail depuis de nombreuses années. J'ai essayé d'apprendre le framework de réseau ASIO de BOOST - Impossible de le comprendre. Alors que BOOST est plus "moderne" C ++, il est également plus difficile à utiliser pour des tâches non triviales - et sans un outil "moderne". Expérience en C ++ et connaissance approfondie en STL, il est difficile d’utiliser correctement

Answer 5

Même si ACE est une sorte de C ++ de la vieille école, il possède encore de nombreuses fonctionnalités orientées thread qui ne sont pas encore fournies par boost.

Pour le moment, je ne vois aucune raison de ne pas utiliser les deux (mais à des fins différentes). Une fois que boost fournit un moyen simple d’implémenter les files de messages entre les tâches, je peux envisager d’abandonner ACE.

Answer 6

En termes de facilité d'utilisation, boost est bien meilleur que ACE. boost-asio a une API plus transparente, ses abstractions sont plus simples et peuvent facilement fournir des blocs de construction à votre application. Le polymorphisme à la compilation est utilisé judicieusement dans boost pour avertir / empêcher le code illégal. Les modèles utilisés par ACE, quant à eux, se limitent à la généralisation et sont rarement suffisamment centrés sur l'utilisateur pour interdire les opérations illégales. Vous êtes plus susceptible de découvrir des problèmes lors de l'exécution avec ACE.

Un exemple simple auquel je peux penser est ACE_Reactor - une interface assez évolutive et découplée - mais vous devez vous rappeler d'appeler son "propre" fonctionne si vous exécutez sa boucle d'événements dans un thread différent de celui où il a été créé. J'ai passé des heures à comprendre cela pour la première fois et j'aurais facilement pu passer des jours. Ironiquement, son modèle objet montre plus de détails qu'il n'en cache - bon pour apprendre, mais mauvais pour l'abstraction.

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

Answer 7

Le filetage n’est vraiment qu’une petite partie de ce que boost et ACE fournissent, et les deux ne sont pas vraiment comparables dans l’ensemble. Je conviens que boost est plus facile à utiliser, car ACE est un framework assez lourd.

Answer 8

Je n’appellerais pas ACE "C avec des classes". ACE n’est pas intuitif, mais si vous prenez votre temps et utilisez le cadre comme prévu, vous ne le regretterez pas.

D'après ce que je peux dire, après avoir lu la documentation de Boost, j'aimerais utiliser le framework ACE et les classes de conteneurs de Boost.

Answer 9

Utilisez ACE et boostez en coopération. ACE dispose d'une meilleure API de communication, basée sur des modèles de conception OO, alors que boost a le style "C ++ moderne". conception et fonctionne bien avec des conteneurs par exemple.

Answer 10

Nous avons commencé à utiliser ACE en pensant qu’il masquerait les différences de plate-forme présentes entre Windows et Unix dans les sockets TCP et l’appel de sélection. Il s'avère que ce n'est pas le cas. Le point de vue de Ace sur le modèle de réacteur, ne peut pas mélanger des sockets et stdin sur des fenêtres, et les différences sémantiques entre les plates-formes concernant les notifications d'écriture des sockets sont toujours présentes au niveau ACE.

Au moment où nous avons réalisé cela, nous utilisions déjà les fonctionnalités de thread et de processus de ACE (ce dernier ne masque pas non plus les différences de plate-forme autant que nous l'aurions souhaité), de sorte que notre code est désormais lié à un énorme bibliothèque qui empêche réellement le portage de notre code vers MinGW 64 bits!

Je suis impatient de voir le jour où la dernière utilisation d'ACE dans notre code sera finalement remplacée par quelque chose de différent.

Answer 11

J'utilise ACE depuis de nombreuses années (8), mais je viens tout juste de commencer à étudier l'utilisation de boost dans le cadre de mon prochain projet. Je songe à boost car il a un sac à outils plus grand (regex, etc.) et que certaines parties sont absorbées par la norme C ++, ce qui facilite la maintenance à long terme. Cela dit, le boost nécessitera quelques ajustements. Bien que Greg mentionne que le support de thread est moins invasif car il peut exécuter n'importe quelle fonction (C ou statique), si vous êtes habitué à utiliser des classes de thread qui s'apparentent davantage aux classes de thread Java et C # fournies par ACE_Task, vous devez utiliser un peu de finesse pour obtenir le même effet avec boost.