Un des bons articles que j'ai lu sur les processeurs

64 Bits ? Pourquoi faire ?




February 15th, 2009

Voilà, une petite ‘page’ sur le 64 bits, pour tordre le coup à certaines idées
fausses et se demander pourquoi une technologie disponible pour le
grand public depuis bientôt 5 ans (les premiers processeurs 64 bits
sont apparus dans les années 1960 pour les supercomputers, et les
processeurs RISC utilisent le 64 bits depuis les années 1990, mais les
premiers Power-PC / x86-64 sont sortis en 2003) met autant de temps à
se démocratiser.

Qu’est ce que le 64 bits ?

Il est déjà difficile de savoir de quoi on parle quand on évoque “64 bits”…

• La taille des instructions ? Non, certaines instructions prennaient
  déjà 64 bits (8 octets) sur une processeur 32 bits, et les processeurs
  64 bits gèrent des instructions 32 bits (4 octets).
  
• La taille du bus mémoire ? Non, il n’a jamais été lié au “nombre de
  bits” du processeur. Par exemple, le 68000 (16 bits) avait un bus
  mémoire de 24 bits. Et les processeurs 64 bits actuels (Core 2 Duo par
  exemple), ont un bus de 42 bits !
  
• La taille du bus données ? Non plus… Le 68000 utilisait une bus de 32 bits, les i7 plusieurs bus de 64 bits.
  
• La taille des registres de données ? Toujours pas, on a des registre 128 bits même sur certains processeurs 32 bits !
  
• Il ne reste donc plus qu’une solution: La taille des registres
  d’addressage… En particulier un: le registre ordinal (le ‘PC’ Program
  Counter) qui indique ou se trouve la prochaine instruction à éxécuter !
  

Donc tout se résume à ça: Le processeur est capable d’adresser 2⁶⁴
octets de mémoire, et surtout d’executer n’importe quelle instruction
dans cette plage mémoire. Les instructions peuvent être 32 bits ou non,
peut importe.

Voilà pourquoi le 68000 était appelé un 16/32 bits… Son ALU (calculs
sur entiers) était de 16 bits, tout comme son bus de données, mais les
registres (y compris le PC) étaient en 32 bits… (même si le bus
addresse n’avait que 24 bits).

La chasse aux idées reçues.

Mes programmes demanderont deux fois plus de mémoire sous un OS 64 bits.

Faux. Un programme 32 bits prendra exactement la même quantité de
mémoire. Un programme 64 bits natif, en revanche, nécessitera environ
10% de mémoire en plus. Seules les données d’adressage mémoire sont
étendues….

Mes programmes 32 bits tourneront plus vite sous un OS 64 bits.

Faux. Un programme 32 bits tournera de manière absoluement identique
sous un OS 64 bits que sous un OS 32 bits. La raison est que l’OS va
fournir un environnement 32 bits (SysWOW64 sous windows) au programme,
et le processeur executera nativement les instructions 32 bits. Le
programme peut même tourner plus lentement si l’environnement
d’execution demande des traductions.

Les programmes 64 bits tournent plus vite que les programmes 32 bits.

Si on s’en tient au même programme, simplement traduit en 64 bits,
c’est évidemment faux… Plus de temps pour décoder l’instruction,
mémoire cache nécessaire plus grande, etc… Mais c’est sans compter sur
le compilateur (le programme qui traduit les instructions des
développeurs en quelque chose de compréhensible par le processeur).
Quand il doit créer un programme pour une architecture de processeur
donné, il doit s’en tenir aux spécifications de ce processeur… Par
exemple le x86. En 32 bits, on a accès à 8 registres de 32 bits… Tout
le reste doit être lu/écris en mémoire cache. En 64 bits c’est 16
registres de 64 bits qui sont disponibles ! Autant dire que le
compilateur peut faire des optimisations bien plus importantes. Sur un
archiveur (WinZIP/WinRAR) il n’est pas rare de voir la version 64 bits
30% plus rapide que son homologue 32 bits !
Je ne parle même pas de l’existence assurée des instructions comme les
SSE2 sous toutes les architectures x86-64 (alors que le SSE n’est
qu’optionnel en x86-32). Et même une version améliorée, puisque 16
registres XMM (utilisés par les instructions SSE) sont disponibles au
lieu de 8 !

Il n’y a pas d’interêt à avoir un OS 64 bits si on a 4Go de mémoire ou moins.

Faux. Les OS réservent tous une portion de la plage adressable pour
les opérations d’entrée/sortie avec le hardware. Cette plage correspond
a des mémoire physiques sur les cartes d’extension, et non la mémoire
centrale. C’est pour cette raison que Windows XP ne propose ‘que’ 2Go
de mémoire utilisateur (3Go avec les bons settings), que l’ordinateur
est 2 ou 4Go de mémoire installés.
De plus, la méthode de lecture d’un fichier la plus rapide est ce qu’on
appelle le “mapping” de fichier… Il permet d’utiliser un fichier comme
mémoire virtuelle mappée à un certain emplacement. Evidemment, pour des
fichiers de plus de 4Go (vidéos 1080p), cela devient difficile en 32
bits, et demande de la pagination (bien plus lente).
Les fonctions de chiffrement/déchiffrement les plus fréquentes
travaillent sur des ‘mots’ de 64 bits en général, et sont donc 50% plus
rapide quand implémentées en 64 bits natif. Comme elles sont proposées
par le système, une système 64 bits est bien plus efficace dans ces cas
là.

Les programmes 32 bits ne bénéficient pas d’un OS 64 bits.

Faux. Comme expliqué ci-dessus, contrairement à un OS 32 bits (sans
tweaking) qui ne propose que 2Go de mémoire adressable par
“l’utilisateur” (le programme), un OS 64 bits propose l’ensemble des
4Go de mémoire adressable ! Et avoir moins de 4Go de RAM installé n’y
change rien, la mémoire virtuelle s’occupant de fournir 4Go de RAM à
toute application, même si 1 seul Go est installé ….
De plus certaines fonctions du système seront plus rapide, comme tout
ce qui touche aux données séquentielles (lecture de fichier,
chiffrement, compression, …).

:queen: