¿Por qué no hay CPUs de 128-bit ya? ¿O sí los tenemos?

Muchos usuarios se preguntan por qué si hubo un salto de los 32-bit a los 64-bit en las CPUs, por qué no lo hay ahora de los 64-bit a los 128-bit, si ya han pasado años… ¿Es que no se pueden crear procesadores de 128-bit? ¿Ya existen unidades de 128-bit? ¿Qué pasa realmente? Todas esas dudas quedarán resueltas en este artículo…

También te puede interesar conocer qué es una ISA y tipos

Implicaciones del cambio de los 64-bit a los 128-bit

La transición desde arquitecturas de 32 bits a 64 bits fue un cambio motivado principalmente por la necesidad de ampliar el espacio de direcciones y mejorar el rendimiento en ciertos tipos de operaciones, es decir, que las CPUs pudieran soportar más capacidad de memoria sin tener que usar técnicas como PAE.

El primero de la historia de 64-bit fue el R4000, producido por la compañía MIPS Technologies en 1991. Para el PC no se alcanzarían los 64-bit hasta que AMD introdujo AMD64 (también llamado EM64T por Intel o x86-64) para sus Athlon64 y Opteron. Esta ampliación de x86 no se debe confundir con IA-64 de Intel, que es la ISA empleada en sus Itanium, y que no es una evolución directa de IA-32 (x86-32).

La idea de dar el salto a 128-bit surge periódicamente en discusiones técnicas, pero sus consecuencias, tanto en software como en hardware, serían drásticamente distintas a la transición previa. A día de hoy, la utilidad práctica de una arquitectura general de 128 bits es cuestionable, la capacidad de memoria soportada ahora por los procesadores de 64-bit es suficiente.

Ten en cuenta que para una CPU de 32-bits en cuanto a la anchura del bus de direcciones, tenemos que 2³² = 4.294.967.296 bytes ≈ 4 GB. Mientras que para una CPU de 64-bit haciendo referencia a su ancho del bus de direcciones, se podrían manejar: 2⁶⁴ = 18.446.744.073.709.551.616 bytes ≈ 16 EB. Con una de 128-bit se alcanzarían aproximadamente 340 billones de billones de billones de bytes, o 256 YB… una auténtica burrada, que hoy por hoy no es necesaria.

Cambios en el hardware necesarios para dar el salto a 128-bit

Entre los cambios necesarios para dar el salto a los procesadores de 128-bit tenemos:

• Registros y ALU: una CPU de 128 bits tendría registros generales de 128 bits, lo que duplicaría el tamaño de los registros respecto a una arquitectura de 64 bits. Esto implicaría ALUs (Arithmetic Logic Units), unidades de carga/almacenamiento y buses internos de doble anchura, aumentando el consumo energético, el calor generado y la superficie de silicio. La densidad de transistores en la CPU crecería notablemente, no tanto por las ALUs (que escalarían linealmente en tamaño) como por las rutas de datos internas y los buffers de registros necesarios.
• Buses y memoria: los buses de direcciones de 128 bits permitirían direccionar 2¹²⁸ bytes, una cantidad astronómica y físicamente imposible de implementar con la tecnología de memoria actual o previsible. Los buses de datos de 128 bits duplicarían el ancho del bus actual en arquitecturas de 64 bits, lo que aumentaría la complejidad de la placa base y el consumo eléctrico. Esto implicaría que memorias y controladores deberían adaptarse, encareciendo el coste por unidad.
• Cache: la L1, L2 y L3 deberían almacenar direcciones y etiquetas de 128 bits, duplicando su espacio de metadatos y penalizando la eficiencia del silicio. Esto incrementa latencias y reduce la cantidad de datos útiles almacenados para un mismo tamaño físico de caché.

Impacto en el Sistema Operativo

Por otro lado, los sistemas operativos también tendrían que ser actualizados, al igual que las bibliotecas de software y los programas para que trabajasen de forma nativa con estas longitudes:

• Espacio de direcciones: el salto a 128 bits no está motivado por la necesidad de más memoria direccionable: los 64 bits ya ofrecen 16 exabytes de espacio, muy por encima de cualquier requisito realista. La gestión de un espacio de direcciones tan descomunal añadiría sobrecarga en tablas de páginas y TLBs (Translation Lookaside Buffers).
• Estructuras de datos internas: todas las estructuras del kernel que almacenen punteros (tablas de procesos, estructuras de memoria, descriptores de archivos, etc.) se duplicarían en tamaño. Esto provoca un aumento sistemático del consumo de RAM en todas las aplicaciones y en el propio kernel, reduciendo la eficiencia de la caché.
• Drivers y compatibilidad: todos los drivers actuales quedarían obsoletos, dado que el modelo de datos y la ABI (Application Binary Interface) cambiarían. Habría que reescribir o recompilar todo el ecosistema de software, incluyendo firmware de dispositivos.

Impacto en el Desarrollo de Software

También el software tendría que modificarse, lo cual es una modificación de la pila o el ecosistema al completo, desde el hardware al software:

