Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Entre C++17, Go, et Java, lequel est plus performant pour un outil de séquençage ?
Go offre le meilleur équilibre entre le temps d'exécution et l'utilisation de la mémoire, selon une étude

Le , par Bill Fassinou

55PARTAGES

5  2 
Dans la communauté bio-informatique, pour le stockage des données de séquençage cartographiées, le format d'alignement de séquence (SAM / BAM) est la norme. Pour info, le format de cartographie d'alignement de séquence, en anglais sequence alignment map (SAM), est un format d'alignement générique pour stocker les alignements de lecture par rapport aux séquences de référence, prenant en charge les lectures courtes et longues (jusqu'à 128 Mbps) produites par différentes plateformes de séquençage. Autrement dit, c'est un format texte permettant de stocker des séquences biologiques alignées sur une séquence de référence.

Il existe un grand nombre d'outils de traitement des fichiers SAM / BAM pour l'analyse. Entre autres, on peut citer elPrep, SAMtools, Picard et Genome Analysis Toolkit (GATK). BMC Bioinformatics, une revue scientifique couvrant la bio-informatique et la biologie computationnelle, a effectué une étude sur elPrep, un framework multi-thread établi pour la préparation de fichiers SAM et BAM dans des pipelines de séquençage. L'objectif est de voir parmi les langages de programmation comme Go, C++ 17 et Java, lequel est plus approprié pour la gestion de la mémoire de tas qui est une tâche complexe dans elPrep.

Pour obtenir de bonnes performances, l'architecture logicielle d'elPrep ne fait qu'un seul passage dans un fichier SAM / BAM pour plusieurs étapes de préparation et conserve le séquençage des données autant que possible dans la mémoire principale. Semblable à d'autres outils SAM / BAM, la gestion de la mémoire de tas est une tâche complexe dans elPrep, et elle est devenue un sérieux goulot d'étranglement de la productivité dans son langage d'implémentation d'origine. BMC Bioinformatics a donc «  étudié trois langages de programmation alternatifs : Go et Java en utilisant un récupérateur de mémoire parallèle d'une part, et C ++ 17 en utilisant le comptage de références d'autre part pour gérer de grandes quantités d'objets de tas ».

L'exécution d'un pipeline de préparation typique à l'aide de l'architecture logicielle d'elPrep dans les trois langages de programmation sélectionnés montre que l'implémentation Go est la plus performante, suivie de l'implémentation Java, puis de l'implémentation C ++ 17, selon BMC Bioinformatics. Pour parvenir à ce résultat, ils ont utilisé un pipeline de préparation en cinq étapes à savoir tri des lectures pour l'ordre des coordonnées, suppression des lectures non mappées, marquage des lectures en double, remplacement des groupes de lecture, réorganisation et filtrage du dictionnaire de séquences. Ce pipeline est exécuté 30 fois pour chaque implémentation et ils ont enregistré le temps écoulé et l'utilisation maximale de la mémoire pour chaque exécution à l'aide de la commande de temps Unix.


C++ 17 et Java auraient permis un réglage fin de leur gestion de la mémoire, conduisant chacun à quatre variations. Pour le classement final dans cette section, les chercheurs ont choisi le meilleur résultat de chaque ensemble de variations, une pour C++ 17 et une pour Java. Les tests de performances Go ont été exécutés avec les paramètres par défaut. Go a besoin en moyenne de 7 minutes 56,152 secondes avec un écart type de 8,571 secondes ; Java a besoin en moyenne de 6 minutes 54,546 secondes avec un écart type de 5,376 secondes ; et C ++ 17 a besoin en moyenne de 10 minutes 23,603 secondes avec un écart type de 22,914 secondes. Les intervalles de confiance pour Go et Java sont très serrés, avec un intervalle de confiance légèrement plus grande pour C ++ 17.

Les résultats de référence pour l'utilisation maximale de la mémoire sont présentés sur la figure ci-dessous. Go a besoin en moyenne de 221,73 Go avec un écart type d'environ 6,15 Go ; Java a besoin en moyenne de 335,46 Go avec un écart type d'environ 0,13 Go ; et C ++ 17 a besoin en moyenne de 255,48 Go avec un écart type d'environ 2,93 Go. Les intervalles de confiance sont très serrés.


