Discussion :

[JolyLoic]

Non, pas des millions d'objets. D'abord parce qu'on n'a pas à visiter les anciens objets (génération 2 - il faudra seulement visiter les pages mémoire modifiées) ni les objets inaccessibles. Ensuite parce que la pile d'appels est en général assez compacte. Enfin parce que c'est un problème mémory-bound mais que les nouveaux objets sont tous dans le cache L3 ou inférieur.

Juste un petit détail : Le C++ a un avantage dans cette situation : On génère globalement beaucoup moins d'allocations mémoire en C++ qu'en Java, car l’agrégation se fait à l'aide d'un seul emplacement mémoire, là où Java va faire deux allocations et un pointeur entre les deux (remarque : C'est aussi un avantage pour l'utilisation du cache et le préfetching).

[DonQuiche]

La tu confond largement multi-coeur et GPU.

Je te parle des évolutions qui sont en train de se produire. Regarde ce qu'a fait AMD avec Steamroller (voire Jaguar sur X1/PS4), c'est exactement ce que je décris.

Le premier c avoir N processeur et en java ou autre utiliser des threads et des sémaphores ou autre objet de synchronisation.
Pour certain problème c la seul solution pour d'autre il y a bcp plus puissant car sans utilisation de mécanisme de synchronisation de thread, cette solution est utilisé avec les shaders.
Pour les shaders tu N unité de calcul qui vont fonctionner de façon indépendante .
Quand un vertex shader travail sur un vertex il ne peut pas interagir avec un autre vertex shader en cour d'execution et c la ou est le gain car il y a pas de synchronisation.

Mais ce modèle est limité, il correspond à trop peu d'algorithmes. Les GPU ne supportent qu'une fraction des problèmes de data parallelism (le terme que tu cherchais ?). Certes on a des bêtes capables de peupler des vecteurs d'un million d'éléments en moins de temps qu'il n'en faut pour le leur ordonner, super. Mais l'intérêt maintenant ce n'est pas de viser des vecteurs d'un milliard d'éléments mais plutôt de viser davantage d'algorithmes pour répondre à davantage de problèmes et servir davantage de domaines. Parce qu'en-dehors du jeu et du calcul scientifique...

Regarde le problème du ramasse-miettes par exemple : le GC récolte 10k racines sur la pile, qui sont autant de chaînes. Il doit ensuite toutes les visiter. Honteusement parallèle ! Avec un algorithme compact, du pur data parallelism ! Et pourtant les GPUs actuels, supposés spécialisé dans ces tâches, y sont médiocres. Pourquoi ?
* Parce qu'il faut recopier l'intégralité de la mémoire via le bus PCIe.
* Parce que le GPU est incapable de supporter efficacement un motif producteur-consommateur, que ce soit CPU->GPU, GPU->CPU ou GPU->GPU. Le dataflow supporté est rudimentaire.
* Parce que les structures de données concurrentes y sont impossibles. Hors du vecteur, point de salut.

Mais une archi moderne comme HSA n'a pas de telles limites. Tu peux aujourd'hui faire un GC efficace sur les nouveaux APU d'AMD grâce aux fonctionnalités que j'avais énumérées et à leur mémoire unifiée avec les coeurs CPU.

En fait ce n'est pas moi qui confonds avec le many-core, c'est cette frontière qui s'étiole : les GPU sont toujours des unités vectorielles SIMT mais moins qu'avant. Et pendant ce temps des sociétés comme Intel ont un temps envisagé de concurrencer les GPU avec une archi many-core (Larrabee, qui a engendré Xeon Phi). Et n'ont sans doute pas totalement abandonné.

Je ne sais pas si l'avenir est au SIMT (à la AMD), au SMT ou au many-core. Ce que je sais en revanche c'est que ces unités, comme la solution d'AMD, seront intégrées au CPU, qu'elles auront avec lui une mémoire virtuelle unifiée et des caches cohérents, capables de synchronisation, d'ordonnancement souple, de communication avec le système, de niveaux de protection. Et on les programmera en Java, C#, Python, C++, etc.

En plus l'architecture matériel qui permet ce genre de fonctionnement est bcp est plus simple qu'un multi coeur ce qui permet pour un même prix d'avoir bcp plus d'unité de calcul