• Reescritura y portabilidad: migrar a 128 bits exigiría que cada puntero en el código fuente fuese compatible con el nuevo tamaño, lo que rompe muchas asunciones en bibliotecas y sistemas embebidos. Lenguajes como C y C++ sufrirían más, ya que suelen tener código dependiente del tamaño exacto de los punteros.
• Rendimiento: operaciones enteras que no necesitan 128 bits serían más lentas si no se usan registros más pequeños, debido al mayor ancho de datos a mover. Los compiladores tendrían que optimizar constantemente para usar registros de 32/64 bits internamente, lo que reduce el beneficio de la arquitectura «pura» de 128 bits.
• Depuración y seguridad: la depuración se complica porque las direcciones de memoria y valores intermedios son más grandes. Desde el punto de vista de seguridad, la aleatorización del espacio de direcciones (ASLR) sería más efectiva al disponer de un rango mucho mayor, aunque esto es marginal dado que 64 bits ya ofrecen un espacio enorme.

En definitiva, costes económicos para todos los desarrolladores y fabricantes de la pila que serían inasumibles en la actualidad, dado que con 64-bit es suficiente.

Te recomiendo leer microprocesadores que pueden ejecutar varios tipos de instrucciones

Extensiones al rescate… ¿Y si ya tuviéramos CPUs de 128-bit e incluso superiores?

Aunque comercialmente se hable de CPU de 64-bit, esta denominación solo describe el tamaño de palabra nativo y el ancho de las direcciones de memoria que maneja la unidad. En la práctica, las arquitecturas modernas de propósito general (x86-64, ARM, RISC-V, POWER, SPARC, etc.) ya procesan datos con anchos muy superiores a 64 bits gracias a extensiones SIMD (Single Instruction, Multiple Data) y otros mecanismos especializados.

Estas extensiones permiten operar con vectores de 128, 256, 512 o incluso 2048 bits en una sola instrucción, sin necesidad de cambiar la arquitectura de la CPU a 128 bits o más a nivel de palabra nativa.

Tamaño de palabra vs. ancho de registro SIMD

Aquí tenemos que diferenciar varias cosas, para entender lo anterior. El bus del sistema se compone de tres buses elementales, el bus de control, que lleva las señales de control, el bus de direcciones que es el que tiene el tamaño de 64-bit en la actualidad para direccionar la memoria, y el bus de datos, que también tiene 64-bit en la actualidad para datos de ese tamaño.

Cuando se habla de tamaño de palabra, es el número de bits que maneja la unidad aritmético-lógica principal (ALU) para operaciones escalares enteras. Determina el espacio de direcciones y el tamaño de punteros.

En cambio, esto no quiere decir que el ancho de registro SIMD esté limitado a eso. En este caso hablamos del número de bits que puede manipular un registro vectorial en una sola instrucción. No afecta directamente al tamaño de palabra ni al direccionamiento de memoria. Ejemplo: un registro AVX-512 tiene 512 bits y puede contener 8 enteros de 64 bits o 16 enteros de 32 bits para operar en paralelo.

En la actualidad, tenemos muchas ISAs usando extensiones de un tamaño superior a los 64-bit, como por ejemplo:

• x86-64: con extensiones como las SSE de 128-bit (permite manejar hasta 4 floats de 32-bits en paralelo), también las AVX de 256-bit (mayor throughput y doble de ancho de las SSE) o las AVX-512 de 512-bit (permite manejar a la vez 8 enteros de 64-bit, o 16 de coma flotante de 32-bit). Todo ello con registros vectoriales independientes a los registros escalares.
• ARM: en este caso pasa algo parecido con extensiones de 128-bit como las NEON, o las SVE (Scalable Vector Extension) que puede configurarse con diferentes anchos, desde 128-bit hasta 2048-bit, y todo en tiempo de ejecución o compilación, lo cual es una ventaja.
• RISC-V: en este caso tenemos el módulo o extensión V, que también permite entre 128 y 2048-bit. Es totalmente parametrizable desde el hardware en este caso.
• POWER: aquí podemos encontrar algunas extensiones como VSX de 128-bit, y también las VMX/Altivec del mismo tamaño, pero éstas últimas para multimedia. En POWER10 también se permite el uso de vectores de 256-bit y matrices.
• SPARC: en este caso también existen ejemplos vectoriales y multimedia como las VIS de 128-bit.

Conclusión: Por qué esto hace innecesaria una CPU de 128 bits nativa

En definitiva, el tamaño de palabra de 64-bit es ideal para direccionamiento y operaciones escalares generales actuales, que con esa longitud es más que suficiente en la actualidad, no haciendo necesario in incremento por ahora. Además, incluso con la llegada de la IA, hemos visto que se hace uso de enteros y coma flotante aún más pequeños, como los de 8-bit, 16-bit, etc., obligando a los arquitectos de CPUs, NPUs, y GPUs a diseñar unidades y extensiones específicas para estos datos.

Para algunas aplicaciones, como las multimedia, gráficos 3D, simulaciones científicas, etc., se pueden usar las extensiones SIMD. De esta forma, se permite el procesamiento masivo de datos se delega a registros vectoriales anchos, sin penalizar el coste y la complejidad de manejar punteros y estructuras de 128 bits en todo el sistema.

Las extensiones SIMD permiten cambiar el ancho de datos procesados sin rediseñar todo el ISA base, solo agregando extensiones según sea necesario, lo que aporta flexibilidad. Por ejemplo, aunque un compilador para x86-64 use operaciones de 64-bit para un programa concreto, también podría utilizar las AVX-512 solo en aquellos casos donde sea necesario.

Por tanto, no es necesario duplicar el ancho de todos los buses y registros generales, lo que reduce consumo y tamaño de die. Solo las unidades vectoriales, que son opcionales en el pipeline, usan buses más anchos…

¿Qué opinas? Deja tus comentarios…