Mais ce ne sera jamais aussi rapide que du C (bien codé, bien compilé) qui restera aussi plus lent que de l'assembleur (bien codé) qui sera toujours plus lent qu'une puce spécialisée (bien architecturée)
Ca c'est justement ce que l'on a tendance a penser intuitivement. Et bien que ce soit vrai, la question est : "est-ce que c'est realisable".
Perso dans mon boulot j'ai rencontre un paquet de gens qui me disais que l'assembleur etait tres superieur au C au niveau optimisation, surtout en ce qui concerne le bas niveau. A tous ces gens la je leur ai demande d'ecrire un malloc qui soit thread-safe et qui batte le malloc GNU compile avec GCC. Ben j'attend toujours.
Le fait que ce soit possible ne veut pas dire que ce soit faisable. Il arrive que dans un projet on tombe sur une routine qui va etre appelee pleins de fois et que le compilateur va optimiser pour une utilisation generique, alors que, dans ce cas particulier, c'est justement ce qu'il ne faut surtout pas faire. Pour ce cas de figure l'assembleur va etre la methode a utiliser pour ameliorer les perfs. Mais l'immense majorite du code restera en C.
Aujourd'hui il est impossible por une equipe de taille normal d'optimiser un programme d'un bout a l'autre et de l'ecrire tout en assembleur. On peut deja considerer que les compilateurs "battent" les programmeurs assembleur dans 90% des cas.
Pour la JVM le meme question se pose, pour l'instant les bonus d'optimisation apportees par une JVM ne sont pas aussi fort que ceux apportes par un compilateur dans la majorite des cas. Mais on peut se demander si ca ne va pas s'inverser. Sur un processeur de type RISC pur (processeur dit a architecture "moderne") on sait deja qu'une dynamo (emulation du processeur sur lui meme) entrainne en moyenne une acceleration des perfs de l'ordre de 10% (oui vous avez bien lu), parceque certains couplages d'appels qui n'avaient pas pu etre fait par le compilateur deviennent possibles. Donc potentiellement une JVM peut ameliore l'execution d'un programme. Peut elle le faire suffisament pour que ca soit tres difficile de battre une JVM avec un compilo dedie architecture ? Pas pour l'instant, peut etre jamais. Mais ca pourrait fort bien arriver, et perso je pense que ca arrivera plus vite qu'on ne le pense.
[^] # Re: Comment ca va ? Java bien
Posté par Jerome Herman . En réponse au journal Comment ca va ? Java bien. Évalué à 4.
Ca c'est justement ce que l'on a tendance a penser intuitivement. Et bien que ce soit vrai, la question est : "est-ce que c'est realisable".
Perso dans mon boulot j'ai rencontre un paquet de gens qui me disais que l'assembleur etait tres superieur au C au niveau optimisation, surtout en ce qui concerne le bas niveau. A tous ces gens la je leur ai demande d'ecrire un malloc qui soit thread-safe et qui batte le malloc GNU compile avec GCC. Ben j'attend toujours.
Le fait que ce soit possible ne veut pas dire que ce soit faisable. Il arrive que dans un projet on tombe sur une routine qui va etre appelee pleins de fois et que le compilateur va optimiser pour une utilisation generique, alors que, dans ce cas particulier, c'est justement ce qu'il ne faut surtout pas faire. Pour ce cas de figure l'assembleur va etre la methode a utiliser pour ameliorer les perfs. Mais l'immense majorite du code restera en C.
Aujourd'hui il est impossible por une equipe de taille normal d'optimiser un programme d'un bout a l'autre et de l'ecrire tout en assembleur. On peut deja considerer que les compilateurs "battent" les programmeurs assembleur dans 90% des cas.
Pour la JVM le meme question se pose, pour l'instant les bonus d'optimisation apportees par une JVM ne sont pas aussi fort que ceux apportes par un compilateur dans la majorite des cas. Mais on peut se demander si ca ne va pas s'inverser. Sur un processeur de type RISC pur (processeur dit a architecture "moderne") on sait deja qu'une dynamo (emulation du processeur sur lui meme) entrainne en moyenne une acceleration des perfs de l'ordre de 10% (oui vous avez bien lu), parceque certains couplages d'appels qui n'avaient pas pu etre fait par le compilateur deviennent possibles. Donc potentiellement une JVM peut ameliore l'execution d'un programme. Peut elle le faire suffisament pour que ca soit tres difficile de battre une JVM avec un compilo dedie architecture ? Pas pour l'instant, peut etre jamais. Mais ca pourrait fort bien arriver, et perso je pense que ca arrivera plus vite qu'on ne le pense.
Kha