Le but d'elPrep est de maintenir simultanément à la fois le temps d'exécution et l'utilisation de la mémoire. Pour déterminer le classement final, BMC Bioinformatics a multiplié le temps moyen écoulé de l'horloge murale en heures (h) par l'utilisation maximale moyenne de la mémoire en gigaoctets (Go), les valeurs inférieures en gigaoctets heures (GBh) étant meilleures. Cela donne les valeurs suivantes : 29,33 Goh pour Go, 38,63 Goh pour Java et 44,26 Goh pour C ++ 17.


Par conséquent, BMC Bioinformatics conclut que l'implémentation Go est la plus performante, offrant le meilleur équilibre entre les performances d'exécution et l'utilisation de la mémoire. Alors que les benchmarks Java signalent un temps d'exécution un peu plus rapide que les benchmarks Go, l'utilisation de la mémoire des runs Java est nettement plus élevée. Les benchmarks C++ 17 s'exécutent beaucoup plus lentement que Go et Java, tout en utilisant un peu plus de mémoire que les exécutions Go. « Sur la base de nos résultats de référence, nous avons choisi Go comme nouveau langage d'implémentation pour elPrep, et nous recommandons de considérer Go comme un bon candidat pour développer d'autres outils bio-informatiques pour le traitement des données SAM / BAM ».

Toutefois, les internautes remettent en question la méthode et la manière dont BMC Bioinformatics a codé le pipeline dans chaque langage, surtout le code du C++ 17. Le code C++ serait écrit comme s'il n'y avait pas de type statique. Il semblerait que BMC Bioinformatics ait fidèlement porté la nature très dynamique de leur code existant en C++. C'est ce qui aurait affecté la performance du C++ 17. En parlant de structure de données, BMC Bioinformatics aurait utilisé également std::unordered_map <int, any>. Or, le conteneur associatif non ordonné, unordered_map, serait très lent (ne convenant pas au matériel moderne, car basé sur un nœud). Par conséquent, C++ est lent parce qu'ils l'ont comme un langage typé dynamique et ils ont choisi les mauvaises structures de données, pensent certains.

Source : BMC Bioinformatics

Et vous ?

Que pensez-vous de cette étude ?
Êtes-vous d'accord ou pas avec les résultats de l'étude ? Pourquoi ?
Selon vous, C++ serait-il plus lent que Java et Go ? Pourquoi ?

Voir aussi

C++ 20 : la spécification de la nouvelle version du langage C++ est finalisée, un tour d'horizon des nouveautés apportées

C++17 est maintenant officialisé, la norme a été publiée sur le site de l'Organisation internationale de normalisation (ISO)

« Pourquoi on est repassé de Go à PHP ? », Danny van Kooten, l'éditeur de MailChimp nous livre les raisons de ce rebasculement

Le langage Go continue sa progression avec de nombreux développeurs qui l'utilisent dans les projets professionnels et personnels selon un sondage

Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors, et supprimera le moteur JavaScript Nashorn

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 30/04/2020 à 14:53
En lisant l'article, quand j'ai commencé à lire :
Citation Envoyé par Bill Fassinou Voir le message
C ++ 17 en utilisant le comptage de références d'autre part pour gérer de grandes quantités d'objets de tas ».
ça commençait déjà mal. Gérer la mémoire à coup de comptage de références, ça revient à faire une sorte de ramasse-miettes en moins bien. Ce n'est pas comme ça qu'on tire profit du C++ pour les performances.

Ensuite, quand j'ai lu :
Citation Envoyé par Bill Fassinou Voir le message
Il semblerait que BMC Bioinformatics ait fidèlement porté la nature très dynamique de leur code existant en C++. C'est ce qui aurait affecté la performance du C++ 17. En parlant de structure de données, BMC Bioinformatics aurait utilisé également std::unordered_map <int, any>.
c'était le bouquet.

C++ n'augmente pas magiquement les performances si on fait n'importe quoi avec. Par contre, une bonne gestion de la mémoire en C++ permet de pousser loin les performances. À ce sujet, je conseille la vidéo CppCon 2018: Stoyan Nikolov "OOP Is Dead, Long Live Data-oriented Design" :