Les faits prouvent le contraire : l'archi d'AMD ne brille pas sur les programmes actuels mais le sacrifice est maigre. Et quand on voit ce qu'on obtient en contrepartie et ce que ça permet... Et puis de toute façon il me semble (à vérifier) que ces tâches sont déjà memory-bound et que les perfs par unité ne pourront être améliorées qu'en anticipant les accès (branchements spéculatifs), en répartissant mieux le travail (granularité du data flow) et en minimisant la latence avec le CPU (en se posant au sein de celui-ci). Autrement dit en devenant plus généralistes.

Quant à multiplier les unités de calcul, pas sûr que la taille des données à traiter suive elle aussi la loi de Moore ! En revanche la complexité des algorithmes...

Juste un petit détail : Le C++ a un avantage dans cette situation : On génère globalement beaucoup moins d'allocations mémoire en C++ qu'en Java, car l’agrégation se fait à l'aide d'un seul emplacement mémoire, là où Java va faire deux allocations et un pointeur entre les deux (remarque : C'est aussi un avantage pour l'utilisation du cache et le préfetching).

Tout à fait et je rappelle que je n'ai jamais voulu faire un comparatif C++/Java, le résultat serait couru d'avance.

Je dis simplement que le ramasse-miettes reste un concept mal connu (voir ceux qui parlaient de comptage de références), sous-estimé, tandis que beaucoup s'illusionnent sur les performances des smart pointers. Dans les faits un ramasse-miettes est plutôt plus efficace que les compteurs de références et allocateurs par tas. Lorsque le C++ domine c'est grâce à la gestion manuelle et aux optimisations fines (#define boost_disable_threads, unique_ptr quand possible, etc). Mais le shared_ptr en lui-même reste un palliatif décevant tant sur le plan des fonctionnalités (ne résout qu'une partie des problèmes et en crée de nouveaux) que des performances.

[jo_link_noir]

Je me demandais, le compteur de référence de shared_ptr, n'est-il pas lié à des problèmes d'intrusifs de code ?

Je veux dire par là, java peut lancer son GC n'importe quand, si un objet est détruit à un instant t ou t+1 il n'y a pas de conséquence. Alors qu'en C++ la destruction de l'instant t est une nécessité, le destructeur est une grosse contrainte pour le coup (avec un pointeur intelligent en tout cas). Si il faut lancer un mark and sweep ou autres algorithmes adapté au GC à chaque destruction du shared_ptr ou sur la dernière instance (nécessite un compteur de référence ?) c'est totalement inefficace. Au final, je pense que le compteur de référence est la moins pire des solutions.

Après, si le t+1 et donc le destructeur n'est pas un problème, vient alors l'ajout d'instruction supplémentaire avec des stratégies qui peuvent varier du tout au tout selon les projets et les types utilisés. Mais on se rapproche vachement d'un gc.

Pour revenir au compteur de référence, je ne pense pas qu'il soit autant utilisé qu'on pourrait le penser. Déjà parce que les copies sont limitées grâce au référence et aussi parce que la sémantique de mouvement n'a pas besoin d'y toucher. Au final, ça se limite aux vraies copies. Avec un weak_ptr ça en fait peut-être beaucoup, comme souvent, tous dépend du projet. Le gros reproche que je fais (comme beaucoup ici en fait), c'est la politique de lock qui ne peut pas être changé.

[Invité]

Salut,

Il faut arrêter de se leurrer, le GPU ne remplacera jamais le CPU et vis versa, la meilleur solution est d'utiliser un thread qui exécute le gpu et le cpu de manière synchronisée et c'est tout aussi rapide que openCL. (Et je trouve que c'est même mieux que openCL.)

Le gpu est selon moi plus dédié à du traitement graphique sur un nombre très limité de vertices et de fragments, mais ce n'est pas à lui à faire le culling, de détecter les collisions, etc...., personnellement tout cela je le fais dans le CPU.

Le mieux que l'on peut faire éventuellement c'est quelque chose comme du dereffered shading, mais bon je ne programme pas beaucoup au niveau du gpu encore (plus difficile à débuguer et en plus, les versions modernes d'opengl ne sont pas supportée par tout les drivers encore, peut être que plus tard, quand les drivers opensource supporteront bien l'opengl moderne (parce que les drivers propriétaires --' j'ai souvent des problèmes de résolution et d'écran noir que je n'ai pas avec les drivers opensource sur ubuntu) et quand il y aura des outils de débuguage qui me permettront de voir comment évolue les variables dans mon shader autrement qu'avec un texture alors là je me remettrai peut être à programmer plus au niveau du GPU mais pour le moment mes essais à ce niveau là ne sont pas concluant du tout, même si certaines techniques comme l'instanced rendering, le deffered shading, etc..., me paraissent intéressante)
Je peine a faire un simple système de lightmap avec un shader, une depthtexture et une normal map.

Mais avec un thread tu fais à peu près la même chose, et j'ai du le faire avec les versions plus anciennes d'opengl. (opengl 3.0)

Il suffit juste de savoir bien programmer et de regrouper toutes les faces utilisant le même type de primitive et la même texture avant de les dessiner, en plus en faisant ça dans un thread ça accélère les perfs, ça évite de devoir faire trop d'appel à draw et à glBindTexture exactement comme le permet de le faire l'opengl moderne.
Pour update c'est très simple aussi avec les VBO, en faisant une VBO par tableau de sommet. (lorsque le vertex est transformé (je le fais côté CPU), j'update juste sa position dans la VBO et les matrices de vue de de projection font le reste)

Il faut juste savoir bien synchroniser ses threads pour que l'affichage soit cohérent. (Le c++11 permet de faire cela facilement, plus facilement que en java je trouve ou je galérais pas mal. )

Donc bon il y a moyen de s'en sortir largement sans devoir faire recours à des techniques modernes au niveau du GPU. (A part peut être, pour les effets graphiques avancés, ou là je ne regretterai pas que mon driver supporte le GLGL 3.3)

Donc en gros le CPU => update la scene à chaque fois que la caméra bouge, effectue le culling, et regroupe tout ce qui est commun pour accélérer le rendu avec un thread, dessine tout avec un autre thread de manière synchonisée.

Le GPU => effectue des effets graphiques avancé.

Mais en aucun cas le GPU doit faire du culling (même si apparemment maintenant c'est possible avec un geometry shader mais ça rendrait l'affichage trop lent), du regroupement de sommets et de la mise à jour de sommet, passer des tableaux de matrices à un shader personnellement je trouve ça moyen, bref...

Sinon, en ce qui concerne le système de réflexion, je n'en ai jamais eu besoin en c++ et au pire des cas quelques macros font l'affaire, je peux très bien faire un système de serialization en ajoutant seulement 3 macros, au niveau des include je n'ai jamais eu de problèmes non plus. (Faut just comprendre comment le compilateurs fonctionne)

Au niveau des shared_pointer personnellement j'arrive à m'en passer, le destructeur me suffit, suffit juste de faire de la composition, de l'agrégation interne et de l'agrégation externe, et je n'ai pas de problème de memory leak enfin du moins pas avec valgrind.

Je trouve que en c++ la mémoire est moins compliqué à gérer que en c car en c++ tu as une classe qui est responsable des allocations et des désallocations, mais encore faut t'il savoir coder correctement et ne pas faire des allocs bêtement dans des fonctions.

En général je n'approuve pas d'utiliser des shared pointer ou ce genre de chose car je trouve que ça nous apprend à mal coder, on est tenté de faire des fonctions qui utilise instancie des shared pointers et à codé comme en c plutôt que de faire des classe qui alloue et libère la mémoire. (Et en java c'est pareil)

Même remarque en ce qui concerne le mot clé auto qui tente d'avantage le programmeur à faire cela.

Le seul moment ou j'ai besoin des shared et unique_ptr c'est lorsque j'ai une moulte d'exception et de blocs catch. (Car le mot clé finally n'existe pas en c++ et là je dois absolument utiliser RAII)

Bref c'est comme ça que j'ai appris à programmer à l'école moi.

[DonQuiche]

Il faut arrêter de se leurrer, le GPU ne remplacera jamais le CPU et vis versa

Mais personne n'a dit ça. Mais il y a deux tendances de fond à prendre en compte :
* Il y a une vraie demande pour un data parallelism complexe, que ce soit plusieurs problèmes honteusement parallélisables encore réalisés de façon séquentielle (tris) ou de nouveaux problèmes liés à l'intelligence artificielle et aux gros volumes de données.
* La loi de Moore est toujours vivace mais les performances CPU stagnent. Alors on double le cache pour gagner 10% sur le CPU ou bien on fait quelque chose de plus utile ?

Donc il ne s'agit pas de remplacer l'un par l'autre mais d'avoir les deux en permanence à portée de main et de les faire interagir de façon fluide pour bien exploiter la loi de Moore et continuer à progresser. Le logiciel et le matériel doivent tous deux aller vers du data parallelism de masse. Et oui c'est compliqué mais, oui, il y a des solutions pour le programmeur de tous les jours.

les versions modernes d'opengl ne sont pas supportée par tout les drivers encore, peut être que plus tard, quand les drivers opensource supporteront bien l'opengl moderne (parce que les drivers propriétaires --' j'ai souvent des problèmes de résolution et d'écran noir que je n'ai pas avec les drivers opensource sur ubuntu)

Le problème a longtemps infesté OpenGL malheureusement. Cela a bien progressé le jour où OpenGL est revenu à la mode (même si les navigateurs gardent une liste des drivers pourris pour lesquels il faut préférer un rendu logiciel). Tu verras que lorsque Chrome et Firefox utiliseront le GPU pour le GC de Javascript et le layout html, alors Monsieur Dell recevra plein d'appels de clients mécontents et ira prompto expliquer à monsieur NVidia qu'il a intérêt à se bouger le derrière s'il veut vendre ses GPU chez eux.

et quand il y aura des outils de débuguage qui me permettront de voir comment évolue les variables dans mon shader autrement qu'avec un texture alors là je me remettrai peut être à programmer plus au niveau du GPU mais pour le moment mes essais à ce niveau là ne sont pas concluant du tout

Cuda est largement mieux pour ça de ce que j'ai entendu dire mais peu importe : oui, ça va s'améliorer. Tout le monde est conscient du problème et le nouveau matos va faciliter ça.

Le mieux que l'on peut faire éventuellement

Le mieux que l'on peut faire avec les précédentes architectures.
Encore une fois les archis AMD changent beaucoup la donne, tant à cause de la mémoire unifiée que du dataflow souple et des possibilités de synchronisation.

[Invité]

Ouais au niveau synchronisation entre le CPU et le GPU ça peut sembler assez galère surtout pour les grosses IA et les gros volumes de données ainsi que les algorithmes de tri, donc ça oui il faut du parallélisme complexe, je suis d'accord, ceci dit, je trouve que les nouvelles librairies pour en faire sont encore trop complexe et ne fonctionnent pas encore très bien avec tout les drivers.
J'espère que à l'avenir il y aura une évolution. (Ainsi que au niveau des drivers aussi)

[Matthieu Vergne]

« C++ est pour la haute performance, la haute fiabilité, le faible encombrement, la faible consommation d’énergie et pour toutes ces bonnes choses, non pas pour les amateurs et les applications rapides, car cela ne relève pas de son domaine ».

Vu qu'on parle de haute performance, j'imagine que ces "applications rapides" font référence aux "applications codées rapidement". Cette phrase me fait quand même un effet très sarcastique. Style "le C++ permet de bonnes choses, mais non désolé il n'en permet pas de mauvaises, nyark nyark".

En le prenant autrement on peut en comprendre que le C++ n'est pas fait pour les débutants et le prototypage. Il est donc préférable de se former avec un autre langage pour apprendre plus en douceur et de faire des prototypes avec un autre langage qui permet de coder plus rapidement sans se soucier de tous les menus détails, qui peuvent être pris en compte plus tard. Perso, c'est un peu pour ça que je suis passé de C++ à Java : dès lors que tu veux tenter des trucs, ça devient une vraie gageure de le faire en C++. Il faut charger 300 bibliothèques pour faire le moindre truc de base et pour les débutants tu passe plus de temps à déboguer qu'à coder ton application. En tout cas, c'est la vision que j'en avais en 2009 qui m'a fait switcher à Java. Maintenant je sais que pas mal de choses ont changé et si je devais me remettre au C++ il me faudrait me reformer depuis la base. Mais apparemment, la perspective est toujours la même : privilégier la performance à la facilité d'utilisation. Du coup je doute qu'avec mon caractère très expérimental je m'y remette sérieusement.

[Luc Hermitte]

Le C++11 s'est voulu moins orienté vers les experts que le C++98 ne le fut.
C'est là que sont arrivés certains sucres syntaxiques, et autres petites améliorations.

Reste que cela ne corrige en rien qu'il faille savoir coder un minimum. Toutes les difficultés & subtilités du Génie Logiciel sont là de même que celles du paradigmes OO, ... Quand on prototype, ce n'est pas trop le genre de choses avec lesquelles ont s'encombre.

Côté écosystème, la lib standard est toujours aussi maigre. Il faut se tourner vers boost et/Qt pour compléter les manques principaux. Il faut se tourner vers d'autres sources pour Java également (Apache, eclipse RCP, middleware, ...), mais dans l'ensemble sa lib standard est plus fournie.

[ternel]

[...] le C++ n'est pas fait pour les débutants et le prototypage. [...] Perso, c'est un peu pour ça que je suis passé de C++ à Java : dès lors que tu veux tenter des trucs, ça devient une vraie gageure de le faire en C++. Il faut charger 300 bibliothèques pour faire le moindre truc de base et pour les débutants tu passe plus de temps à déboguer qu'à coder ton application. [...]

Je ne suis pas d'accord avec cela.

Je code régulièrement des prototypes en C++, sans lib externe, en général.
Par contre, je reconnais que d'avoir Swing sous la main donne à java l'avantage pour prototyper une interface graphique

C++ est un langage assez simple en lui même. Pour peu qu'on accepte d'apprendre comment ca marche en dessous.

Mais le problème est le même en java.
Il faut savoir le for( : ) fonctionne sur les iterables en invoquant iterator(),
que les objets sont passés par références (comment ca, des pointeurs cachés...)
que toutes les classes héritent indirectement ou non d'Object.
qu'il faut explicitement appeler new sur chaque objet... (pas de gestion de la mémoire?)
que les exceptions qui héritent de RuntimeException n'ont pas à être déclarée dans la "throws", et peuvent être attrapée régulièrement.
que les génériques n'acceptent pas int, et donc qu'il existe un mécanisme de boxing/unboxing presque magique.

Bref, que les fonctionnalités du langage sont intimement entrelacées avec la bibliothèque standard.

[koala01]

Vu qu'on parle de haute performance, j'imagine que ces "applications rapides" font référence aux "applications codées rapidement". Cette phrase me fait quand même un effet très sarcastique. Style "le C++ permet de bonnes choses, mais non désolé il n'en permet pas de mauvaises, nyark nyark".

En le prenant autrement on peut en comprendre que le C++ n'est pas fait pour les débutants et le prototypage.

Je suis justement occupé à la rédaction d'un ouvrage qui tend à démontre le contraire (pour ce qui est des débutants du moins).

Il est donc préférable de se former avec un autre langage pour apprendre plus en douceur et de faire des prototypes avec un autre langage qui permet de coder plus rapidement sans se soucier de tous les menus détails, qui peuvent être pris en compte plus tard.

Peut être, à un bémol près : il ne faut jamais en arriver à considérer les principes de base du (des) paradigne(s) utilisés comme étant de "menu détails".

Si tu penses, par exemple, aux pointeurs et à la gestion manuelle de la mémoire, tu as (en partie) raison : il ne sert à rien de s'inquiéter de ces détails lors de l'apprentissage. Mais C++ permet de s'en passer jusqu'à ce qu'on aborde les problèmes liés au point réellement neuf du paradigme oo : la substituabilité et son pendant que sont les comportements polymorphes.

Par contre, si tu considère les principes SOLID ou la loi de déméter comme de "menus détails", tu mérites sans doute de te faire pendre par les pieds au dessus d'un feux de joie

Il est tout à fait vrai que C++ part du principe que le développeur sait ce qu'il y a toujours une bonne raison à ce qu'il fait, privilégiant à chaque fois la fonctionnalité utile (à condition d'être correctement utilisée) à la sécurité d'une fonctionnalité non fournie.

D'autres langages ont une philosophie différente, mais c'est sans doute cette différence de philosophie qui permet le mieux de choisir le langage "qu'on préfère"

[jblecanard]

Salut

Le "succès" du langage ne tient pas qu'à ses caractéristiques techniques mais également à l'histoire humaine de celui-ci. Le succès de C++ aujourd'hui n'est pas lié qu'à ses particularités, il est lié aussi au fait qu'il est massivement utilisé dans l'industrie et que de coûteuses et volumineuses solutions logicielles sont faites avec. Dans ces conditions, changer de langage aurait un coût totalement exhorbitant pour nombre de domaines, que ce soit en réécriture de code, en coût de formation et de recrutement de développeurs, et autres auxquels je ne pense pas encore. Il vaut mieux faire évoluer l'existant (et d'ailleurs, Stroustrup dit lui même que la rétro-compatibilité est une feature en C++, je met pas le lien car il va mettre une miniature vidéo forcée et je veux pas) que partir sur un nouveau langage.

Sans que cela mette en doute ce qui est dit sur la partie technique, c'est un facteur, parmi d'autres, à prendre en compte. A supposer qu'un langage aussi bon et adressant les mêmes problématiques soit inventé, il ne pourrait avoir autant de ce succès à cause de ce facteur historique. Un facteur qui concerne aussi d'autres langages et qui fait que nous aurons encore du C et du Java pour de longues années.

[Matthieu Vergne]

On est d'accord. Un paradigme, on le prend ou on le jette. On l'imagine pas à sa sauce pour se plaindre après que ça marche pas comme on veut. Je parle bien du fait que, une fois que tu as installé Java, tu as tout ce qu'il faut pour t'amuser avec des concepts haut niveau, jusqu'aux interfaces graphiques. Après, libre à toi de rajouter des libs et de refactorer ton code pour les utiliser, mais au moins tu peux démarrer tout de suite. En C/C++, la sélection et installation de libs est quasi-obligatoire, sinon on en reste à des exercices d'écolier et à réinventer la roue. Si aujourd'hui on a des grosses libs qui fournissent de nombreuses bases de manière homogène, avant c'était pas le cas, et c'était bien là le problème (et le gros avantage de Java à ce moment là). J'imagine qu'aujourd'hui, tu as une ou deux libs typiques que tu utilises dans tous tes projets et à partir de ça tu fais un peu ce que tu veux, comme en Java (avec la config initiale en plus pour les utiliser). Mais comme ça fait longtemps que j'ai pas codé en C++, je peux pas m'avancer plus.

[Médinoc]

je met pas le lien car il va mettre une miniature vidéo forcée et je veux pas

Regarde dans les options sous la TextBox quand tu postes, tu verras des cases à décocher pour éviter cela.

[moldavi]

Bonjour.

Il ne faut pas perdre de vue que les performances d'un programme ne sont pas pas intrinsèquement liées à un langage.

En effet le compilateur à son mot à dire. Un bon langage comme le C++, avec un compilateur médiocre, et tout le monde dira que le C++ n'est pas performant.

Les langages interprétés comme C#/Java ajoute des instructions au code (l'interprétation + GC et autre truc), ce qui fait que ces langages seront toujours moins performants que le C++. C'est juste de la logique : moins d'instruction, plus de performance. Cela est encore plus flagrant au niveau du GPU : une instruction en moins, et c'est 2 fps de gagné, surtout avec des millions de poly).

Les langages interprétés comme C#/Java ont l'avantage de la rapidité de développement et du portage. Mais pour les performances le C++ a encore de longues années devant lui.

Les langages interprétés sont encore perdants face aux langages impératifs, en terme de performance.

De toute façon, si un langage était "Performant", "Portable", "Rapide à développer", cet article n'aurait pas lieu d'être. Chaque langage a ses avantages et ses inconvénients. Au développeur d'utiliser ceux-ci à bon escient.

[ChristianRoberge]

Le C++ est un mauvais langage car il y a plusieurs façons de faire la même chose (Des bonnes et de très mauvaises!). Après 25 ans de programmation avec ce langage, il y a toujours de nouvelles façons de faire. Les nouvelles normes C++11 et C++14 amènent encore plus de confusion dans un langage qui était déjà fort complexe. Toutefois, quand on réussis à maitriser la bête, c'est un langage que l'on ne peut se passer. Les performances ont un prix. Plusieurs aiment des solutions simples et rapides, mais on oublie souvent qu'outre les performances médiocres, l'extensibilité et la réutilisation haut niveau du code est aussi moindre en C++. Quand on travaille dans un même domaine, comme moi, l'avantage du C++ est alors incommensurable par rapport aux autres langages à long terme. Je n'ai pas vu de d'autres langages qui le surpasse.

[DonQuiche]

Il ne faut pas perdre de vue que les performances d'un programme ne sont pas pas intrinsèquement liées à un langage.

En effet le compilateur à son mot à dire. Un bon langage comme le C++, avec un compilateur médiocre, et tout le monde dira que le C++ n'est pas performant.

Je n'irais pas jusqu'à dire que les perfs ne sont "pas intrinsèquement liées au langage" car cela ne serait vrai que dans un monde où des compilateurs encore plus intelligents que nous seraient possibles. Mais en attendant que ce soit vrai un jour, un typage dynamique, par exemple, restera toujours plus lent car le compilateur ne pourra pas toujours obtenir de certitude quand aux types attendus.

Plusieurs aiment des solutions simples et rapides, mais on oublie souvent qu'outre les performances médiocres, l'extensibilité et la réutilisation haut niveau du code est aussi moindre en C++.

Tu voulais dire, je présume, que la réutilisabilité et l'extensibilité sont meilleures en C++ ? Si oui, je confirme : je suis très frustré par le système de types en C#, je trouve qu'ils n'ont fait qu'une partie du chemin. Et celui de Java ne vaut pas beaucoup mieux.

Sur le seul système de types, pour simplement égaler le C++ et compenser l'absence d'héritage multiple et de templates il faudrait des mixins, des corps de méthodes dans les interfaces, des contraintes génériques plus riches, et de l'inlining de lambdas pour une composition fonctionnelle. Après ça on pourrait rêver de fonctionnalités plus exotiques puisque le systèmes en C++ n'est pas non plus l'apha et l'oméga de la POO, loin s'en faut.

Et ensuite il y a la métaprogrammation : l'introspection (reflexion) reste fastidieuse et de toute façon elle va disparaître pour des raisons de sécurité (l'OS devra pouvoir prouver l’innocuité du bytecode) et de performances (les binaires en sont très alourdis et cela empêche de nombreuses optimisations). A l'heure actuelle il ne reste plus que les générateurs de code comme solution sur dotnet ! Je râlais précédemment contre les templates, je maintiens que c'est un mauvais modèle, mais en attendant c'est certainement mieux que rien.

[Médinoc]

l'introspection (reflexion) reste fastidieuse et de toute façon elle va disparaître pour des raisons de sécurité (l'OS devra pouvoir prouver l’innocuité du bytecode)

Avec les restrictions de droits du code, ça ne change pas grand-chose (la validation du bytecode, que ce soit lors du chargement ou de la création par réflexion, peut interdire tous les codes qui peuvent compromettre la validation).

[DonQuiche]

Avec les restrictions de droits du code, ça ne change pas grand-chose (la validation du bytecode, que ce soit lors du chargement ou de la création par réflexion, peut interdire tous les codes qui peuvent compromettre la validation).

Je présume que c'est lié à une fonctionnalité matérielle (Data execution prevention) utilisée pour empêcher l'exploitation d'une éventuelle faille du runtime mais qui réclame que toutes les pages de code soient marquées comme telles à la création du processus.

Quoi qu'il en soit MS interdit ce genre de choses dans un nombre croissant de contextes: windows store aujourd'hui et, demain, singularity/midori.

[Invité]

Personnellement j'ai commencé à apprendre le java qui est très bien pour apprendre avec les interfaces graphiques.
J'ai appris aussi entre temps du c pour apprendre à coder des algorithmes en console. (On a vu alors la différence entre ces deux langage au niveau de la gestion de la mémoire et de l'orienté objet)
Et puis j'ai terminé mes études en apprenant le c++ qui ajoute l'orienté objet au language c.

Le java n'était plus suffisant pour faire des applications plus complexe niveau performance c'était pas ça, niveau programmation parallèle c'était limite et ça manquait cruellement de libs et de documentation surtout dans le domaine du codage de grosse applications multimédia.

C'est à ce moment là que je suis repassé au c++ qui fournis, pleins de librairies sympas.

Je pense que le c++ tiens sont succès grâce à ça.

[Médinoc]

Je présume que c'est lié à une fonctionnalité matérielle (Data execution prevention) utilisée pour empêcher l'exploitation d'une éventuelle faille du runtime mais qui réclame que toutes les pages de code soient marquées comme telles à la création du processus.

Non, pour .Net, c'est logiciel, lors de la compilation JIT: Les instructions bytecode sont de haut niveau, du genre "écrire cette variable locale", "écrire ce membre de cet objet" ou "écrire à tel emplacement de ce tableau" (avec vérification des bornes) ; et les instructions "écrire à cette adresse arbitraire" ou "appeler cette fonction non-managée" causeront une erreur de compilation JIT si le code n'est pas en Full Trust.

Ce qui signifie que seul le code en Full Trust peut faire des manipulations arbitraires en mémoire, comme celles nécessaires pour contourner la sécurité (par exemple en falsifiant la pile d'appels). Et s'il est déjà en Full Trust, il n'en a pas besoin.

(et tu as très probablement, par-dessus, les protections hardware)