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
Rapidité entre C# -vs- C++ -vs- JAVA
Hello tout le monde...
Bon je pense que grand nombre d'entre vous vont me dire C++ mais maintenant avec les compilateur JIT (Just In Time) Le code que ce soit en JAVA ou en C# est compiler en code natif avant ça première exécution donc en théorie il devrait être aussi rapide que le C++... bon d'accord, le lancement de l'application sera un peu plus lent car il est compiler mais une fois cette étape passé....????
Quelle est votre avis ???
Y a t'il des testes qui ont déjà été fait ???
Merci
Je ne connais pas C#, mais même compilé Java reste plus lent que le C++ car il n'est pas conçu pour les records de vitesse (pas de pointeurs).
oki...
Personnes d'autres a des infos ?
Bah, C# et Java grâce à leur compilateur JIT permettent de faire des optimisations que les compilateurs C++ ne peuvent pas faire, parce qu'ils ne peuvent qu'agir statiquement.
Il y a donc forcément des cas où C# et Java sont plus rapides que C++.
D'ailleurs, C# et Java en tu manipules pas les pointeurs en général, sauf C# qui te permet de programmer en mode unsafe et là tu peux (Java je sais pas).
En pratique, C# à 90-95% des performances de C++.
Ce qu'on dit de C#/Java :
Avantages par rapport à C++, c'est que tu perds pas de temps pour la gestion de la mémoire, t'es plus productif
T'as beaucoup de bibliothèques à disposition directement, qui te permettent de faire plein de choses direct.
Là où C++ pêche, parce qu'il faut chercher les bonnes bibliothèques. Bon c'est plus trop vrai, parce que souvent l'IDE vient avec un bon SDK, bibliothèques de classes utiles. Puis sous Linux souvent t'as QT, GTK...
Mais les gens sont réticents pour C# parce que c'est Microsoft, .NET et tout, ils s'en méfient.
Sache qu'au niveau de la gestion mémoire, Java est plus rapide que C/C++, quand il s'agit d'allouer et désallouer.
Que programmer quelque chose qui gère efficacement la mémoire est très difficile quand ça devient complexe, et que faire mieux qu'un Garbage Collector (GC) est une tâche de surhomme.
C'est pour ça qu'on passe un certain temps en C++ pour faire des managers. Mais bon, souvent on fait moins bien que le GC.
En C++ pour compenser ce désavantage, il y a une super bibliothèque qui s'appelle Boost.
Elle contient beaucoup de choses, dont les smart_pointers, sous forme de shared_ptr et array_ptr j'crois.
En plus, tu peux programmer en style fonctionnel assez bien optimisé, grâce à la méta-programmation (bon, faut un bon compilateur). Expressions lambda, n-uplets.
Je ne comprends pas cet argument. Si on compile le code à l'aide du compilateur JIT alors il est compilé et le compilateur ne peu plus faire d'optimisation quand il est exécuté. Cependant s'il n'est pas compilé jusqu'au niveau de la machine alors l'interpréteur peut faire des optimisations de ce genre mais alors on n'a plus de JIT.Envoyé par HanLee
D'ailleurs j'ai entendu que MS essaie à créer un inventaire de code compilé pour les programmes CLI. C'est à dire Windows ne compile un programme CLI que la première fois, qu'il est lancé, et puis stock le code compilé pour accélérer tout lancement postérieur de ce programme.
On ne doit cependant pas oublier que C++ propose de nombreuses alternatives à la gestion de la mémoire direct. Par exemple std::vector ou boost::shared_ptr. Je dirais plutôt qu'on doit avoir plus expérience qu'en Java pour pouvoir écrire du code C++ vite. Cependant si on le peut alors je ne crois pas qu'on serait moins productif. Je dirais même que le solutions spécialisés tel que std::vector accéléraient le développement s'ils sont employées dans les bonnes situations.Avantages par rapport à C++, c'est que tu perds pas de temps pour la gestion de la mémoire, t'es plus productif
Ceci est cependant uniquement vrai s'il y a pendant l'exécution du programme des fenêtres de temps où on peut exécuter le GC sans devoir interrompre une autre procédure. Les interfaces graphiques sont de bons exemples. Le temps de réaction de l'utilisateur est assez grand pour l'utiliser à collecter de la mémoire. Cependant les programmes de traitement de vidéo sont un exemple où cette stratégie de gestion de la mémoire n'est pas optimale. Le GC doit être lancé par exemple pendant l'application d'un filtre et on perd l'avantage de vitesse.Sache qu'au niveau de la gestion mémoire, Java est plus rapide que C/C++, quand il s'agit d'allouer et désallouer.
Cependant ces facettes sont peu utilisées. Le problème est que les expressions lambda tel qu'il sont possible avec boost sont très lent de compilation.En plus, tu peux programmer en style fonctionnel assez bien optimisé, grâce à la méta-programmation (bon, faut un bon compilateur). Expressions lambda, n-uplets.
Ca je sais pas trop, demande l'avis d'expert C#/Java.Je ne comprends pas cet argument. Si on compile le code à l'aide du compilateur JIT alors il est compilé et le compilateur ne peu plus faire d'optimisation quand il est exécuté. Cependant s'il n'est pas compilé jusqu'au niveau de la machine alors l'interpréteur peut faire des optimisations de ce genre mais alors on n'a plus de JIT.
D'ailleurs j'ai entendu que MS essaie à créer un inventaire de code compilé pour les programmes CLI. C'est à dire Windows ne compile un programme CLI que la première fois, qu'il est lancé, et puis stock le code compilé pour accélérer tout lancement postérieur de ce programme.
Oui, c'est pour ça que j'en parle à la finOn ne doit cependant pas oublier que C++ propose de nombreuses alternatives à la gestion de la mémoire direct. Par exemple std::vector ou boost::shared_ptr. Je dirais plutôt qu'on doit avoir plus expérience qu'en Java pour pouvoir écrire du code C++ vite. Cependant si on le peut alors je ne crois pas qu'on serait moins productif. Je dirais même que le solutions spécialisés tel que std::vector accéléraient le développement s'ils sont employées dans les bonnes situations.Avantages par rapport à C++, c'est que tu perds pas de temps pour la gestion de la mémoire, t'es plus productif
J'pense que c'est grâce à cela que C++ arrive à rester compétitif, de par sa communauté active et ses bibliothèques.
Je parlais de malloc/new et compagnie, et pas du GCCeci est cependant uniquement vrai s'il y a pendant l'exécution du programme des fenêtres de temps où on peut exécuter le GC sans devoir interrompre une autre procédure. Les interfaces graphiques sont de bons exemples. Le temps de réaction de l'utilisateur est assez grand pour l'utiliser à collecter de la mémoire. Cependant les programmes de traitement de vidéo sont un exemple où cette stratégie de gestion de la mémoire n'est pas optimale. Le GC doit être lancé par exemple pendant l'application d'un filtre et on perd l'avantage de vitesse.Sache qu'au niveau de la gestion mémoire, Java est plus rapide que C/C++, quand il s'agit d'allouer et désallouer.
OuiCependant ces facettes sont peu utilisées. Le problème est que les expressions lambda tel qu'il sont possible avec boost sont très lent de compilation.En plus, tu peux programmer en style fonctionnel assez bien optimisé, grâce à la méta-programmation (bon, faut un bon compilateur). Expressions lambda, n-uplets.. Personnellement j'trouve le compilateur Microsoft de Visual C++ 2005 plutôt performant à ce niveau là
. Parce qu'avec boost::spirit j'ai bien senti le compilateur morfler
D'un côté c'est l'occasion de se sensibiliser aux techniques qui allègent le temps de compilation d'un programme + programmation modulaire
Puis d'un côté, vu que ça permet une bonne rédaction du code, de manière concise et claire, ce n'est pas vraiment un désavantage, avec les compilateurs qui savent recompiler que ce qui a été effectivement modifié !
Ah oui tiens j'y pense, c'est que la gestion des gros projets, ça peut être bancal, avec les headers qui trainent partout, par rapport à Java/C#.
Je n'aime pas contredire ce qu'un autre participant dit, mais il y a deux trois trucs avec lesquels je ne suis pas daccord.
Pas de pointeurs en Java : c'est un argument CONTRE Java, en terme de vitesse d'exécution, bien que ce soit un argument pour Java en terme de vitesse de développement. Le contrôle direct permet d'optimiser.
Le garbage collector : en C++, la libération de la mémoire est à la charge du concepteur. Il sait précisément quoi faire et à quel moment. Les erreurs sont faciles, mais un code bien conçu peut être efficace et rapide. Le garbage collector du Java est très générique. Etre capable de s'adapter à toutes les situations sans erreur imploique d'être assez lourd, Java a probablement à compter en permanence combien de pointeurs pointent sur chaque objet. Faire un garbage collector est très complexe, mais on ne crée pas de garbage collector en C++, on efface manuellement, pas automatiquement.
La compilation à la volée permet des optimisations intéressantes, car elle peut être exécutée juste pour la machine sur laquelle elle fonctionne. Cependant, ceci implique que la JVM ne peut pas passer tout son temps à chercher la petite bête car il ne faut pas traîner. Par ailleurs, les compilateurs C++ actuels sont des compilateurs optimiseurs extrémement performant car forts d'années d'expérience qui manquent à la compilation just in time de Java. Je dois cependant admettre que l''idée que les compilateurs Java optimisent moins bien n'est qu'une hypothèse, bien qu'une hypothèse raisonnable.
Hanlee a écrit :
Je n'était pas au courant de ceci. La JVM passe par l'OS comme le c++, n'est-ce pas? Qu'est-ce qui rend Java plus rapide?Sache qu'au niveau de la gestion mémoire, Java est plus rapide que C/C++, quand il s'agit d'allouer et désallouer.
Par ailleurs, le Java a une gestion des erreurs performante mais lourde, car des vérifications sont effectuées systématiquement. Le C++ ne fait des vérifications que si on lui demande. Ceci complique le débogage d'une application en C++, mais accélère l'exécution.
Java utilise une API générique, donc non optimisée. Le C++ utilise une interface spécialisée pour l'OS sur lequel il fonctionne.
Au final, je pense que même avec la compilation just in time Java n'est pas au niveau du C++. Ceci, principalement parce que ce n'est pas l'objectif du Java.
Mais quels que soient les arguments, seul un test pourrait les départager avec certitude. Il faudrait créer un grand nombre d'applications en utilisant les deux langages, mais ce serait beaucoup de travail. J'aimerai toutefois faire remarquer que toutes les applications Java que j'ai utilisé sont plus lentes que leur équivalent C. (Par exemple : Eclipse rame sur des machines qui font fonctionner VC++ sans problème.)
Il y a tout un débat ici:
http://www.developpez.net/forums/vie...asc&highlight=
Les experts en Java/C# vous répondront hein =P, dans le sens ils connaissent les dernières nouveautés.
Moi je ne fais que du C++.
Il me semble qu'il existe des GC en C++ je crois.
Non mais en fait je voulais dire, parfois on aimerait bien se passer de la gestion de la mémoire à des endroits non critiques, c'est là où on aimerait bien avoir un GC.
Oui ne pas pouvoir utiliser de pointeurs c'est un argument contre Java quand tu voudrais optimiser rigoureusement, d'où ma préférence pour C#.
Là on a le choix entre code unsafe et safe.
Pour Java et compilation JIT, je sais juste que les dernières versions de Java sont très optimisées, et que même si j'aime pas trop Java par rapport à C#, faudrait tordre le coup aux préjugés d'antan.
Certains défauts restent.
Si on parle de la gestion de la mémoire à la méthode Java alors on doit parler du GC. Le problème est que les allocations et libérations ne sont pas presque gratuites en Java. Les coûts ne sont que reportés dans le future jusqu'à un moment où on n'a rien mieux à faire. Cependant si on repousse trop ce moment alors on arrive au point où la mémoire est pleine et on doit payer les coûts.Je parlais de malloc/new et compagnie, et pas du GC
N'oublie pas que les références Java partagent beaucoup de caractéristique avec les pointeurs.
Non, le GC ne fonctionne pas avec la même méthode que boost::shared_ptr.
Une allocation a le même coût qu'une addition et la libération est gratuite. Les références Java correspondent à des indexes dans un tableau de pointeurs donc la copie d'une référence correspond à la copie d'un pointeur. L'accès à l'objet référencié est plus coûteux qu'il ne l'est pour un pointeur comme on a une double indirection.
Pour collectionner les objets qui ne sont plus utilisés le GC d'abord marque tous les objets comme non utilisés (ceci est possible sans visiter chaque objet). Puis il cherche tous les références automatiques et marque ces objets comme utilisés. Pour chaque un de ces objets il cherche les objets qu'ils référencent. Avec cette méthode il peut déterminer quels objets sont à garder. Après cette étape il met ces objets l'un après l'autre dans la mémoire. Ceci est possible grâce au tableau de pointeurs. Le reste de la mémoire est alors marqué comme libre.
Un des grand avantage de cet procédure par rapport est à boost::shared_ptr est qu'on n'a plus de problème avec des références cyclique. Le grand et à mon avis unique désavantage par rapport à boost::shared_ptr est la double indirection.
Là je ne suis pas de ton avis. En C++ on doit éviter la gestion de la mémoire manuelle.
La méthode la plus élégante est de créer différents stratégies réutilisable tel que std::vector ou boost::shared_ptr. Cependant la gestion manuelle doit être limitée à ces classes. En dehors la gestion se fait automatiquement mais pas uniformément.
GCC par exemple propose aussi d'optimiser un programme pour un certain processeur. Cependant si on veut distribuer son application sous forme binaire alors ce n'est probablement pas une option. Mais on pourrait offrir différents exécutable pour différents processeur.
Il alloue un grand bloc et puis fait tous manuellement car le modèle est incompatible avec celui proposé par de nombreuse systèmes d'exploitation.
Du fait qu'une API est générique tu ne peux pas déduire quelle est forcément plus lente. Il se peut qu'après optimisation il n'en reste rien.
Il n'en existe pas qui pourrait tenir le coup contre un GC Java.
Tu démontres ici une lourde méconnaissance du domaine des GCs : ce dont tu parles (garder le compte des références vers un objet) n'est pas du tout la méthode de Java qui emploie un GC bien plus performant.
La compilation statique peut aussi s'effectuer spécifiquement pour la machine sur laquelle on compile, même si la plupart des programmes distribués sont compilés simplement pour du i386 génériques (cependant certains, par exemple s'ils sont compilés par icc, ont tout de même plusieurs code possibles pour une même section, et la plus performante selon le processeur est sélectionnée à l'exécution). Mais la JIT permet d'autres optimisations, parce qu'elle se fait à l'exécution, par exemple on connaît déjà les paramètres, on peut ainsi faire sauter des sections entières de test dans des boucles, qu'il faudrait sinon exécuter plusieurs fois... (ce n'est qu'un exemple maladroit et je ne sais même pas s'il est vraiment implémenté, il n'en reste pas moins que certaines optimisations sont beaucoup plus faciles pour un compilateur JIT).La compilation à la volée permet des optimisations intéressantes, car elle peut être exécutée juste pour la machine sur laquelle elle fonctionne. Cependant, ceci implique que la JVM ne peut pas passer tout son temps à chercher la petite bête car il ne faut pas traîner. Par ailleurs, les compilateurs C++ actuels sont des compilateurs optimiseurs extrémement performant car forts d'années d'expérience qui manquent à la compilation just in time de Java. Je dois cependant admettre que l''idée que les compilateurs Java optimisent moins bien n'est qu'une hypothèse, bien qu'une hypothèse raisonnable.
Encore un point : les compilateurs C++ sont assez mauvais généralement, ils ont beaucoup de mal à utiliser les sets d'instructions avancés (SSE, MMX,....) (icc est le meilleur dans ce domaine), il y a pas mal d'optimisations qu'il n'implémentent pas, ils produisent du code plus lourd qu'ils ne devraient (comparer le même code compilé avec gcc et g++). Et de toute façon l'important dans la conception d'un compilateur est surtout l'implémentation de la théorie (qui a un train d'avance sur la pratique), de ce fait un compilateur récent a peut-être même un avantage sur un compilateur ancien (qui a été bâti sur des bases qui ne permettent peut-être pas d'utiliser les dernières avancées).
Java gère lui-même l'espace qu'il alloue, donc non il ne passe pas par l'OS à chaque allocation, et souvent cela permet une gestion plus performante de l'allocation, d'autant plus qu'il utilise un GC.Hanlee a écrit :
Je n'était pas au courant de ceci. La JVM passe par l'OS comme le c++, n'est-ce pas? Qu'est-ce qui rend Java plus rapide?Sache qu'au niveau de la gestion mémoire, Java est plus rapide que C/C++, quand il s'agit d'allouer et désallouer.
Après cela ne signifie pas que Java est plus rapide que le C++, car tous ces points ne sont que des compensations pour la nature non compilée de Java, d'autant qu'il y a des GC en C++, des allocateurs, etc... D'ailleurs je trouve Java lourd et surévalué et pour tout dire je n'aime pas vraiment ce langage, néanmoins il ne faut pas dire de bétises dessus, ça ne fait qu'aider ses supporters quand ils peuvent corriger des contres-vérités.
--
Jedaï
Non, elle se fait au démarrage et non pas à l'exécution.
Un interpréteur le pourrait mais un compilateur, JIT ou non, ne le peut pas.
.... JIT = Just in Time, révisez la définition de cette technique ! Quoi que fasse la JVM (et j'ai déjà dit que Java n'était pas ma tasse de thé, je ne connais donc pas les détails du fonctionnement de la JVM), la JIT est bien plus large qu'une simple compilation avant que le programme soit lancé (qui ne présenterais aucun avantage sur une compilation statique, je doute donc que la JVM fasse ainsi), elle se fait la plupart du temps durant l'exécution du programme et peut se faire sur des morceaux du code : par fichier, ou par fonction. Et une VM avec JIT est un interpréteur qui compile les morceaux critiques du code, elle est donc tout à fait capable de faire l'optimisation décrite ci-dessus.Non, elle se fait au démarrage et non pas à l'exécution.
Un interpréteur le pourrait mais un compilateur, JIT ou non, ne le peut pas.
--
Jedaï
Jedaï a tout a fait raison. Le JIT peut se declencher quand il veut pour compiler des parties de code. (par exemple, le JIT de la JVM java cliente se declenche plus vite, et fait moins d'optimisation que la version serveur qui attends d'avoir plus d'info sur le code et comment il est utilisé pour compiler).
un exemple simple : inliner : si tu as une methode qui est appelée tres régulierement, il s'avere en général plus rapide de la recopier partout (lors de la compilation) que de faire un appel a une unique methode: le JIT va detecter ca et le faire alors que la compilation ahead of time va s'en passer.
[b]HanLee a écrit :[b]
Si j'ai bien compris, on cherche ici a optimiser en vitesse pure à l'exécution. La plus grande complexité est un prix à payer.Il me semble qu'il existe des GC en C++ je crois.
Non mais en fait je voulais dire, parfois on aimerait bien se passer de la gestion de la mémoire à des endroits non critiques, c'est là où on aimerait bien avoir un GC.
Oui ne pas pouvoir utiliser de pointeurs c'est un argument contre Java quand tu voudrais optimiser rigoureusement, d'où ma préférence pour C#.
Là on a le choix entre code unsafe et safe.
[b]HanLee a écrit :[b]
C'est vrai. Je pense qu'à ce stade, l'argument bytecode contre code natif n'a plus beaucoup de poids. Cependant, il y a d'AUTRES aspects qui me font penser que C++ est plus rapide.Pour Java et compilation JIT, je sais juste que les dernières versions de Java sont très optimisées, et que même si j'aime pas trop Java par rapport à C#, faudrait tordre le coup aux préjugés d'antan.
ben04 a écrit :
Ben oui, c'est pratiquement la même chose, mais je ne peux pas faire ptr++ (ce n'est qu'un exemple). Ou même des horreurs comme (int *) (((int) ptr1 + (int) ptr2) / 2) quand je fais une recherche par dichotomie.N'oublie pas que les références Java partagent beaucoup de caractéristique avec les pointeurs.
ben04 a écrit :
Pourquoi? Pour éviter les fuites de mémoire? On code ses delete soi-même et après on débogue. Pour optimiser il faut payer le prix. Ce serait comme de dire qu'une Ferrari n'est pas plus rapide qu'une Twingo parce que vous ne dépassez jamais le 30 par sécurité.Là je ne suis pas de ton avis. En C++ on doit éviter la gestion de la mémoire manuelle.
[b]HanLee a écrit :[b]
En théorie... dans la pratique c'est rarement le cas. J'admets cependant mon inexpérience dans ce domaine.Du fait qu'une API est générique tu ne peux pas déduire quelle est forcément plus lente. Il se peut qu'après optimisation il n'en reste rien.
[b]HanLee a écrit :[b]
Intéressant, mais hors sujet, pouisque quand on fait de la vitesse pure on ne se sert pas d'un GC.HanLee a écrit:
Il me semble qu'il existe des GC en C++ je crois.
Il n'en existe pas qui pourrait tenir le coup contre un GC Java.
[b]Jedai a écrit :[b]
On ne peut pas optimiser parce qu'on connaît déjà les paramêtres, puisque les paramêtres changent avec chaque appel à la méthode. A moins de recompiler à chaque appel. Ouch.par exemple on connaît déjà les paramètres
[b]Jedai a écrit :[b]
C'est pour ça qu'on en choisit un bon.Encore un point : les compilateurs C++ sont assez mauvais généralement
C'est vrai, je ne connais pas le fonctionnement du GC. Néanmmoins, quel que soit sont fonctionnement, il lui faut déterminer le moment où effectuer l'effacement. C'est une charge, quelle que soit la méthode. En C, on appelle delete au bon moment.
Java alloue un grand bloc d'un coup? Rien à redire, celà doit effectivement être plus rapide. Cependant, ça ne fait qu'un point pour Java.
Il y a encore d'autres arguments que je n'ai pas cité. Par exemple :
pas de inline en Java
charge de la JVM
Et probablement d'autres auxquels je n'ai pas encore pensé.
Mais ça ne sert pas vraiment à grand chose de continuer à chercher. Les deux langages ont une philosophie différente. Pour le Java, les priorités sont la portabilité, la robustesse, etc... La rapidité d'éxécution n'est pas négligée, mais reste secondaire pour Java. En C++, la vitesse est une des priorités. A moins de supposer que les développeurs de C++ soient incompétents, C++ doit être plus rapide.
Enfin et surtout, vous oubliez l'argument le plus important. Le simple constat que sur des applications existantes équivalentes, le C++ est plus rapide.
Selon ta définition cette optimisation est possible. Désolé, c'était donc un malentendu.
Mais qui ne présenterais non plus les inconvénients.(qui ne présenterais aucun avantage sur une compilation statique, je doute donc que la JVM fasse ainsi)
Je ne sais pas si la compilation JIT (selon ta définition) serait capable de récupérer le temps perdu dans la compilation pendant l'exécution de code optimisé. Il y a certainement des situation où ce serait possible mais l'analyse du code n'est pas gratuite non plus et garder un analyse complète d'un programme tous le temps en mémoire risque de consommer énormément d'espace.
Et d'ailleurs ce n'est pas qu'un compilateur compilant tous le code une fois serait incapable de cette optimisation. On peut très bien faire une analyse du code à cette étape et introduire des blocs if dans le code pour traiter des cas spéciaux où une optimisation spécifique peut être appliquée.
Les compilateurs JIT sont extrèmement rapides, car ils travaillent à partir du bytecode, beaucoup plus abordable pour la machine. Il ne s'agit pas du JIT "selon ma définition, mais du JIT selon la définition communément admise, ce dont tu parles s'apparente à la compilation normale...
(BugFactory : le inline en Java est pratiqué par la JIT après analyse des performances dans le cas de la JIT "server" et le GC n'a jamais besoin de surveiller s'il doit effectuer une suppression : il se déclenche simplement lorsqu'on a besoin de place (vérification faite lors d'une allocation) ou si on le lui demande explicitement. Par ailleurs je suis bien d'accord que les applications en C++ sont plus rapides qu'en Java, c'est juste qu'il vaut mieux éviter les arguments faux dans un débat)
--
Jedaï
Ah j'ai retrouvé un lien d'IBM...
http://www-128.ibm.com/developerwork...-jtp09275.html
A propos de la gestion de la mémoire des application C++ :
ils disent que des gens ont essayé sur diverses applications C/C++ de supprimer toute la gestion de la mémoire faite à la main, et de les remplacer à l'aide un GC qui était pourtant rudimentaire.
Ben ça a considérablement boosté les performances. Moi j'considère que c'est un argument en faveur des GC parce que les gros programmes passent une grande partie de leur temps à allouer/désallouer de la mémoire.
D'autant plus que prétendre optimiser à la main la gestion de la mémoire d'un programme conséquent, mieux qu'un GC, je ne vous croirai pas, sauf si vous étiez parmi ceux qui sont dans les majors des concours Mines/Centrale-Supélec, eux sont comparables à des machines, rapides, efficaces...
Parce qu'un GC performant, il agit dans du local, et sur le fonctionnement global du programme. Nous on a pas assez de recul sur le fonctionnement du programme, on a un aperçu d'une situation particulière, ou alors si elle est générale, elle l'est trop.
Ce lien était intéressant, je vois que beaucoup de choses que j'avais rangées dans la catégorie "hypothèses raisonnables" étaient fausses. Plus important, cet article s'appuie sur des tests. J'en suis à regretter qu'on ne puisse pas surcharger les opérateurs new et delete... On pourrait avoir un opérateur delete qui marquerait un objet comme obsolète pour être effacé par le garbage collector plus tard, ce qui donnerait un GC léger et performant.
En revanche, je ne vois toujours pas comment la compilation JIT pourrait faire gagner du temps en faisant des optimisations sur les paramêtres. Par exemple, mettons qu'on puisse optimiser une méthode si l'un des paramêtres est supérieur à zéro. Le compilateur fait ceci, et à l'appel suivant, le paramêtre est négatif! Pouf! On doit recompiler! Et en plus on doit vérifier que le paramêtre est positif à chaque appel. Par ailleurs, en supposant que le compilateur soit capable de remarquer que ce paramêtre serait en fait toujours positif, le programmeur aussi, et il aurait fait l'optimisation correspondante.
Beaucoup des optimisations de la compilation JIT supposent d'analyser le code en temps réel. C'est une charge supplémentaire. Par ailleurs, une détection ne peut être faite qu'après plusieurs cycles. C'est acceptable sur un serveur, pas sur un système temps réel.
(Note : dans mon post précédent, j'ai pu donner l'impression d'ignorer quelques unes de vos remarques : c'est parce que certains messages ont été postés pendant que je le tapais.)
Bien sûr, d'ailleurs pour la JVM, la solution a été de proposer deux "modes" de JIT : une "server" qui est utilisé pour les programmes tournant très longtemps et qui accumule des statistiques pour optimiser avec la JIT, et une "client" plus rudimentaire et se contentant de compiler avec des optimisations faisables par un vrai compilateur.
--
Jedaï
Je ne connais pas JAVA mais j'ai étudié un peu le GC et le JIT de .NET.
L'intérêt du GC par rapport à la gestion manuelle habituelle en C++ est la performance à l'allocation (new) et non à la libération. Apparemment le bénéfice est sensible et en plus, ça simplifie le travail du développeur.
Pour l'instant, la compilation du JIT est totale au lancement et ne se fait pas par morceau à l'appel des fonctions. L'intérêt est l'adaptation à la machine d'exécution et non la machine de développement (multiprocesseurs, SSE2 etc.).
Répondre avec citation
Partager