Comment se compare les bibliothèques de fil de boost contre les bibliothèques Java.Util.ContCurrent?
performance est critique et préférerais donc rester avec C ++ (bien que Java soit beaucoup plus rapide de nos jours). Étant donné que je dois coder en C ++, quelles bibliothèques existent pour rendre le filetage facile et moins sujet aux erreurs.
J'ai entendu récemment qu'à partir de JDK 1.5, le modèle de mémoire Java a été modifié pour résoudre certains problèmes de concurrence. Que diriez-vous de C ++? La dernière fois que je faisais la programmation multithread en C ++ était il y a 3 à 4 ans lorsque j'ai utilisé Pthreads. Bien que je ne souhaite plus utiliser cela pour un grand projet. La seule autre alternative que je connaisse est de booster les fils. Cependant, je ne suis pas sûr que si c'est bon. J'ai entendu de bonnes choses à propos de Java.Util.ConCurrent, mais rien encore sur les fils de boost.
6 Réponses :
Si vous ciblez une plate-forme spécifique, l'appel direct du système d'exploitation sera probablement un peu plus rapide que d'utiliser Boost pour C ++. J'aurais tendance à utiliser Ace, car vous pouvez généralement faire les bons appels à votre plate-forme principale et il sera toujours indépendant de la plate-forme. Java devrait avoir à peu près la même vitesse tant que vous pouvez vous garantir qu'il fonctionnera sur une version récente.
Boost.thread est plus rapide que l'ACE pour la seule raison qui stimule les modèles. Boost et Ace utilisent à la fois les mêmes appels de système d'exploitation. Le code compilé de Boost est toutefois très près de ce que vous écririez à l'aide de Pthreads natifs. Tandis que ACE doit ramper à travers des couches d'abstraction avant qu'il ne touche des primitives d'OS natifs. Java aurait un problème similaire, mais le JVM est capable de supprimer la plupart (tous?) Des coûts d'abstraction.
N'oubliez pas que l'ACE se concentre sur la communication croisée de la plateforme et ajoute beaucoup d'abstractions de niveau supérieur comme le cadre du réacteur / proacteur. Donc, à partir de ce point de vue, il peut être préféré plus de booster.
Les fils de boost sont beaucoup plus faciles à utiliser que Pthreads et, à mon avis, légèrement plus faciles à utiliser que les fils Java. Lorsqu'un objet de thread de boost est instancié, il lance un nouveau fil. L'utilisateur fournit une fonction ou un objet fonction qui fonctionnera dans ce nouveau fil.
C'est vraiment aussi simple que: Vous pouvez facilement passer des données sur le thread en stockant des valeurs à l'intérieur de l'objet de fonction. Et dans la dernière version de Boost, vous pouvez transmettre un nombre variable d'arguments sur le constructeur de fil lui-même, qui sera ensuite transmis à l'opérateur vous Peut également utiliser des verrous de style Raii avec Notez que c ++ 0x utilisera la même syntaxe pour () boost :: mutex pour la synchronisation. std :: thread .
IMHO Le but des bibliothèques de la concurrence Java est de faciliter la multi-threading que les threads Java Plan (qui sont basés sur Pthreads)
@Peterlawrey qu'est-ce qui ne va pas avec Pthreads? À moins que vous parliez de collections simultanées à Java, alors oui, ceux-ci sont impossibles dans Pthreads.
@Igorganapolsky rien de mal avec Pthreads. Je faisais le point que la comparaison des fils Java n'est pas la même chose que celle de la comparaison avec Java.UtilL.ConCurrent ajoutée en 2006 et ils sont beaucoup plus faciles. L'API Parallelstream () est beaucoup plus facile à nouveau.
performance sage, je ne vous inquiéterais pas vraiment. C'est mon intestin, un expert Boost / C ++ pouvait écrire un code plus rapide qu'un expert Java. Mais tous les avantages devraient être combattus.
Je préfère les paradigmes design de boost à Java. Java est tout le chemin, où Boost / C ++ permet à OO si vous le souhaitez, mais utilise le paradigme le plus utile pour le problème à la main. En particulier, j'adore Raii lorsqu'il s'agit de serrures. Java gère une gestion de la mémoire magnifiquement, mais parfois, il se sent parfois comme le reste des ressources des programmeurs reçoivent la tige: poignées de fichier, mutiles, dB, sockets, etc.
La bibliothèque simultanée de Java est plus étendue que celle de Boost. FLOW Pools, conteneurs simultanés, atomes, etc. Mais les primitives de base sont à l'autre, les fils, les mutiles, les variables de condition.
Alors pour la performance, je dirais que c'est un lavage. Si vous avez besoin de beaucoup de bibliothèque simultanée de haut niveau Support Java WINS. Si vous préférez le paradigme Freedom C ++.
java.util.concurrent et Boost threads Library avoir une fonctionnalité qui se chevauchent, mais java.util.concurrent fournit également une) abstraction de niveau supérieur et b) également des fonctions de niveau inférieures.
Les fils de boost fournissent:
Java.Util.ConCurrent a aussi:
Un côté Note: C ++ n'a actuellement aucun modèle de mémoire. Sur une machine différente, la même application C ++ peut avoir à gérer un modèle de mémoire différent. Cela rend la programmation portable et simultanée en C ++ encore plus délicate.
.
en C ++ on peut utiliser directement Pthreads (pthread_create (), etc.) si on le voulait. Java interne utilise Pthreads via son environnement d'exécution. Faire "LDD" à voir.
Si la performance est un problème dans votre programme multithreadé, vous devez envisager une conception sans verrouillage.
Les threads de moyens de verrouillage ne sont pas en concurrence pour une ressource partagée et minimisent les coûts de commutation. Dans ce département, Java a une meilleure histoire IMHO, avec ses collections simultanées. Vous pouvez rapidement proposer une solution sans verrouillage.
Pour avoir utilisé le fil de boost liber un peu (mais pas beaucoup), je peux dire que votre réflexion sera influencée par ce qui est disponible, et cela signifie essentiellement une solution de verrouillage.
Écrire une solution C ++ sans verrouille est très difficile, car le manque de support de bibliothèque et de conceptuellement, il manque un modèle de mémoire qui garantit que vous pouvez écrire des objets vraiment immuables.
Ce livre est un doit lire: Java Concurrence dans la pratique
Martin, je pense que cela signifie "Java est beaucoup plus rapide qu'auparavant."
Dans mon expérience, tout le temps dit que "la performance est critique" sans détails, ce n'est pas vraiment essentiel du tout. Ne choisissez pas le choix C ++ ou Java pour des raisons de performance, choisissez C ++ ou Java, car vous vous familiarisez plus facilement ou vous trouvez plus facile à programmer.