En ce qui concerne Windows spécifiquement : les autres réponses sont probablement suffisantes.
En ce qui concerne le 128 bits, cependant... la réponse est plus complexe que ce que les autres réponses tentent de faire croire.
Et voici'pourquoi :
La plupart des réponses prétendent que ce n'est pas nécessaire. Ce n'est pas exactement vrai.
D'autres réponses prétendent que c'est'simplement parce qu'il n'y a pas d'unités centrales de traitement de 128 bits ; ce n'est'pas exactement vrai non plus.
Deux machines disponibles dans le commerce avec des pointeurs de 128 bits
L'utilisation la plus intéressante de 128 bits est la gestion de l'espace d'adressage.
Le System i d'IBM, anciennement l'AS/400, une caractéristique de conception de la version CISC S/38, et étendue dans les modèles 64 bits RS64 PPC.
Malheureusement pour la valeur utile des espaces d'adressage de 128 bits, l'espace d'adressage virtuel est architecturalement limité, ce qui signifie qu'il réside sur les 48 bits les plus à droite de l'AS/400 basé sur le S/38, et sur les 64 bits les plus à droite de l'AS/400 basé sur le RS64.
Ce qui le rend effectivement inutile pour l'utilisation la plus intéressante d'un espace d'adressage de 128 bits.
Le besoin d'un espace d'adressage de 128 bits
Pourrait-on utiliser un espace d'adressage de 128 bits pour les applications CS ? Absolument. Est-ce que quelqu'un les construit pour nous ? Absolument pas.
Il existe plusieurs utilisations très intéressantes d'un espace d'adressage de 128 bits ; dans aucun ordre particulier, ce sont :
- Mémoire partagée distribuée, clusters HPC (High Performance Computing), NUMA et NUMA virtuel
- HSM (Hierarchical Storage Management)
- Vectorisation de la répartition
- Protection statistique de la mémoire
Il y en a des tas d'autres ; ils ont tendance à être un peu plus obsédants, donc juste à titre d'échantillon aléatoire (ce'n'est pas aléatoire, mais hé, n'offensons pas quelqu'un d'autre qui a une utilité pour 128 bits, et que je n'ai pas inclus dans ma liste personnelle), regardons chacun d'entre eux.
- DSM (Distributed Shared Memory), clusters HPC (High Performance Computing), NUMA, et Virtual NUMA
Il'est déjà possible d'utiliser plus que 32 bits de mémoire physique. 32 bits vous donne 4G de RAM adressable ; 64 bits vous en donne plus, mais c'est généralement insuffisant, même si la mémoire physique adressable typiquement maximale descend autour de 56 bits ; cela ne vous laisse que 8 bits pour jouer.
À l'heure actuelle, les décodeurs d'adresses ne disposent pas de masques de décodage programmables. Nous pourrions obtenir certains des avantages, mais pas tous, dans un processeur 64 bits, avec des masques de décodage d'adresse programmables et des exceptions matérielles.
Le résultat de ceci est que nous ne pouvons'utiliser les 8 bits supérieurs, puisqu'ils font partie de l'espace d'adresse virtuel, si ce n'est de l'espace physique de 56 bits. Il'est probable que quelqu'un, un jour, va coincer 57 bits de mémoire physique dans une machine, et alors tout exploserait si nous utilisions ces 8 bits de toute façon.
Un usage typique serait sur les processeurs Intel modernes.
Sur les machines multiprocesseurs, l'interconnexion du bus mémoire est effectivement une mise en œuvre en anneau à jeton. La RAM physique peut être accrochée à chaque CPU, et accessible via n'importe quel autre CPU.
En pratique, il s'agit d'une mise en œuvre NUMA virtuelle ; mais aussi en pratique : la plupart de la mémoire est accrochée à un seul paquet de CPU, généralement le BSP, et tous les autres accèdent à la mémoire du système via l'anneau à jeton. Il existe quelques conceptions de serveurs, toutes assez récentes, qui s'opposent à cette tendance.
Où viendraient les bits supplémentaires (masqués, exceptés) ?
Les désignateurs de localité. La localité détermine la vitesse d'accès :
- Cache L1 : le plus rapide
- Cache L2 : le plus rapide suivant
- Cache L3 (si présent) : le plus rapide suivant ; généralement non utilisé sauf dans les systèmes ASMP
- Mémoire attachée localement : le plus rapide suivant
- NUMA/Virtuel NUMA (par ex. Intel aujourd'hui) : le plus rapide
- Cluster HPC (même interconnexion) : le plus rapide
- DSM ou cluster HPC (interconnexion plus éloignée) : le plus lent, vitesse décroissante avec le nœud/la distance physique
Il'serait utile d'utiliser certains des bits du pointeur pour étiqueter la mémoire en fonction de son coût, afin de pouvoir prendre des décisions sur la mémoire à utiliser pour un élément de données donné, n'est-ce pas ? Nos ordinateurs deviendraient tous (mesurés) jusqu'à environ 11%-18% plus rapides, sans autres changements majeurs dans les logiciels.
Mais nous avons besoin de plus de bits pour cela.
- HSM (Hierarchical Storage Management)
C'est un problème similaire à NUMA et ses parents, comme discuté précédemment ; cependant, il peut être encore plus compliqué, parce qu'au lieu d'être simplement plus lente, la mémoire pourrait être s..l..o..w..e..r.
Il existe certains algorithmes que beaucoup de gens ont pris l'habitude d'appeler par le nom coloré d'algorithmes do-I-really-want-to-wait. Et si certains des bits désignaient des localités, en plus des localités physiques de la RAM ? Par exemple, un désignateur de HSM pourrait être :
- Il'est sur le disque local ; je'reviens tout de suite !
- Il'est sur le robot à bande ; laissez-moi le demander !
- C'est sur une bande 9 pistes dans le centre de service de l'IRS à Ogden, Utah ; laissez-moi envoyer un message qui fera apparaître un dialogue sur l'écran de quelqu'un's, et ils peuvent entrer, prendre la bande, et la fourrer dans l'un de leurs lecteurs de bandes CDC attachés à leurs systèmes Zilog Zeus qu'ils gardent autour pour accéder aux vieux dossiers fiscaux !
- Il'est à un endroit indéterminé ; laissez-moi diffuser un "qui a" dessus à tout le monde, et s'ils peuvent le trouver, vous'saurez d'ici jeudi prochain !
Non seulement cela, mais généralement, le HSM implique une migration du cache de plus lent à plus rapide, mais qui se produit lentement. Donc c'est une désignation de type "appelez-moi une fois, ce'sera lent ; appelez-moi deux fois, ce'sera plus rapide".
Etes-vous simplement curieux, ou avez-vous l'intention d'itérer sur ces données pour une raison précise ? Il'serait utile de pouvoir omettre certaines informations, lorsque c'est une chose OK à faire, sur la base d'un compromis temps/complétude. La sensibilité à cela varierait non seulement selon l'algorithme, mais aussi selon l'objectif.
Mais nous avons besoin de plus de bits pour cela.
- Vectorisation de la répartition
Une des choses que vous faites dans la recherche, parce que vous ne pouvez pas'tenir tout dans une seule machine, est de tenir différentes parties de l'espace de réponse dans différentes machines. Et ensuite vous transférez la demande de réponse à une autre machine.
Vous pouvez faire cela de nombreuses façons, et cela'a été fait de nombreuses façons au fil des ans, y compris simplement l'envoi en round-robin des demandes à un serveur, quelque part, et ensuite, même s'il'est lent, il obtient les données pour vous.
Une autre façon est d'utiliser la vectorisation de la répartition afin de traiter la demande.
C'est une façon fantaisiste de dire que vous avez la recherche en main, puis vous créez une sorte de hachage sémantique, et ensuite vous l'utilisez pour router vers une machine (ou une parmi un tas de machines) pour qu'elle réponde à la demande.
En termes pratiques, cela signifie qu'il y'a un facteur de localité sémantique dans l'endroit où vous envoyez la requête.
Traitons donc l'ensemble de l'infrastructure du moteur de recherche comme une "mémoire", et assignons ensuite certains bits du pointeur pour adresser l'élément d'information que nous demandons : nous prenons le hachage sémantique, et c'est l'adresse virtuelle de la réponse que nous voulions obtenir en premier lieu. Ensuite, nous le référençons simplement et renvoyons le résultat.
Mais nous avons besoin de plus de bits pour cela.
- Protection statistique de la mémoire
Je trouve cette utilisation particulière massivement intéressante, personnellement.
Plutôt que d'utiliser des domaines de protection matérielle pour protéger les pages de données les unes des autres, vous utilisez le fait que vous'utilisez seulement, disons 52 bits de valeur de RAM physique (c'est une sacrée quantité de RAM, soit dit en passant ! C'est un pétaoctet ! 10^15 !).
Qu'est-ce qui'reste sur les 64 bits ? C'est 2^12, autrement connu comme notre vieil ami, 4K.
Brievement, la protection statistique de la mémoire repose sur le fait de la quasi-impossibilité de deviner une page valide, puis de jouer avec son contenu. C'est appelé protection pas nécessairement d'un point de vue de sécurité aussi : il inclut l'idée de la fréquence à laquelle vous'vous attendez à ce qu'un pointeur avec une valeur aléatoire en lui frappe une page qui se trouve être valide.
Disons que nous avons un pétaoctet de mémoire, plus ou moins, en service dans le système, et que nous exécutons un programme qui charge un pointeur avec une valeur aléatoire dedans, puis essaie de griffonner sur ce qui se trouve être dans l'espace d'adresse virtuelle du CPU à ce moment-là dans la mémoire.
Quelles sont mes chances, sur un système 64 bits ? 1:4096.
Maintenant... à quelle vitesse puis-je trouver une page à griffonner, si je'suis malveillant ? Ou à lire, si je'cherche quelque chose que je ne devrais pas regarder, mais qui se trouve être en mémoire ?
Si je'suis autorisé à attraper des exceptions et à réessayer : sacrément vite. Statistiquement, donc, cette mémoire n'est pas très sûre, sans mettre en œuvre des protections matérielles de la mémoire, et des surcharges de croisement de domaines de protection, et des fusillades de TLB, et toutes ces autres ordures qui font que les OS's sont si surchargés.
Pour en arriver à la blague...
Un éléphant est une souris avec un système d'exploitation. -- Inconnu
Mais... et si mon espace d'adressage virtuel était de 128 bits ? Je pourrais utiliser 64 de ces bits comme emplacement de page aléatoire dans l'espace d'adressage virtuel.
Quelles sont mes chances ? 1:18,446,744,073,709,551,616.
Maintenant... à quelle vitesse puis-je trouver cette page ?
Précisemment : ça't arrivera pas. Jamais.
Et maintenant je peux jeter tous les frais généraux du domaine de protection que je payais auparavant pour utiliser, et je récupère tous mes frais généraux d'appel système, et le TLB flushing, et tout le reste.
La protection statistique de la mémoire est viable. Il en est de même pour la protection de la mémoire Mondrian.
En fait, il en est de même pour beaucoup de recherches en CS que je ne peux pas faire aujourd'hui, sauf en simulation, et même si mes résultats sont bons, je ne peux pas les déployer, faute de matériel.
Avons-nous besoin d'espaces d'adressage virtuels de 128 bits ?
Je soutiens qu'il y a un besoin pour ça.