Le titre est putaclic. En vrai, il ne s'agit pas d'une vidéo hostile envers la programmation orientée objet. La vidéo est assez longue (une heure), mais elle est intéressante. Elle se focalise sur comment gérer les structures de données de manière à limiter les cache miss.
12  0 
Avatar de SimonDecoline
Expert confirmé https://www.developpez.com
Le 30/04/2020 à 17:55
Apparemment leur implémentation n'est pas du tout adaptée au C++ alors qu'elle aurait pu l'être (https://news.ycombinator.com/item?id=22957884)...
C'est peu inquiétant de voir ce genre d'études publiées dans une revue scientifique malgré un biais aussi énorme.
7  0 
Avatar de redcurve
Membre éclairé https://www.developpez.com
Le 30/04/2020 à 15:40
Le code est pas top
5  0 
Avatar de 23JFK
Membre chevronné https://www.developpez.com
Le 30/04/2020 à 20:07
J'ai plutôt l'impression que même codé avec deux pieds gauches et des paramètres compilateur non optimisés, C++17 parvient à conserver des performances honorables.
4  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 30/04/2020 à 18:10
Citation Envoyé par SimonDecoline Voir le message
C'est peu inquiétant de voir ce genre d'études publiées dans une revue scientifique malgré un biais aussi énorme.
Article publié dans la revue BMC Bioinformatics, c'est-à-dire pas l'endroit où on trouve des gens qui savent vraiment coder : le code, c'est un outil, sans plus. Les auteurs auraient dû avoir la décence de ne pas commettre ce genre de crime, la revue de refuser illico du code avec autant de défauts (surtout que c'est la seule contribution de l'article !).
3  0 
Avatar de SimonDecoline
Expert confirmé https://www.developpez.com
Le 01/05/2020 à 10:53
Citation Envoyé par abriotde Voir le message
Ca confirme ce que je pense. C++ est top mais il devient de plus en plus le Cobol moderne car les compétences baissent. Beaucoup de développeurs savent faire du C++ mais peu (enfin de moins en moins surtout parmis les jeunes) savent bien en faire. Je pense que C++ doit progressivement être remplacé par Rust la ou on en a l occasion...
Donc si je résume bien: 3 scientifiques publient leur comparaison C++/Java/Go; dès qu'on en parle sur un forum d'informatique tout le monde remarque que l'implémentation C++ est ridicule; et toi tu en conclues que pratiquement plus personne ne sait faire de C++ correctement et qu'il faut le remplacer par Rust ?
Moi j'en conclue plutôt que : 1) beaucoup de gens savent reconnaitre une mauvaise utilisation de C++, 2) coder avec un langage à GC est différent de coder avec un langage sans GC (et cela vaut aussi pour Rust), 3) l'article scientifique publié semble assez inacceptable aussi bien techniquement que scientifiquement.
2  0 
Avatar de archqt
Membre éclairé https://www.developpez.com
Le 01/05/2020 à 11:23
Citation Envoyé par abriotde Voir le message
Ca confirme ce que je pense. C++ est top mais il devient de plus en plus le Cobol moderne car les compétences baissent. Beaucoup de développeurs savent faire du C++ mais peu (enfin de moins en moins surtout parmis les jeunes) savent bien en faire. Je pense que C++ doit progressivement être remplacé par Rust la ou on en a l occasion. Sinon Go ou Julia sont des bons langages qui donneront des perf correct assez facilement.

Je pense que Go est un bon choix pour eux même s il n est sans doute pas réellement optimum.
L'autre jour j'avais un pote qui se traînait à 90km/h avec sa Ferrari, alors que moi avec ma Clio je le suivais sans problème.

Ferrari c'est plus ce que c'était, il vaut mieux acheter une Clio.

PS tu remplaces Ferrari par C++ et Clio par Java sur l'article
1  0 
Avatar de abriotde
Membre expérimenté https://www.developpez.com
Le 01/05/2020 à 2:04
Ca confirme ce que je pense. C++ est top mais il devient de plus en plus le Cobol moderne car les compétences baissent. Beaucoup de développeurs savent faire du C++ mais peu (enfin de moins en moins surtout parmis les jeunes) savent bien en faire. Je pense que C++ doit progressivement être remplacé par Rust la ou on en a l occasion. Sinon Go ou Julia sont des bons langages qui donneront des perf correct assez facilement.

Je pense que Go est un bon choix pour eux même s il n est sans doute pas réellement optimum.
0  4