Y at-il une amélioration de la bande passante de l’installation d’un système d’exploitation 32 bits sur un ordinateur 64 bits?

Question

Knuth s'est récemment opposé aux systèmes 64 bits, déclarant que pour les programmes qui tiennent dans 4 Go de mémoire, "ils jettent effectivement la moitié de la mémoire cache" parce que les pointeurs sont deux fois plus gros que sur un système 32 bits.

Ma question est la suivante: ce problème peut-il être évité en installant un système d'exploitation 32 bits sur une machine 64 bits? Et existe-t-il des points de repère gourmands en bande passante qui démontrent l’avantage dans ce cas?

Answer 1

La réponse est: oui, dans une certaine mesure, bien que la différence de performances soit peu probable.

Toute référence pour tester ceci devra faire beaucoup de résolution de pointeur, ce qui sera difficile à séparer du bruit. Concevoir un point de référence qui ne sera pas optimisé est difficile. Cet article sur les points de repère Java défectueux a été publié par une personne à une autre question, mais bon nombre des principes qui y sont décrits s’appliqueront à cela.

Answer 2

La bande passante n’est pas vraiment le terme correct ici. Knuth parlait réellement de la densité des données, en ce qui concerne l'empreinte de la mémoire cache. Imaginez que vous avez un cache de données L1 de 16 Ko: si vous ne stockez que des pointeurs, vous pouvez stocker 2 ^ 14/2 ^ 2 = 2 ^ 12 = 4096 pointeurs 32 bits, mais seulement 2048 pointeurs 64 bits. Si les performances de votre application dépendent de la capacité de garder trace de plus de 2 000 tampons différents, vous pouvez constater un réel avantage en termes de performances grâce à un espace d'adressage 32 bits. Cependant, la plupart des codes réels ne sont pas ainsi, et les avantages réels d'un système de mise en cache en termes de performances réelles viennent souvent de la possibilité de mettre en cache des structures de données entières et en virgule flottante communes, et non des quantités énormes de pointeurs. Si votre groupe de travail n’est pas trop pointillé, l’inconvénient de la version 64 bits devient négligeable, et l’inconvénient devient beaucoup plus évident si vous effectuez de nombreuses opérations arithmétiques sur 64 bits.

Answer 3

Je ne pense pas que Knuth se soit opposé aux systèmes 64 bits. Il vient de dire que l'utilisation de pointeurs 64 bits sur un système disposant de moins de 4 Go de RAM est idiote (du moins si vous avez beaucoup de pointeurs comme ceux d'une liste à double liaison). Je ne peux pas dire que je suis d'accord avec lui, voici 3 façons différentes qui peuvent être prises. Supposons que vous disposiez d'un processeur compatible 64 bits pouvant également fonctionner en mode 32 bits, comme certains processeurs Intel Core Duo.

1 - Tout est en 32 bits, le système d’exploitation, l’APPZ, tous. Vous avez donc des pointeurs 32 bits, mais vous ne pouvez pas utiliser les registres / instructions supplémentaires disponibles en mode 64 bits.

2 - Tout est en 64 bits, le système d'exploitation, l'APPZ, tous. Vous avez donc des pointeurs 64 bits et vous pouvez utiliser les registres / instructions supplémentaires disponibles en mode 64 bits. Mais comme vous avez moins de 4 Go de RAM, utiliser des pointeurs 64 bits semble idiot. Mais, est-ce?

3 - Le système d’exploitation est 64 bits et permet de s’assurer que tous les pointeurs de code / données se trouvent dans la plage 0x00000000 - 0xFFFFFFFF (mémoire virtuelle !!!). L’ABI fonctionne de manière très étrange, car tous les pointeurs de code / données conservés en mémoire / fichiers ont une largeur de 32 bits, mais ils sont chargés dans des registres 64 bits avec une extension nulle. S'il existe un emplacement de code à sauter, le compilateur / ABI effectue les corrections nécessaires et effectue le saut 64 bits. De cette façon, les pointeurs sont en 32 bits, mais APPZ peut être en 64 bits, ce qui signifie qu’ils peuvent utiliser les registres et les instructions 64 bits. Ce processus est quelque chose comme thunking, je pense ;-P

Ma conclusion est la suivante ::

La 3ème option me semblait faisable mais ce n’est pas un problème facile. En théorie, cela peut fonctionner, mais je ne pense pas que ce soit faisable. Et je pense aussi que sa citation "Lorsque de telles valeurs de pointeur apparaissent dans une structure, non seulement elles gaspillent la moitié de la mémoire, mais elles jettent en fait la moitié de la mémoire cache". est exagéré ...

Answer 4

J'ai vu quelque part que la meilleure combinaison (sur les processeurs x86) consiste à utiliser un système d'exploitation 64 bits et des applications 32 bits.

avec un système d'exploitation 64 bits, vous obtenez:

• possibilité de gérer plus de 4 Go d'espace d'adressage
• plus, de plus grands registres pour aider dans les opérations de copie de données

avec une application 32 bits, vous obtenez:

• petits pointeurs
• moins de registres plus petits pour enregistrer les changements de contexte

inconvénients:

• toutes les bibliothèques doivent être dupliquées. minuscule par les normes d'espace HD.
• toutes les bibliothèques chargées sont dupliquées sur la RAM. pas si petit ...

étonnamment, il ne semble y avoir aucune surcharge lors du changement de mode. J'imagine que passer de l'espace utilisateur au noyau coûte la même chose, peu importe la taille de l'espace utilisateur.

bien sûr, certaines applications bénéficient d’un grand espace d’adresse. mais pour tout le reste, vous pouvez obtenir une performance supplémentaire de 5% en restant en 32 bits.

et non, je me fiche de cette petite accélération. mais cela ne "choque" pas moi d’exécuter FireFox 32 bits sur une machine KUbuntu 64 bits (comme je l’ai déjà vu sur certains forums)