IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Débats sur le développement - Le Best Of Discussion :

[Débat] C++ vs Java


Sujet :

Débats sur le développement - Le Best Of

  1. #221
    Futur Membre du Club
    Profil pro
    Inscrit en
    octobre 2006
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2006
    Messages : 8
    Points : 8
    Points
    8
    Par défaut
    Citation Envoyé par Epictète
    Cependant contrairement à Java, il manque plein de chose à C++ ce qui fait que pour faire certaines choses (exemple interfaces utilisateurs : swing en java, en C++ rien) , ou accès sgbd (jdbc en Java, en C++ rien), etc, tu doit soit utiliser une lib pour l'OS, donc non portable, soit trouver une lib portable. Mais c'est une LIB en plus, c'est pas inclus dans le standard C++.
    Personnellement, je suis un adepte de C++ + QT. Et franchement, à part pour des application Internet, java ne fait pas le poids !

  2. #222
    Membre actif
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 255
    Points
    255
    Par défaut Le vrai pb de C++: la standardisation
    Je crois que comme certain l'on peut être déjà dit (mais chui pas sûr), le vrai problème de C++ est le manque de biblio standard de haut niveau, et je trouve que là c'est un serieux problème, lorsqu'on doit par exemple maintenir un code qui a été écrit par une tierce personne, car la probabibilité qu'il ait utilisé une bibliothéque qu'on ignore totalement est beaucoup plus élévé qu'en Java. (ce qui va dimunier la productivité)

  3. #223
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 495
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 495
    Points : 17 584
    Points
    17 584
    Par défaut
    Citation Envoyé par kisitomomotene
    Je crois que comme certain l'on peut être déjà dit (mais chui pas sûr), le vrai problème de C++ est le manque de biblio standard de haut niveau,
    tout à fait mais cela ne se fait pas parce que les éditeurs d'OS se font la guerre Voir Java , Sun vs M$...
    Si Sun et M$ se seraient mis d'accord sur un standard commun de telles biblios existeraient

  4. #224
    Membre du Club
    Profil pro
    Inscrit en
    octobre 2005
    Messages
    38
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : octobre 2005
    Messages : 38
    Points : 65
    Points
    65
    Par défaut
    Citation Envoyé par Mat.M
    tout à fait mais cela ne se fait pas parce que les éditeurs d'OS se font la guerre Voir Java , Sun vs M$...
    Si Sun et M$ se seraient mis d'accord sur un standard commun de telles biblios existeraient
    Il y a de toute façon une abstraction trop faible entre la plateforme d'execution et le langage C++ pour que soit viable comme idée, au contraire du langage Java.

    C++ est un langage, ni plus ni moins. Et Java est un langage qui s'accompagne d'un environnement d'execution ( sa machine virtuelle et son framework de classes ), son abstraction le lui permettant.

    Comparer les deux, c'est un peu comme comparer la grammaire française et un dictionnaire anglais.

    Alexis.

  5. #225
    Provisoirement toléré
    Inscrit en
    décembre 2006
    Messages
    146
    Détails du profil
    Informations forums :
    Inscription : décembre 2006
    Messages : 146
    Points : 66
    Points
    66
    Par défaut
    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.
    Je me suis vu dans une glace hier, et c'était la première fois!
    La nouvelle c'est que je ne suis que moitié homme, l'autre moitié et hors service!
    PS: La partition de mon corps se fait verticalement!!

  6. #226
    Membre à l'essai
    Inscrit en
    février 2007
    Messages
    14
    Détails du profil
    Informations forums :
    Inscription : février 2007
    Messages : 14
    Points : 16
    Points
    16
    Par défaut C++ vs Java un point de vue !!
    Slt tt le monde,

    je ss en retard pr rentrer ds ce sondage , et je n'arrive pas a lire tous les citations.

    D'abord pour comprendre la diffrence entre les deux langauges de programmation évoluée C/C++ & Java il faut en jetter un coup d'œil ,et ca pr les deux langauges.

    D'apres mn point de vue la diffrence se présente au niveau des bibliotheques standards disponibles. Java offre un ensemble des outils et fonctions prédéfinis qui gèrent des applications et des manipulations de grande taille vous pouvez remplcer une cinquantaine de lignes avec une seule instruction. Mais j'ai rencontré une diffeculté lors de mn premeir contact avec le Java c'est la manipulation des flux; j'ai pas trouvé des fonctions directes comme c'est le cas pour le C++ ou C.

    Egalement une diffrence au niveau de la POO (Programmation Orienté Objet)
    lorsqu'on parle de l'heritage (heritage multiple, class abstraite, fonction virtuelle,...) ;les conversion de types; la notion du pointeur (passage de parametres,..)

    En C/C++ si vous vs ne metrisez pas la notion des pointeurs vous aurez des resultats étonnantes. En C/C++ il faut tous definir , n'exploiter pas la notion PAR DEFAUT mais en Java ca fonctionne.

    En conclusion je voix qu'on peut comparer les langauges de programmation mais on peut pas dire que le mielleur c'est x ou y plutôt on peut spécifier un langauge à un certain type de programmation (Graphique, scietifique, ...).

  7. #227
    Candidat au Club
    Profil pro
    Inscrit en
    mars 2007
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 2
    Points : 2
    Points
    2
    Par défaut 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.

  8. #228
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 495
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 495
    Points : 17 584
    Points
    17 584
    Par défaut
    Citation Envoyé par Melnofil
    *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 !
    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

  9. #229
    Candidat au Club
    Profil pro
    Inscrit en
    mars 2007
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 2
    Points : 2
    Points
    2
    Par défaut
    Citation Envoyé par Mat.M
    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.
    Un programme subit les mêmes contraintes d'OS & vitesse CPU qu'il soit programmé en C++ ou en Java.

    Citation Envoyé par Mat.M
    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
    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).

  10. #230
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Melnofil
    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 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).



    Citation Envoyé par Melnofil
    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.
    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++

  11. #231
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par adiGuba
    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 !
    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 )

    Citation Envoyé par adiGuba
    [*]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...[/list]

    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
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  12. #232
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par gorgonite
    + 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
    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 ?

    Citation Envoyé par gorgonite
    + 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
    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).


    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!


    Les optimisations d'un programme C++ et Java ne se situent pas au même endroit ni au même moment

    a++

  13. #233
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 495
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 495
    Points : 17 584
    Points
    17 584
    Par défaut
    Citation Envoyé par Melnofil
    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..

  14. #234
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par adiGuba
    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!

    Les optimisations d'un programme C++ et Java ne se situent pas au même endroit ni au même moment

    elles ne se situent pas au même endroit, car java a surtout oublié d'en faire


    edit par ailleurs, il y a de nombreux que peu de gens prennent en compte... comme le nombre d'instructions exécutées pour une instruction utile dans une machine virtuelle, contrairement à un code 100% compilé qui effectue chaque instruction "utilement" (cf papier de riccardi sur les machines virtuelles)


    perso, j'ai pas besoin d'aller voir ce papier... j'ai les sources de la machine virtuelle java officielle : elle fait partie intégrante de mon stage, donc je peux affirmer connaître un peu
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  15. #235
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par gorgonite
    elles ne se situent pas au même endroit, car java a surtout oublié d'en faire
    Si on pouvait éviter de partir en troll ce serait bien


    Citation Envoyé par gorgonite
    edit par ailleurs, il y a de nombreux que peu de gens prennent en compte... comme le nombre d'instructions exécutées pour une instruction utile dans une machine virtuelle, contrairement à un code 100% compilé qui effectue chaque instruction "utilement" (cf papier de riccardi sur les machines virtuelles)
    Et qu'est-ce que tu appelles une instruction utile exactement ?
    Il y a quelques années un débat similaire avait lieu entre le C et le C++ trop lourd à cause de ses concepts objets...

    Faudrait-il s'en passer pour n'avoir que des instructions "utiles" ?

    (au passage je n'ai pas retrouvé ce papier de riccardi sur les machines virtuelles... si tu a un lien j'y aurais bien jeté un coup d'oeil )


    a++

  16. #236
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par adiGuba
    Et qu'est-ce que tu appelles une instruction utile exactement ?
    Il y a quelques années un débat similaire avait lieu entre le C et le C++ trop lourd à cause de ses concepts objets...

    Faudrait-il s'en passer pour n'avoir que des instructions "utiles" ?
    pas du tout...
    je parle d'instructions utiles au sens d'instructions exécutées pour faire le boulot du programme...
    contrairement à celles qui sont ajoutées pour faire le boulot de la machine virtuelle

    Citation Envoyé par adiGuba
    (au passage je n'ai pas retrouvé ce papier de riccardi sur les machines virtuelles... si tu a un lien j'y aurais bien jeté un coup d'oeil )
    http://citeseer.ist.psu.edu/rd/43437...optimizing.pdf
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  17. #237
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par gorgonite
    pas du tout...
    je parle d'instructions utiles au sens d'instructions exécutées pour faire le boulot du programme...
    contrairement à celles qui sont ajoutées pour faire le boulot de la machine virtuelle
    Le boulot de la machine virtuelle est justement de laisser le développeur se concentrer sur le code métier... je ne pense pas que ce soit inutile !


    (Je comprend pourquoi je ne trouvais pas, je cherchais une message de riccardi sur le forum )

    Ca à l'air intéressant et j'essayerais d'y jeter un coup d'oeil quand j'aurai le temps... mais ce n'est pas vraiment d'actualité : ca date de 1998 (et donc de Java 1.2, la première JVM de Sun à intégrer un compilateur JIT). 9 ans après les techniques des JIT ont quand même évoluées...


    a++

  18. #238
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par adiGuba
    Le boulot de la machine virtuelle est justement de laisser le développeur se concentrer sur le code métier... je ne pense pas que ce soit inutile !
    rien à voir...
    la machine virtuelle permet surtout d'avoir normalement le meme code sur différentes architecures physiques différentes, mais peuvent parfaitement etre très bas niveau, et obliger le développeur a comprendre le RTL de la machine



    Citation Envoyé par adiGuba
    (Je comprend pourquoi je ne trouvais pas, je cherchais une message de riccardi sur le forum )

    Ca à l'air intéressant et j'essayerais d'y jeter un coup d'oeil quand j'aurai le temps... mais ce n'est pas vraiment d'actualité : ca date de 1998 (et donc de Java 1.2, la première JVM de Sun à intégrer un compilateur JIT). 9 ans après les techniques des JIT ont quand même évoluées...

    je sais parfaitement qu'elles ont évoluées, et j'ai d'ailleurs des papiers beaucoup plus récents (normal, c'est mon domaine d'étude), mais ce papier reste une référence... ce qui y ait écrit est valable pour toutes machines virtuelles à jeu d'instructions assez bas niveau
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  19. #239
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 495
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 495
    Points : 17 584
    Points
    17 584
    Par défaut
    Citation Envoyé par adiGuba
    Si on pouvait éviter de partir en troll ce serait bien

    Et qu'est-ce que tu appelles une instruction utile exactement ?
    Il y a quelques années un débat similaire avait lieu entre le C et le C++ trop lourd à cause de ses concepts objets...

    Faudrait-il s'en passer pour n'avoir que des instructions "utiles" ?
    a++
    la grosse différence entre Java et C++ c'est que la couche objet pour C++ tu as des pointeurs "live" pour accéder directement à la mémoire : un jmp ou mov <adresse> ,valeur ou registre en assembleur c'est direct ça consomme pas forcément beaucoup de cycles CPU donc la différence entre C et C++ peut être minime.
    En java c'est radicalement différent c'est du pseudocode à réinterpréter , faut vérifier s'il n'y pas d'exceptions , s'il n'ya pas d'erreur mémoire avec le Garbage Collector....donc tout cela ça fait beaucoup de traitement...

  20. #240
    Expert éminent

    Avatar de christopheJ
    Profil pro
    Inscrit en
    avril 2004
    Messages
    1 600
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Indre et Loire (Centre)

    Informations forums :
    Inscription : avril 2004
    Messages : 1 600
    Points : 8 232
    Points
    8 232
    Par défaut
    Attention a tout ce qui est idées reçues sur la gestion mémoire dans la JVM et coût du GC sur les perfs :
    Brian Goetz qui fait beaucoup contre les mythes Java à dit :
    http://java.sun.com/developer/techni.../goetz_qa.html
    Citation Envoyé par Brian Goetz
    question : Are there any other myths that you want to touch on?

    answer : One older myth that unfortunately persists is that object allocation is expensive. In the J2SE 1.0 and 1.1 days, object allocation was expensive. But garbage collectors have greatly improved, and the cost now of allocating an object in the Java language is less expensive than in C by a factor of four or five, according to data I've seen. The fast-path object allocation for new objects in Java software is on the order of 10 machine instructions, which requires fewer than 10 cycles on most processors. C can't come close to that. In memory management, Java technology is already significantly faster than C, and yet people incorrectly believe that it's expensive and that developers should preallocate and pool their objects.

    question : Why do people find it so surprising that allocation is faster in Java applications than in C?

    answer : They make outmoded assumptions about how garbage collection works. Because software architects have been thinking about garbage collection for 45 years, garbage collection is far more advanced than people realize.

    In order to get the appearance of garbage collection in C++, you use reference counting -- which requires overloading a number of operators, adding overhead to many operations -- plus, you still use malloc/free for memory management. People assume that garbage collection in the Java language works the same way, but in fact, it does nothing of the sort.

    The garbage collector in contemporary JVMs doesn't touch most garbage at all. In the most common collection scenario, the JVM figures out what objects are live and deals with them exclusively -- and most objects die young. So by the time they get to garbage collection, most objects that have been allocated since the last garbage collection are already dead. The garbage collector avoids a lot of work it would have to do if it were doing it one piece at a time. Similarly, the JVM can optimize away many object allocations. These are just a few examples of how moving memory management out of the libraries and into the platform enables huge performance improvements.
    Le reste de l'interview est très interessant aussi.

Discussions similaires

  1. [Débat] Technologie .NET vs JAVA
    Par neo.51 dans le forum Débats sur le développement - Le Best Of
    Réponses: 1047
    Dernier message: 14/01/2019, 16h15
  2. [Débat] .NET vs JAVA/J2EE
    Par tssi555 dans le forum VB.NET
    Réponses: 5
    Dernier message: 10/12/2008, 07h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo