La plupart des applications sont plus _lentes_ si elles sont compilées en 64-bits qu'en 32-bits (c'est pour cela, par exemple, que la Debian sur SPARC64 est compilée en 32-bits, sauf pour le noyau).
En effet, le facteur limitant dans bien des cas, ce n'est pas la vitesse brute du CPU mais la bande passante CPU<=>Mémoire (d'où l'importance d'un gros cache par exemple). Un programme 64-bits est plus gros (pointeurs sur 64-bits, long sur 64-bits, ...) que son équivalent compilé en 32-bits, donc il utilise plus cette précieuse BP mémoire et plus de place dans le cache du CPU.
De plus, hors SIMD (méchanisme particulier qui permet de grouper les instructions, par exemple utiliser le 64-bits pour faire deux additions 32-bits d'un coup, comme le fait le MMX sur ia32+mmx), le gain est extrêmement faible, un programme "classique" utilise très peu de types à 64-bits.
Il ne faut pas croire que 64-bits => plus rapide. C'est le cas dans des domaines particuliers (calculs en virgule fixe sur 64-bits, ...); mais pas de manière générale. Par contre, ça apporte de gros avantages sur la gestion de la mémoire (32-bits => espace d'addressage limité à 4G, donc mémoire virtuelle disponible par application limitée à 4G, ainsi que différent problèmes si on approche des 4G de mémoire physique, voir la gestion de la mémoire sous Linux ia32).
Enfin, le nombre de "bits" d'un CPU c'est une notion assez floue, si on prend un PIII par exemple, on a:
- registres entiers: 32-bits
- registres flottants: 80-bits
- registres MMX: 64-bits
- bus mémoire: 64-bits
- addressage linéaire: 32-bits
- addressage virtuel: 32-bits
- addressage physique: 36-bits
[^] # Re: Intel a choisi d'étendre X86 vers le 64 bits
Posté par Gaël Le Mignot . En réponse à la dépêche Intel a choisi d'étendre X86 vers le 64 bits. Évalué à 4.
En effet, le facteur limitant dans bien des cas, ce n'est pas la vitesse brute du CPU mais la bande passante CPU<=>Mémoire (d'où l'importance d'un gros cache par exemple). Un programme 64-bits est plus gros (pointeurs sur 64-bits, long sur 64-bits, ...) que son équivalent compilé en 32-bits, donc il utilise plus cette précieuse BP mémoire et plus de place dans le cache du CPU.
De plus, hors SIMD (méchanisme particulier qui permet de grouper les instructions, par exemple utiliser le 64-bits pour faire deux additions 32-bits d'un coup, comme le fait le MMX sur ia32+mmx), le gain est extrêmement faible, un programme "classique" utilise très peu de types à 64-bits.
Il ne faut pas croire que 64-bits => plus rapide. C'est le cas dans des domaines particuliers (calculs en virgule fixe sur 64-bits, ...); mais pas de manière générale. Par contre, ça apporte de gros avantages sur la gestion de la mémoire (32-bits => espace d'addressage limité à 4G, donc mémoire virtuelle disponible par application limitée à 4G, ainsi que différent problèmes si on approche des 4G de mémoire physique, voir la gestion de la mémoire sous Linux ia32).
Enfin, le nombre de "bits" d'un CPU c'est une notion assez floue, si on prend un PIII par exemple, on a:
- registres entiers: 32-bits
- registres flottants: 80-bits
- registres MMX: 64-bits
- bus mémoire: 64-bits
- addressage linéaire: 32-bits
- addressage virtuel: 32-bits
- addressage physique: 36-bits