On 26 jan, 23:51, "Cl.Massé" :
| Jean-Christophe :
| (...) faire croire que compiler un code avant de l'exécuter
| serait AUSSI RAPIDE que d'exécuter directement du code natif.
Post by Cl.MasséNon, la machine virtuelle Java exécute un jeu d'instruction
qui est le même sur toutes les plateformes.
Et qui est bien moins rapide qu'un simple exécutable.
Ce 'jeu d'instruction' n'est toujours pas du code
machine natif compatible avec le uP de la machine hôte :
la machine virtuelle doit donc exécuter une phase supplémentaire
avant d'appeler du code de bas niveau exécutable par ce uP;
cela ajoute un overhead qui ralentit l'exécution.
Sans compter - entre autres - l'inefficacité notoire du
garbage collector des machines virtuelles Java (et autres bugs)
qui n'ont rien à voir avec l'algorithme du programme source.
Post by Cl.MasséLe code Java est compilé (ou plutôt assemblé) à
l'avance pour ce jeu d'instructions. Ce n'est ni
une compilation just in time, ni une interprétation.
Par définition, si, puisque ce code n'est pas natif.
La grosse machine virtuelle doit faire le lien entre
le bytecode et les appels de bas niveau, sinon l'algo
programmé à l'origine en Java ne tournerait pas du tout.
En résumé, un algo écrit en Java n'est pas utilisable
avant d'être fourni à l'utilisateur; c'est la machine de
l'utilisateur (avec N machines virtuelles installées)
qui doit refaire tout le boulot à chaque fois.
Post by Cl.MasséIl y a forcément une perte de performance
mais elle n'est pas énorme
Ce critère dépend du programme que l'on fait tourner.
Comme je l'ai déja souligné, s'il s'agit d'un
jeu de morpion alors la vitesse n'est pas critique
et Java sera assez bon pour cela;
s'il s'agit par contre d'un algo qui consomme
du temps et des ressources alors Java est un boulet.
Il suffit de recenser les utilisations de Java pour noter
qu'on ne l'utilise jamais quand on a besoin d'efficacité.
Préférer la portabilité à l'efficacité ne se rencontre
guère que pour des softs sans importance, ou sur le Net.
Post by Cl.Masséet c'est le prix à payer pour la compatibilité.
Tout à fait d'accord. Comme tu seras d'accord
avec le fait qu'on accepte de payer ce prix
UNIQUEMENT lorsque l'application finale
est peu regardante quant aux performances.
En pratique on préfère largement compiler deux fois
un source pour cible Mac puis pour cible PC
afin d'obtenir deux exécutables en code machine natif,
ca s'appelle préférer l'efficacité à la portabilité.
(sans se trainer le boulet de machines virtuelles qui
ajoutent une floppée de déboires dont on se passe bien)
Post by Cl.MasséEt pis vu les performances des machines
d'aujourd'hui, franchement, hein?
C'est comme si tu disais "j'ai une voiture
de 100 CV, donc je peux me permettre de laisser
ces 4 sacs de sable de 150 kg dans mon coffre".
Tant que c'est toi qui payes, c'est ton droit.
Ta remarque s'applique aussi à une tendance relativement récente
des (jeunes) programmeurs à ne PAS optimiser leurs algorithmes,
d'une part parce-que ce n'est censé être visible par le client,
d'autre par parce-que ca permet de lui livrer le soft plus vite,
l'argument massue étant justement : "oui, on peut faire mieux,
mais on ne le fera pas car les machines d'aujourd'hui sont rapides"
Bref, non seulement on fourgue de la merde mais surtout on perd
le savoir faire qui consiste écrire des algos compacts et rapides.
C'est d'ailleurs une tendance générale dans bien des métiers,
ca aussi c'est la 'portabilité' - ou plutôt la portadébilité.
Post by Cl.MasséTu travailles sous DOS?
T'as encore une manivelle sur ta voiture?
Chez moi j'ai l'électricité (probablement d'origine nucléaire)
MAIS il m'arrive parfois de préférer m'éclairer
à la bougie lorsque, par exemple, je préfère
une ambiance plus douce pour un repas romantique.
Et toi, dans ce cas, tu t'éclaires avec des lampes à arc ?
