Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Mouais je ne suis pas expert Java mais qu'est-ce qui empêche d'avoir une vm écrite en Java 'compilé'.Envoyé par CAMIC
C'est comme dire que le C a de beaux jours devant lui (ce que je ne doute pas) parce que le compilateur C++ est écrit en C....Le premier compilateur sûrement mais plus maintenant...
J'aurais surtout tendance à dire que C++ a encore de beaux jours devant lui parce qu'il y a une quantité phénoménale de code écrit en C++ qu'il est irréaliste d'envisager de réécrire
De plus, il n'y a rien à faire, il faut et il faudra toujours -- même si c'est pour des "secteurs de niche"-- des langages qui soient, en tout état de cause beaucoup plus proche de la machine que ce que peut l'être java, même dans sa version compilée.
Ceci dit, on peut en dire autant en ce qui concerne la quantité de code java, surtout quand on voit le nombre de projets à démarrer pour lesquels le choix s'est orienté vers lui
A méditer: La solution la plus simple est toujours la moins compliquée
je confirme c'est pour la même qu'il existe encore tout un tas de développeur cobol/mainframe aussi. dure pour une entreprise de se débarrasser d'un vieux système quand tout son SI est basé" dessus.....J'aurais surtout tendance à dire que C++ a encore de beaux jours devant lui parce qu'il y a une quantité phénoménale de code écrit en C++ qu'il est irréaliste d'envisager de réécrire
De plus, il n'y a rien à faire, il faut et il faudra toujours -- même si c'est pour des "secteurs de niche"-- des langages qui soient, en tout état de cause beaucoup plus proche de la machine que ce que peut l'être java, même dans sa version compilée.
Ceci dit, on peut en dire autant en ce qui concerne la quantité de code java, surtout quand on voit le nombre de projets à démarrer pour lesquels le choix s'est orienté vers lui
Vue sous cet angle, le C est largement préféré au C++ par la communauté des développeur lorsqu'on veut faire un développement "proche de la machine" . Le C++ a finalement de la peine a trouver sa véritable place, quelque soit le critère de choix que l'on opte (productivité, performance, robustesse, maintenabilité etc) on pourra difficilement choisir le C++ comme langage pour démarrer un nouveau projet, et il ne sera finalement utilisé que pour maintenir du code ancien
Je ne suis pas sur du tout!!!
Il ne faut pas croire que, parce que l'on dit "proche de la machine", on parle d'office de drivers, non plus
Je travaille actuellement sur un projet industriel entièrement écrit en C++ qui n'a été démarré il n'y a "que" 5 ans
Je ne doute pas qu'il y aurait sans doute moyen de faire le même projet en java, mais je ne suis pas sur du tout que nous pourrions atteindre le degré de performances obtenu en C++
Dans certaines situations, le recours au garbage collector ou à une machine virtuelle (ou à d'autres obligations apportées par java) n'est, purement et simplement, pas envisageable, mais où l'apport du paradigme OO ou du paradigme générique est indispensable.
Dans de telles situations, le seul langage qui reste, c'est C++
La place de C++ est relativement simple : entre le driver et l'application qui peut se permettre de recourir à une machine virtuelle
Et encore, il y a parfaitement moyen de décider d'écrire un driver avec
Ok, alors au boulot !
En tout cas merci à tous pour toutes ces explications très enrichissantes, qui, même si elles ne me font pas choisir un des deux languages me donnent juste envie de toucher aux deux
Peut-être que c'est en pratiquant que j'en viendrai à donner ma préférence à l'un ou à l'autre. Mais c'est vrai que pratiquant le Java depuis 2 mois maintenant, je reste tout de même séduit et attiré par le côté vitesse de C++ mais surtout par le fait qu'on reste de libre de "toucher à tout" et de "jouer avec la machine". Quant au principe de la programmation orientée objet, je crois qu'il ne doit pas être trop difficile de passer de l'un à l'autre, les structures de programmation restant identiques (ou très similaires) pour les deux languages, à ce que j'ai compris...
Voilà, voilà...
A+
Ok, alors au boulot !
En tout cas merci à tous pour toutes ces explications très enrichissantes, qui, même si elles ne me font pas choisir un des deux languages me donnent juste envie de toucher aux deux
Peut-être que c'est en pratiquant que j'en viendrai à donner ma préférence à l'un ou à l'autre. Mais c'est vrai que pratiquant le Java depuis 2 mois maintenant, je reste tout de même séduit et attiré par le côté vitesse de C++ mais surtout par le fait qu'on reste de libre de "toucher à tout" et de "jouer avec la machine". Quant au principe de la programmation orientée objet, je crois qu'il ne doit pas être trop difficile de passer de l'un à l'autre, les structures de programmation restant identiques (ou très similaires) pour les deux languages, à ce que j'ai compris...
Voilà, voilà...
A+
Pour du temps réel, le C++ est le choix le plus évident.
Pour apprendre la conception objet, Java me semble un meilleur choix.
Java donne par contre de mauvaises habitudes(au débutant) sur la gestion des ressources. On laisse travailler le GC, il faut pourtant l'aider si on veut améliorer les performances (mettre les objet inutilisé à null par exemple).
Le développement en Java est plus simple que celui en C++, il nous abstrait de pas mal de problèmes techniques.
Ce sont les techniciens de Sun qui fournissent les bibliothèque C++ maison.
En C++, c'est un véritable casse tête pour travailler avec des String si on inclu d'autres bibliothèque qui utilisent leurs propres implémentation de String(X11/Motif, etc).
Bref,
Normal, X11 et Motif (du moins il me semble, faudrait que je vérifie) sont des bibliothèques écrites en C et non en C++, ce qui n'a absolument rien à voir. Pour le reste, la classe string du C++ standart marche très bien (même si j'admets qu'il lui manque encore quelques fonction du style split(), mais bon).
Sinon, en ce qui concerne l'évolution du C++ dont il est question plus haut, je crois que le problème est que le C++ est avant tout un standart ouvert et qu'il faut mettre tous le monde d'accord pour le faire avancer, contrairement à des langages comme java qui sont poussés par les gars de sun.
Je pense que pour un développement il vaut mieux faire une bonne conception Objet avec un proto en JAVA qui sera plus facile a tester et a debugger et ensuite si il y a des problème de performance le redévelopper totalement ou en partie en C++ ou de générer du C++.
Je trouve que la problèmatique de traduction entre langage est intéréssente
Peut traduire du C++ en Java et inversement ?.
Par contre il y a un domaine C++ ecrase JAVA c'est pour l'écriture de formule mathématique qui manipule des vecteurs ou des matrices.
avec les constructeurs par recopie et la surcharge d'opérateur on peut faire des programmes très lisible et performant alors quand JAVA il faut mettre des objets en cache et faire attention ne pas en allouer sans raison.
On peut aussi allouer des objets sur la pile d'execution ce que java ne peut pas faire.
Il y a gcj qui compile le java en natif, avec le résultat que l'on connait : des performances médiocres. A mon avis les traductions automatiques ne sont jamais bonnes car elles ne font jamais appel aux particularités des langages. Comment un traducteur utiliserai l'api Sun. Comment décider de prendre un HashSet, un LinkedHashSet par exemple
Je pense aussi qu'il faut apprendre les deux, mais dans un certain ordre:
Java en premier puis C++
Tu apprendras ainsi à 'concevoir' des applications en objet (avec Java). Tu penseras plus en objet quand tu feras du C++. En effet, on peut faire des choses abominables en C++ (mix entre C et objet), alors que si tu prends l'habitude de voir bien les divers objets et leurs interactions, tu appliqueras naturellement ces méthodes au C++ et tu auras des applis plus propres et moins buggées.
C'est n'est pas important l'ordre, tu peux même les apprendre les deux à la fois, mais en tenant compte qu'on parle de deux langues différentes.
Un language rapide ? IMPOSSIBLE !
A tout ceux qui prétendent "Java est plus rapide que le C++ sur certains programmes" (Entre autre j'ai aperçu le post de Badra qui parle de Fibonacci).
*STOP* Idée fausse :
Ce n'est pas le programme qui fait la vitesse de l'executable (tant que l'algorithme utilisé est identique dans les 2 languages) mais bien le compilateur lui-même !
Partant d'un même algorithme, plus un compilateur est efficace plus il trouvera d'optimisations et plus il saura choisir les instructions rapides pour la machine sur laquel vous êtes en train de compiler.
En Java, le compilateur a des contraintes plus importantes d'utilisation de la mémoire (vive ou morte) et surtout sur le temps de compilation "perdu" à chercher des optimisations spécifique a chaque architecture. Il est donc normal qu'un compilateur Java produise des executables moins rapide EN MOYENNE. (Cela n'exclut pas les nombreuses exceptions que vous avez pu rencontrer...)
Pour toutes les MV écrites en C/C++, il est toujours possible de "fusionner" votre programme Java avec le code source de la MV et d'élaguer toutes les parties inutiles du monstre optenu pour optimiser le tout. Vous obtiendrez ainsi un programme en C/C++ fatalement plus rapide que si vous aviez fait tourner votre code sur cette MV.
C'est discutable : pour la vitesse d'exécution d'un programme il y a plusieurs paramêtres qui rentrent en ligne de compte : la vitesse CPU et l'OS notamment.
S'il ya beaucoup de taches en exécution en même temps un programme développé en C++ risque d'être aussi lent qu'un autre fait en Java
Un programme subit les mêmes contraintes d'OS & vitesse CPU qu'il soit programmé en C++ ou en Java.
Oulà exemple très mal choisi, totalement en défaveur de tous les languages haut niveau justement !
La chute de performance étant exponentielle (quasi-asymptotique) lorsque l'on approche de la limite critique de l'utilisation d'un serveur, la moindre ressource utilisé en plus peut être fatale. Une attaque DDoS par exemple, vise à faire franchir au serveur cette fameuse "limite" au delà de laquelle tous les services du serveur sont perturbés (quasiment plus rien ne va répondre).
Ca s'explique très facilement :
Si a un moment donné tous les programmes sont soudainement ralentis, alors la quantité de programme en attente derrière augmente. Ce qui fait monter le nombre de ressource (en attente d'être utilisées) sockets, RAM, CPU, etc. La conséquence est que les ressources systèmes disponibles diminuent. Du coups les programmes actuellement en cours ralentissent aussi.
... Bref : moins on va vite, moins on va vite.
Les languages de haut niveaux comme le Java sont au contraire compétitif quand les ressources disponibles sont largement suffisante, c'est bien pour cela que tout le monde -en tout cas au moins moi- te dira que le Java est bien CAR les machines modernes sont de toutes façons de plus en plus puissantes (c'est à dire moins de chance d'approcher la limite critique).
Pas du tout les ressources sont gérées par l'OS ; qu'un programme soit en Java ( bytecode ) ou en C++ ( code natif ) l'OS lui fournit la mémoire requise.
Quand tu fais un new c'est l'OS qui fournit la mémoire donc il n'ya pas de compétition comme tu affirmes avec Java..
Il faut quand même nuancer cela : le compilateur JIT (Just In Time) de la JVM n'effectue pas une compilation complète. Le gros du travail de la compilateur est bien fait par le compilateur javac, et le JIT n'a plus qu'à optimiser le code pour la machine.
De plus il a également ses avantages :
- Il connait avec précisions les caractéristiques de la plateforme qui fait tourner l'application, et peut donc utiliser les meilleurs optimisations.
- Il connait l'état du programme (classes chargées par exemple), et peut ainsi en profiter pour appliquer des optimisations qui ne serait pas toujours possible.
- Il peut recompiler du code déjà compiler afin de le "dés-optimiser" si possible. C'est très pratique car cela permet d'utiliser des optimisations très poussé et de revenir en arrière au cas où cela poserait problème !
Tout cela peut permettre d'améliorer les performances d'une application. Prenons l'exemple de l'inlining des méthodes :
- Un compilateur C++ ne pourra pas utiliser l'inlining pour une méthode virtuelle, puisque il faudra exécuter un autre code si elle est redéfini...
- Par contre, le compilateur JIT de la JVM pourra très bien utiliser l'inlining pour une méthode virtuelle, à condition qu'il n'existe aucune classes filles qui ne redéfinissent cette méthode. Et si une tel classe fille est chargé plus tard, le code sera recompilé afin de prendre en compte cela...
Bien sûr je ne dis pas qu'un programme Java sera obligatoirement plus rapide qu'une programme C++. Je dis seulement qu'un programme Java peut tout à fait rivaliser avec un programme C++ en terme de performance. Bref je reste persuadé que l'argument "performance" ne devrait pas entrer en compte dans le choix du langage (en tout cas pour ce qui concerne C++ et Java).
Et ceci n'est pas forcément vrai non plus !!!
J'avais fait quelques tests il y a quelques temps avec GCJ et JET (qui permettent tout deux de générer du code natif) et grosso modo les performances natif se trouvait entre la JVM -client (JVM "standard") et la JVM server (JVM optimisé pour les gros traitement) : La machine virtuelle Java est-elle vraiment lente ?
a++
très intéressant, mais il faut aussi signaler quelques détails sur cette compilation JIT :
+ la compilation bénéficie d'informations sur l'état de l'environnement d'exécution, ce qui n'est pas possible avec les compilateurs traditionnels
+ ce compilateur JIT ne traite pas tout le code d'un coup, ce qui implique qu'il ne peut pas, contrairement aux compilos traditionnels, appliquer certaines optimisations très poussées sur le code... qui peuvent réduire sa taille, et augmenter sa vitesse énormement
+ le fait que le code compilé puisse etre facilement "dé-compilé", comme tu le soulignes, implique que la structure du code compilé est restée assez proche d'une structure de bytecode.... et donc que les optimisations n'ont pas été appliquées à leur potentiel maximal
(nb: ceci va en revanche beaucoup dépendre de l'architecture de la machine... car le bytecode java possède quand meme pas mal d'instructions bas niveau
très intéressant... sauf qu'il faut savoir que cette compilation JIT et l'inlining ont un cout, qui n'est pas négligeable surtout si l'on passe son temps à changer de "classe réelle" pour cette méthode
J'avoue que je ne sais pas vraiment comment cela fonctionne en détail... mais cela ne pourrait pas être effectué par le compilateur javac ?+ ce compilateur JIT ne traite pas tout le code d'un coup, ce qui implique qu'il ne peut pas, contrairement aux compilos traditionnels, appliquer certaines optimisations très poussées sur le code... qui peuvent réduire sa taille, et augmenter sa vitesse énormement
Non le compilateur peut compilé en natif pure même s'il doit le "décompiler". En fait le code natif n'est pas vraiment "décompilé" mais plutôt supprimé pour être recompilé à partir du bytecode lorsque la JVM charge une classe qui pourrait poser des problèmes (plus d'info, même si c'est un peu vieux : Method Inlining Example).+ le fait que le code compilé puisse etre facilement "dé-compilé", comme tu le soulignes, implique que la structure du code compilé est restée assez proche d'une structure de bytecode.... et donc que les optimisations n'ont pas été appliquées à leur potentiel maximal
Sinon si le sujet t'intéresses tu peux jeter un coup d'oeil à ce billet qui recense quelques optimisations possibles par le JIT (même si certaines sont théoriques et ne sont pas encore implémenté) : Software Territory: Where Hardware can't go!
a++
Thifauv a écrit en page1:
C'est marrant j'aurais plutôt dit le contraire.Je pense aussi qu'il faut apprendre les deux, mais dans un certain ordre:
Java en premier puis C++
Je suis passé par le C et le C++ pour m'orienter ensuite vers Delphi et C#.
Je pense que C++ permet de bien appréhender les notions de types, de blocs mémoires, de pointeurs etc...
C et C++, de part leur précision, force la compréhension du code.
Combien de fois au début me suis-je demandé en delphi comment est transmis un record, un objet, un entier (valeur ou adresse?).
Idem en ce qui concerne les tableaux.
D'ailleurs, pour effectuer des traitements de chaines, je transtype toujours les strings en pchar pour me retrouver dans un contexte 'C'.
Et le constructeur de recopie, la forme canonique de Coplien: concepts absent en Delphi.
Pour le développement à bas niveau C et C++ resteront les références.
PS/ Le Java? quelle horreur! Ce langage n'a jamais su me convaincre.
@+
Répondre avec citation
Partager