Con respecto a Windows específicamente: las otras respuestas son probablemente suficientes.
Con respecto a los 128 bits, sin embargo… la respuesta es más compleja de lo que las otras respuestas intentan hacer ver.
Y aquí está el porqué:
La mayoría de las respuestas afirman que no hay necesidad de ello. Esto no es exactamente cierto.
Otras respuestas afirman que es simplemente porque no hay CPUs de 128 bits; esto tampoco es exactamente cierto.
Dos máquinas disponibles comercialmente con punteros de 128 bits
El uso más interesante de los 128 bits es para gestionar el espacio de direcciones.
El IBM System i, anteriormente el AS/400, una característica de diseño de la versión S/38 CISC, y ampliada en los modelos RS64 PPC de 64 bits.
Desgraciadamente para el valor útil de los espacios de direcciones de 128 bits, el espacio de direcciones virtual está limitado arquitectónicamente, lo que significa que reside en los 48 bits más a la derecha del AS/400 basado en S/38, y en los 64 bits más a la derecha del AS/400 basado en RS64.
Esto lo hace efectivamente inútil para el uso más interesante de un espacio de direcciones de 128 bits.
La necesidad de un espacio de direcciones de 128 bits
¿Podríamos utilizar un espacio de direcciones de 128 bits para aplicaciones CS? Por supuesto. ¿Hay alguien que las construya para nosotros? Por supuesto que no.
Hay varios usos muy interesantes para un espacio de direcciones de 128 bits; sin ningún orden en particular, son:
- Memoria compartida distribuida, clusters HPC (High Performance Computing), NUMA y NUMA virtual
- HSM (Hierarchical Storage Management)
- Vectorización de envíos
- Protección de memoria estadística
Hay un montón de otros; tienden a ser un poco más oscuro, por lo que sólo como una muestra aleatoria (no es al azar, pero hey, let’s no ofender a alguien más que tiene un uso de 128 bits, y que didn’t incluyen en mi lista personal), let’s mirar a cada uno de estos.
- DSM (Memoria Compartida Distribuida), Clusters HPC (Computación de Alto Rendimiento), NUMA, y NUMA Virtual
Ya es posible utilizar más de 32 bits de memoria física. Con 32 bits se consiguen 4G de RAM direccionable; con 64 bits se consiguen más, pero generalmente no es suficiente, aunque la memoria física típicamente máxima direccionable se sitúa en torno a los 56 bits; eso te deja sólo 8 bits con los que jugar.
Ahora mismo, los descodificadores de direcciones no tienen máscaras de descodificación programables. Podríamos obtener algunos de los beneficios, pero no todos, en un procesador de 64 bits, con máscaras de decodificación de direcciones programables y excepciones de hardware.
El resultado de esto es que no podemos utilizar los 8 bits superiores, ya que son parte del espacio de direcciones virtual, si no el espacio físico de 56 bits. Es probable que alguien, algún día, vaya a meter 57 bits de memoria física en una máquina, y entonces todo explotaría si usamos esos 8 bits de todos modos.
Un uso típico sería en los procesadores Intel modernos.
En los procesadores Intel modernos en máquinas multiprocesadoras, la interconexión del bus de memoria es efectivamente una implementación de anillo de fichas. La RAM física puede colgarse de cada CPU, y acceder a ella a través de cualquier otra CPU.
En la práctica, se trata de una implementación NUMA virtual; pero también en la práctica: la mayor parte de la memoria se cuelga de un único paquete de CPU, normalmente el BSP, y todos los demás acceden a la memoria del sistema a través del anillo de fichas. Hay algunos diseños de servidores, todos bastante recientes, que se saltan esta tendencia.
¿Dónde entrarían los bits extra (enmascarados, exceptuados)?
Diseñadores de localidad. La localidad determina la velocidad de acceso:
- Caché L1: la más rápida
- Caché L2: la siguiente más rápida
- Caché L3 (si está presente): la siguiente más rápida; generalmente no se utiliza excepto en los sistemas ASMP
- Memoria conectada localmente: la siguiente más rápida
- NUMA/Virtual NUMA (p. ej. Intel hoy en día): la siguiente más rápida
- Cluster HPC (misma interconexión): la siguiente más rápida
- DSM o Cluster HPC (interconexión más lejana): la más lenta, velocidad decreciente con la distancia física/nodo
Sería útil si pudiéramos utilizar algunos de los bits del puntero para etiquetar la memoria según su coste, de modo que pudiéramos tomar decisiones sobre qué memoria utilizar para un dato determinado, ¿no es así? Nuestros ordenadores serían (medidos) hasta un 11%-18% más rápidos, sin ningún otro cambio importante en el software.
Pero necesitamos más bits para eso.
- HSM (Hierarchical Storage Management)
Este es un problema similar al de NUMA y sus parientes, como se discutió anteriormente; sin embargo, puede ser aún más complicado, porque en lugar de ser sólo más lento, la memoria podría ser s..l..o..w..e..r.
Hay algunos algoritmos a los que mucha gente ha empezado a llamar con el colorido nombre de algoritmos «do-I-really-want-to-wait». ¿Qué pasaría si algunos de los bits designaran localidades, además de las localidades físicas de la RAM? Por ejemplo, un designador HSM podría ser:
- Está en el disco local; ¡ya vuelvo!
- Está en el robot de cinta; ¡déjame pedirlo!¡
- Está en una cinta de 9 pistas en el centro de servicios del IRS en Ogden, Utah; déjame enviar un mensaje que hará aparecer un diálogo en la pantalla de alguien, y ellos pueden entrar, coger la cinta, y meterla en una de sus unidades de cinta CDC conectadas a sus sistemas Zilog Zeus que guardan para acceder a los antiguos registros de impuestos!
- Está en un lugar indeterminado; déjame emitir un «quién lo tiene» a todo el mundo, y si lo encuentran, ¡lo sabrás el próximo jueves!
No sólo eso, sino que, en general, el HSM implica una migración de la caché de más lento a más rápido, pero que ocurre lentamente. Así que es una designación de «llámame una vez, será lento; llámame dos veces, será más rápido».
¿Sólo tienes curiosidad, o pretendes iterar sobre estos datos por alguna razón? Sería útil ser capaz de omitir alguna información, cuando es una cosa correcta de hacer, sobre la base de un compromiso de tiempo/completitud. La sensibilidad a esto no solo depende del algoritmo, sino del propósito.
Pero necesitamos más bits para eso.
- Vectorización de la distribución
Una de las cosas que haces en la búsqueda, porque no puedes mantener todo en una máquina, es mantener diferentes partes del espacio de respuestas en diferentes máquinas. Y luego se pasa la solicitud de respuesta a otra máquina.
Se puede hacer esto de muchas maneras, y se ha hecho de muchas maneras a lo largo de los años, incluyendo sólo el envío de las solicitudes a algún servidor, en algún lugar, y luego, incluso si es lento, obtiene los datos para usted.
Otra forma es utilizar la vectorización de envíos para manejar la solicitud.
Esta es una forma elegante de decir que tienes la búsqueda en la mano, y luego creas una especie de hash semántico, y luego lo utilizas para dirigirte a una máquina (o a una de un montón de máquinas) para que responda a la solicitud.
En términos prácticos, esto significa que hay un factor de localidad semántica en donde se envía la solicitud.
Así que vamos a tratar toda la infraestructura del motor de búsqueda como una «memoria», y luego asignar algunos bits del puntero para dirigir el elemento de información que estamos solicitando: tomamos el hash semántico, y es la dirección virtual de la respuesta que queríamos obtener en primer lugar. Entonces hacemos referencia a ella y devolvemos el resultado.
Pero necesitamos más bits para eso.
- Protección estadística de la memoria
Personalmente, este uso particular me parece enormemente interesante.
En lugar de utilizar dominios de protección por hardware para proteger las páginas de datos entre sí, utilizas el hecho de que sólo estás usando, digamos, 52 bits de RAM física (¡eso es un montón de RAM, por cierto! ¡Es un petabyte! 10^15!).
¿Qué queda de los 64 bits? Es 2^12, también conocido como nuestro viejo amigo, 4K.
Brevemente, la protección estadística de la memoria se basa en el hecho de la casi imposibilidad de adivinar una página válida, y luego jugar con su contenido. Se llama protección no necesariamente desde una perspectiva de seguridad también: incluye la idea de la frecuencia con la que se espera que un puntero con un valor aleatorio en él para golpear una página que resulta ser válida.
Así que digamos que tenemos un petabyte de memoria, más o menos, en uso en el sistema, y ejecutamos un programa que carga un puntero con un valor aleatorio en él, y luego trata de garabatear en cualquier cosa que suceda en el espacio de direcciones virtual de la CPU en ese punto de la memoria.
¿Cuáles son mis posibilidades, en un sistema de 64 bits? 1:4096.
Ahora… ¿qué tan rápido puedo encontrar una página para garabatear, si soy malicioso? O para leer, si estoy buscando algo que no debería estar mirando, pero que resulta estar en la memoria?
Si se me permite atrapar excepciones y reintentar: bastante rápido. Estadísticamente, entonces, esa memoria no es muy segura, sin implementar protecciones de memoria por hardware, y sobrecarga de cruce de dominios de protección, y disparos de TLB, y toda esa otra basura que hace que los SOs tengan tanta sobrecarga.
Llevando al chiste…
Un elefante es un ratón con un sistema operativo. — Desconocido
Pero… ¿y si mi espacio de direcciones virtuales fuera de 128 bits? Podría utilizar 64 de esos bits como una ubicación de página aleatoria dentro del espacio de direcciones virtual.
¿Cuáles son mis posibilidades? 1:18,446,744,073,709,551,616.
Ahora… ¿con qué rapidez puedo encontrar esa página?
Muy poco: no va a ocurrir. Nunca.
Y ahora puedo tirar toda la sobrecarga del dominio de protección que antes pagaba por usar, y recupero toda la sobrecarga de las llamadas al sistema, y el flushing del TLB, y todo lo demás.
La protección de memoria estadística es viable. También lo es la protección de memoria Mondrian.
De hecho, también lo es mucha de la investigación en CS que no puedo hacer hoy en día, excepto en la simulación, e incluso si mis resultados son buenos, no puedo desplegarlos, por falta de hardware.
¿Necesitamos espacios de direcciones virtuales de 128 bits?
Yo diría que hay necesidad de ello.