> C'est une comparaison 32bit x86 vs 64bit amd64 , la plus grande partie
> de ces perfs est due au fait que le l'amd64 a des registres en plus notamment.
Il y a aussi un avantage pratique (ou "stratégique"), non inhérent aux spécificités du x86_64, mais dû au champ d'utilisation du IA32 (et à son âge).
Dans le cas spécifique des distributions Linux (et je suppose que ça doit être aussi vrais pour certains binaires distribués pour win32), les binaires x86 sont compilés en ciblant la compatibilité avec les vieux pentiums 686 - quand ce n'est pas carrément la compatibilité avec les 486 (par ex. chez Debian). Dans tout les cas, lorsque ce n'est pas explicitement demandé (-mcpu & co), et en 32bits, GCC produit des binaires qui peuvent tourner tels quels sur un 486.
Les jeux d'instructions et fonctionnalités ultérieurs aux vieux pentiums ne sont généralement que peux exploités dans les paquets binaires pour Linux (ie. seulement si c'est suffisamment modulaire pour être activé dynamiquement, et si le développeur les a écrit explicitement à la main). Si bien que certaines distributions, qui s'efforcent de conserver la compatibilité avec les x86 pré-pentiums, distribuent deux paquets distincts pour la libc (une "libc" tout court et une libc-i686). Mais ce procédé, couteux en temps de maintenance, n'a pas été généralisé aux autres paquets.
En revanche, tout les x86_64 supportent les jeux d'instructions supportés par les pentium4, dont le compilateur peut alors tirer partis sans affecter la compatibilité. Aussi, les binaires x86_64 (qui n'existent que depuis peu) affranchissent le compilateur de ce besoin de rétro-compatibilité avec des processeurs vieux de presque 20 ans. GCC peut s'efforcer, avec plus ou moins de succès, d'exploiter les instructions et fonctionnalités des CPUs x86 modernes.
Je ne crois pas que ça fasse une très grande différence pour un navigateur comme firefox cela dit. D'après le blog d'un développeur de flash, ça ne change rien pour flash non plus, dans la mesure où les développeurs de ce logiciel écrivent eux même à ma main les parties critiques en assembleur optimisé modulairement selon les jeux d'instructions disponibles à l'exécution (ce qui fait, au passage, qu'il leur a fallu beaucoup de temps pour faire ce port x86_64 de flash).
Donc dans ce cas précis on peux supposer qu'il est peu probable qu'un flash 64 bits améliore les performances (en termes d'efficacité CPU uniquement, parce qu'être obligé d'avoir sur disque et chargé en mémoire les libs 32 bits, c'est quand même du gachis de ressources à mon gout). Mais en pratique, et dans le cas d'une distribution Linux, on ne peux pas généraliser ce constat en disant que le 64bits n'apporte aucun autre gain qu'un plus grand espace d'adressage.
Et je ne sais pas vous mais je vois malheureusement venir à grands pas le jour où firefox utilisera régulièrement plus de 3 Go de ram /o\
[^] # Re: la vraion raison
Posté par herodiade . En réponse au journal Flash version 64 bits pour linux exclusivement!. Évalué à 4.
> de ces perfs est due au fait que le l'amd64 a des registres en plus notamment.
Il y a aussi un avantage pratique (ou "stratégique"), non inhérent aux spécificités du x86_64, mais dû au champ d'utilisation du IA32 (et à son âge).
Dans le cas spécifique des distributions Linux (et je suppose que ça doit être aussi vrais pour certains binaires distribués pour win32), les binaires x86 sont compilés en ciblant la compatibilité avec les vieux pentiums 686 - quand ce n'est pas carrément la compatibilité avec les 486 (par ex. chez Debian). Dans tout les cas, lorsque ce n'est pas explicitement demandé (-mcpu & co), et en 32bits, GCC produit des binaires qui peuvent tourner tels quels sur un 486.
Les jeux d'instructions et fonctionnalités ultérieurs aux vieux pentiums ne sont généralement que peux exploités dans les paquets binaires pour Linux (ie. seulement si c'est suffisamment modulaire pour être activé dynamiquement, et si le développeur les a écrit explicitement à la main). Si bien que certaines distributions, qui s'efforcent de conserver la compatibilité avec les x86 pré-pentiums, distribuent deux paquets distincts pour la libc (une "libc" tout court et une libc-i686). Mais ce procédé, couteux en temps de maintenance, n'a pas été généralisé aux autres paquets.
En revanche, tout les x86_64 supportent les jeux d'instructions supportés par les pentium4, dont le compilateur peut alors tirer partis sans affecter la compatibilité. Aussi, les binaires x86_64 (qui n'existent que depuis peu) affranchissent le compilateur de ce besoin de rétro-compatibilité avec des processeurs vieux de presque 20 ans. GCC peut s'efforcer, avec plus ou moins de succès, d'exploiter les instructions et fonctionnalités des CPUs x86 modernes.
Je ne crois pas que ça fasse une très grande différence pour un navigateur comme firefox cela dit. D'après le blog d'un développeur de flash, ça ne change rien pour flash non plus, dans la mesure où les développeurs de ce logiciel écrivent eux même à ma main les parties critiques en assembleur optimisé modulairement selon les jeux d'instructions disponibles à l'exécution (ce qui fait, au passage, qu'il leur a fallu beaucoup de temps pour faire ce port x86_64 de flash).
Donc dans ce cas précis on peux supposer qu'il est peu probable qu'un flash 64 bits améliore les performances (en termes d'efficacité CPU uniquement, parce qu'être obligé d'avoir sur disque et chargé en mémoire les libs 32 bits, c'est quand même du gachis de ressources à mon gout). Mais en pratique, et dans le cas d'une distribution Linux, on ne peux pas généraliser ce constat en disant que le 64bits n'apporte aucun autre gain qu'un plus grand espace d'adressage.
Et je ne sais pas vous mais je vois malheureusement venir à grands pas le jour où firefox utilisera régulièrement plus de 3 Go de ram /o\