¿Por qué no hay microprocesadores de 256 o 512 bits?

En un microprocesador de 8 bits, su bus de datos consta de 8 líneas de datos. En un microprocesador de 16 bits, su bus de datos consta de 16 líneas de datos y así sucesivamente.

¿Por qué no hay ni un microprocesador de 256 bits ni un microprocesador de 512 bits? ¿Por qué no aumentan simplemente el número de líneas de datos y crean un microprocesador de 256 bits o un microprocesador de 512 bits?

¿Cuál es el obstáculo que impide crear un microprocesador de 256 bits o un microprocesador de 512 bits?

Incluso el marketing no puede seguir aumentando un número para siempre.
"... su bus de datos consta de..." No es tan cierto en estos días...
¿Por qué todavía no hay una maquinilla de afeitar de 256 hojas?
@Rocket: Espera unos años más. Recuerdo en la década de 1970 cuando Gillette presentó el "Track 2". Se suponía que iba a ser un gran avance nuevo. Saturday Night Live hizo una parodia comercial de una "Pista 3" con el lema porque te creerás cualquier cosa . Ahora tenemos un Track 3 (o como sea que lo llamen). Aparentemente, realmente creerás cualquier cosa.
@OlinLathrop ¡Mira el Gillete Fusion Power , con 5 cuchillas y una batería!
La respuesta es casi la misma que la de esta pregunta: Tenemos autos de 1 y 2 y 3 y 4 y 5 y 6 y 8 y 12 y 16 cilindros. ¿Por qué no tenemos autos de 32, 64 y 128 cilindros?
¿Por qué tenemos coches?
@Russell: Porque entonces habría una escasez mundial de cilindros.
@RussellMcMahon: ¿quién dice que no? Aquí hay un Mini Cooper Diesel con 78 litros de cilindrada, dieciocho cilindros, alrededor de 12 turbocompresores, 3.500 caballos de fuerza alucinantes y más de 10.000 libras-pie de torque: topspeed.com/cars/car-news /...
@jippie - Me gusta. PERO solo tiene 18 cilindros :-). Ni siquiera hasta el más bajo de mi lista con 32 cilindros :-).
Pequeño dato interesante sobre los microprocesadores de 128 bits aquí: en.wikipedia.org/wiki/128-bit (ya que se han diseñado al menos dos pero ninguno existe en la práctica).
"El procesador de x bits tiene x líneas de datos". No. El 8088 de Intel, alrededor de 1979, era un procesador de 16 bits con 8 líneas de datos. El 80386-SX de Intel, alrededor de 1988, era un procesador de 32 bits con 16 líneas de datos. Motorola (Freescale) 68000, alrededor de 1979, procesador de 32 bits con 16 líneas de datos. Motorola 68008, alrededor de 1982 Procesador de 32 bits con bus de datos de 8 líneas. Estoy seguro de que hay otros. en.wikipedia.org/wiki/8088 , en.wikipedia.org/wiki/80386SX#The_i386SX_variant , en.wikipedia.org/wiki/Motorola_68000 , en.wikipedia.org/wiki/Motorola_68008
Transmeta sacó un procesador de 256 bits hace un tiempo. Emuló x86 para que pudiera ejecutar aplicaciones estándar. No puedo hablar del rendimiento del de 256 bits, ¡pero el de 128 bits fue un poco lento! en.wikipedia.org/wiki/Transmeta_Crusoe
Porque el mercado aún no está preparado para ellos. La aceptación del mercado es muy importante para el mejor producto.
@OlinLathrop - ¿No te refieres a una escasez global de agujeros ? Esos agujeros grandes y brillantes son caros, ¿sabes?

Respuestas (10)

Piénsalo. ¿Qué imagina exactamente que sería un procesador de "256 bits"? ¿Qué hace que el bit-ness de un procesador en primer lugar?

Creo que si no se hacen más calificaciones, el bit-ness de un procesador se refiere a su ancho ALU. Este es el ancho del número binario que puede manejar de forma nativa en una sola operación. Por lo tanto, un procesador de "32 bits" puede operar directamente en valores de hasta 32 bits de ancho en instrucciones individuales. Por lo tanto, su procesador de 256 bits contendría una ALU muy grande capaz de sumar, restar, OR, AND, etc., números de 256 bits en operaciones individuales. ¿Por qué quieres eso? ¿Qué problema hace que valga la pena tener y pagar la ALU grande y costosa, incluso en aquellos casos en los que el procesador solo cuenta 100 iteraciones de un bucle y similares?

El punto es que debe pagar por la ALU amplia, ya sea que la use mucho o solo una pequeña fracción de sus capacidades. Para justificar una ALU de 256 bits, debe encontrar un problema lo suficientemente importante que realmente pueda beneficiarse de la manipulación de palabras de 256 bits en instrucciones individuales. Si bien es probable que pueda inventar algunos ejemplos, no hay suficientes problemas de este tipo que hagan que los fabricantes sientan que alguna vez obtendrán un retorno de la importante inversión requerida para producir dicho chip. Si hay problemas de nicho pero importantes (bien financiados) que realmente pueden beneficiarse de una ALU amplia, entonces veríamos procesadores muy costosos y altamente específicos para esa aplicación. Su precio, sin embargo, evitaría un uso generalizado fuera de la estrecha aplicación para la que fue diseñado. Por ejemplo, si los 256 bits hicieran posible ciertas aplicaciones criptográficas para el ejército, probablemente surgirían procesadores especializados de 256 bits que costarían entre 100 y 1000 dólares cada uno. Sin embargo, no pondrías uno de estos en una tostadora, una fuente de alimentación o incluso un automóvil.

También debo tener claro que la ALU ancha no solo hace que la ALU sea más costosa, sino también otras partes del chip. Una ALU de 256 bits de ancho también significa que debe haber rutas de datos de 256 bits de ancho. Eso por sí solo requeriría una gran cantidad de área de silicio. Esos datos tienen que venir de algún lugar e ir a algún lado, por lo que tendría que haber registros, caché, otra memoria, etc., para que la ALU amplia se use de manera efectiva.

Otro punto es que puede hacer cualquier aritmética de ancho en cualquier procesador de ancho. Puede agregar una palabra de memoria de 32 bits en otra palabra de memoria de 32 bits en un PIC 18 en 8 instrucciones, mientras que podría hacerlo en la misma arquitectura escalada a 32 bits en solo 2 instrucciones. El punto es que una ALU estrecha no le impide realizar cálculos amplios, solo que los cálculos amplios llevarán más tiempo. Por lo tanto, es una cuestión de velocidad, no de capacidad. Si observa el espectro de aplicaciones que necesitan usar números de ancho particular, verá que muy pocas requieren palabras de 256 bits. El gasto de acelerar solo esas pocas aplicaciones con hardware que no ayudará a las demás simplemente no vale la pena y no es una buena inversión para el desarrollo de productos.

Odio decirlo, pero no estoy de acuerdo aquí. Permítanme idear un ejemplo: renderizado de gráficos para videojuegos. Es un pequeño mercado del que quizás haya oído hablar que vale decenas de miles de millones de dólares.
@Rocket: Primero, el OP preguntó por un microprocesador , no por un procesador de gráficos. En segundo lugar, la representación de gráficos no requiere palabras particularmente amplias. Se pueden realizar muchas operaciones más pequeñas en paralelo, pero no llamaría a 8 núcleos de CPU en paralelo, cada uno trabajando en datos de 32 bits, un procesador de "256 bits". ¿Se refiere a su PC de cuatro núcleos como un procesador de "256 bits" solo porque cada núcleo puede operar con datos de 64 bits de forma nativa? Creo que es un mal uso del término, e incluso el marketing de Intel no parece estar lanzando múltiples núcleos de esa manera.
En ese caso, todavía mal. Llamaría a un Intel Pentium con MMX un microprocesador , y eso tiene SIMD. Esto no debe confundirse con 8 núcleos . SIMD en realidad está implementado por una amplia ALU. Cada núcleo contiene su propia ALU ancha capaz de SIMD.
@Rocket: SIMD es un tipo diferente de paralelismo, pero todavía no lo llamaría una ALU amplia, solo un grupo de ALU pequeñas que se ejecutan estrechamente en paralelo. No puede hacer una adición de 256 bits con todos los acarreos, por ejemplo, en un procesador SIMD de este tipo. El paralelismo no es lo mismo que una ALU más amplia. Parece que te esfuerzas por ser contrario. Tal vez pueda discutir la redacción sobre lo que es paralelo versus más ancho, pero usar definiciones no convencionales y luego afirmar que otras interpretaciones son asombrosamente incorrectas es simplemente participar en un concurso de meadas.
Una instrucción de suma SIMD, por ejemplo, es idéntica a una instrucción de suma muy amplia, excepto que el acarreo se interrumpe en varios puntos.
+1 Sin embargo, agregaría a esta respuesta que si realmente necesita tales operaciones y ejecuta algoritmos que usan tales valores, un procesador de señal digital podría ser una mejor opción, y ya existen. Para tales cálculos, encuentro que un DSP pequeño con capacidad SIMD (datos múltiples de instrucción única, útil para cosas como la multiplicación de vectores) es mucho más útil que un procesador simple con una ALU más amplia.
@Rocketmagnet sí, y un Intel Pentium con MMX no es una "CPU de 128 bits", es de 32 bits. :)
@hobbs: no, es solo un ejemplo temprano de SIMD. Sin embargo, los chips de Intel con AVX son capaces de procesar 256 bits de datos en la ALU en cada instrucción, para cada núcleo . Esto los convierte esencialmente en CPU de 256 bits. Este es un claro ejemplo del hecho de que las CPU de 256 bits tienen sentido y se están fabricando para un mercado que las quiere. Por eso Olin está equivocado.
@Rocket: el hecho de que la CPU pueda funcionar en 256 bits a la vez haciendo un montón de operaciones en paralelo no la convierte en una CPU de "256 bits". Eso implicaría que en realidad puede funcionar directamente en números de 256 bits de ancho, lo que no puede hacer. Como usted mismo dijo, no hay transporte entre las unidades ALU paralelas separadas, lo que hace que no sea una ALU de 256 bits. Parece que tiene una definición inusual de lo que significa el bitness de una CPU. No es la cantidad de bits que puede procesar a la vez, sino el ancho de una palabra que puede procesar como un todo.
@OlinLathrop: eres demasiado rígido en tu forma de pensar. Hay muchas formas de definir el ancho de bit de una CPU, incluido el ancho de la dirección, el ancho del bus, el ancho de la instrucción, el tamaño del registro y el ancho de la ALU. Es bastante razonable llamar a una CPU de 256 bits si puede recopilar dos paquetes de 256 bits de la memoria o los registros, procesarlos a través de una ALU de 256 bits de ancho y volver a escribir 256 bits.
Cuando estaba en la escuela, nos enseñaron que la gente del software medía el bitness en términos del ancho del conjunto de instrucciones "lógicas" y que la gente del hardware medía el bitness en términos del ancho del bus. Entonces, el 8088 era un procesador de 16 bits para la gente de software y un procesador de 8 bits para la gente de hardware. El 8086 era de 16 bits para todos. Por supuesto, la gente de marketing tomaría el mayor número que pudieran encontrar, ¡así que esperemos que no lean este hilo de comentarios y comiencen a comercializar CPU de 512 bits! :-)
@Rocketmagnet Olin en su respuesta principal cubrió excepciones como criptografía (operación matemática de más de 2000 bits, multiplicación, suma) y gráficos. SIMD se usa ampliamente para gráficos, es una forma de realizar ese tipo de matemáticas en paralelo, pero no tiene un caso de propósito general. algoritmos codificados a mano, etc. 32-64 bits es suficiente para el 99% de lo que hacemos, navegar por páginas web llenas de texto e imágenes. Enviar mensajes entre sí y trollear foros. Fuera de estos propósitos especiales, el costo es demasiado alto para la informática general, nadie los compraría.
No estoy seguro de si toda la combinación de 256 bits sería tan útil, ya que usar todo eso requeriría energía ... en.wikipedia.org/wiki/Brute-force_attack#Theoretical_limits
@woliveirajr: Muchos algoritmos criptográficos de clave asimétrica requieren la capacidad de calcular (n1 * n2) mod n3, donde n1, n2 y n3 están todos en el orden de 1000-4000 bits. Un procesador con un gran multiplicador podría ser útil para eso. Por otro lado, si uno desea realizar multiplicaciones de 4096x4096 bits, puede ser más rápido y económico subdividirlas en 256 fragmentos cada 4096x16, que en 256 fragmentos cada 256x256 (el diseño anterior podría canalizarse para producir 16 bits de resultado final por ciclo, sin cadena de transporte de más de 32 etapas).
"Tiene que haber rutas de datos de 256 bits de ancho. Eso por sí solo requeriría una gran cantidad de área de silicio": no olvide la capacitancia parásita. Cambiar un registro de 256 bits de -1 a 0 requeriría mucho jugo. Lo que significa una gran cantidad de calor residual. Lo que significa ventiladores más ruidosos, ventiladores más voluminosos, ventiladores que se desgastan antes. Usted lo consigue.

Bueno, no sé sobre 256 o 512 bits, pero he oído hablar de un procesador de 1024 bits (no puedo encontrarlo ahora). La palabra es VLIW , para palabra de instrucción muy larga . Ese es el bus de instrucciones, no el ancho del bus de datos. Las ventajas son que puede implementar el paralelismo de nivel de instrucción (ILP) a gran escala.

Mi primer encuentro con ILP debe haber sido hace 20 años con los DSP de Motorola, que tenían instrucciones para realizar un MAC (Multiplicar y Acumular) mientras se trasladaban datos hacia y desde la memoria, para que pudiera realizar un nuevo MAC en la siguiente instrucción, sin desperdiciar tiempo entre dos MAC para mover datos.
Hoy en día también existen controladores de propósito general que ofrecen esta opción. VLIW aplica esto a una escala mucho mayor.

Dado que el ancho de su bus de datos no será tan amplio, puede tener varias instrucciones más constantes en una instrucción. La razón por la que el bus de datos no sigue la tendencia es que es bastante inútil; un registro de datos de 64 bits puede representar un número de 20 dígitos decimales. ¿Cuándo fue la última vez que necesitó 20 dígitos de precisión? Para la mayoría de las aplicaciones 10 20 = .

Lectura adicional
Arquitectura VLIW

la mayoría de los cálculos financieros :( me encuentro con este problema ahora
Pensé que el x86 era una CPU VLIW. ;-)
@MarcusLindblom Solo si por VLIW se refiere a palabras de instrucción de longitud variable. ;-)
@MarcusLindblom: probablemente se deba a que tiene instrucciones de longitud variable. Una de las razones por las que todavía le está yendo bien; las instrucciones comunes son más cortas, lo que beneficia al caché de código.
@ AK4749, ¿Está ejecutando transacciones financieras que requieren 20 dígitos decimales? Con mucho gusto intercambiaré cuentas bancarias contigo, incluso si la tuya está denominada en rupias.
@ThePhoton jajaja sí, nadie vio venir esto hace unos años, así que ahora estamos obligados a usar trucos como el redondeo dinámico y otras cosas para evitar que los minúsculos errores de FP se acumulen en unos pocos años al amortizar
@ AK4749, los estándares contables tienen una historia que se remonta mucho antes de que las computadoras estuvieran disponibles en todas las sucursales bancarias. Creo que en los EE. UU., los cálculos solo se hacen a 0,00001 centavos (1/100 mil) más o menos. Si está haciendo finanzas, debe usar punto fijo y usar los estándares de redondeo comunes en su país, no usar punto flotante y tratar de maximizar la precisión más allá de esos estándares.
@ThePhoton Ah, pero ahí es donde tenemos un malentendido. Nos ocupamos de los clientes financieros y sus predicciones . Un número de 12 dígitos antes del decimal puede desviar el valor decimal posterior hasta en una centésima en raras ocasiones que involucran la reproducción de transacciones antiguas con resultados diferentes. Una sola diferencia de centavo puede proyectar más de 1 billón de dólares adicionales en solo una década. La contabilidad actualizada es una ciencia simple y exacta. el nuestro no lo es.
@ AK4749 En ese caso, es probable que sus predicciones sean rechazadas por los bancos que manejan sus transacciones utilizando reglas contables "reales". Lo que significa que si va a ejecutar un plan basado en esas reglas, no dará los resultados esperados porque los bancos reales usarán las reglas de contabilidad reales, no la precisión de nano centavos. Y por supuesto porque los mercados son inciertos. Entonces, si un error de 1 centavo al principio da un error de $ 1 billón en la salida, ese $ 1 billón es solo un efecto de simulación, no es algo que sus clientes deberían usar para hacer planes.
Por supuesto, nunca usarían predicciones de una década como base para las decisiones actuales, incluso yo, como programador, no sería tan tonto. Sin embargo, (y para que quede claro, hemos resuelto el problema del error divergente para que no exista) los clientes más grandes de hecho requieren este tipo de capacidades para cualquier propósito nefasto que elijan no divulgar a sus proveedores. Además, después de haber trabajado en el espacio financiero durante un par de años, puedo decirle que las empresas financieras SÍ utilizan cálculos de mayor precisión (1/2)
(2/2) y, si es necesario, volver a convertirlos a una precisión más baja cuando entregue los datos a un sector/subsidiaria si, por alguna razón, no pueden hacer frente a números de precisión más altos. La banca es un espacio separado de las finanzas y tiene un conjunto de requisitos muy diferente como resultado de tener objetivos diferentes.

El "bitness" de un microprocesador generalmente se define en términos del tamaño de los registros de propósito general. El tamaño determina la cantidad de números que un procesador puede manejar de forma nativa y la cantidad de memoria a la que puede acceder. Los números de 64 bits son suficientes para casi cualquier algoritmo y la cantidad de memoria direccionable (16 millones de terabytes) es suficiente durante bastante tiempo. Simplemente no hay ninguna ventaja en aumentar el tamaño de los registros de propósito general. Por otro lado, el área de unidades aritméticas lógicas (ALU) que se utiliza para realizar operaciones en los registros escala con el cuadrado de la cantidad de bits. Una ALU de 256 bits sería 16 veces más grande y significativamente más lenta.

Por otro lado, tiene sentido ampliar el procesador para que sea posible realizar muchas operaciones más pequeñas a la vez. De hecho, los procesadores Sandy Bridge e Ivy Bridge de Intel hacen precisamente eso, tienen registros SIMD de 256 bits y pueden realizar dos operaciones aritméticas y una operación de memoria por ciclo en ellos. Por lo tanto, uno podría justificar llamarlos procesadores de 256 bits, o incluso de 768 bits, si uno fuera un vendedor astuto que quisiera cambiar los términos que se usan regularmente.

Esa es una arquitectura impresionante.
+1 para "comerciante astuto que quiere doblar los términos que se usan regularmente".

En primer lugar, el tamaño de bits de un procesador generalmente está determinado por la arquitectura abstracta que es visible para el programador de lenguaje de máquina, no por detalles de implementación como el tamaño del bus de datos.

Por ejemplo, el Motorola 68000 es un procesador de 32 bits. Tiene registros de datos de 32 bits y registros de direcciones de 32 bits. Ahora, la primera versión de esa familia arquitectónica solo expone 24 bits de líneas de dirección. Además, existen variantes que tienen solo un bus de datos de 8 bits (por lo que el procesador realiza operaciones de memoria de 32 bits como ciclos de acceso múltiple).

Ahora sobre la pregunta, ¿por qué no ir a 256 y 512? Los procesadores manipulan "de forma nativa" varios tipos de datos, por lo que es útil ver qué significan 256 o 512 bits para cada uno de estos tipos de datos individualmente. Tenemos enteros, punteros y tipos de coma flotante.

  1. Números enteros: los programas aprovechan mucho los números enteros de 32 y 64 bits. Si 64 bits es una limitación, la solución es tener enteros bignum implementados por software. Los lenguajes de alto nivel pueden implementar tipos enteros de modo que las operaciones cambien sin problemas entre "fixnums" y "bignums". Por supuesto que recibe un golpe de rendimiento con bignums, pero debe considerar eso en el panorama general: cuántas de las operaciones en un programa son operaciones bignum. Los números de 256 o 512 bits no eliminan la necesidad de números grandes, solo aumentan el margen antes de que tengamos que cambiar a números grandes. Si desea manipular claves públicas de 2048 bits, los enteros de 512 bits no funcionarán (pero un número grande con dígitos de 512 bits podría ser rápido).

  2. Punteros: los punteros más anchos permiten dos cosas: espacios de direcciones más amplios y metadatos adicionales almacenados en un puntero. Los espacios de direcciones son virtuales en estos días y, por lo tanto, pueden crecer incluso si los recuerdos no crecen. Se ha propuesto que si tiene punteros de 128 bits, el espacio de direcciones es tan amplio que puede colocar todos los procesos de espacio de usuario de un sistema operativo y el kernel en lugares aleatorios en un solo espacio desprotegido, y es poco probable chocar. En lugar de simplemente crear un espacio de direcciones más grande, se pueden usar punteros más gruesos para transportar bits que no son bits de dirección, como información sobre el objeto de referencia (tipo, tamaño y otra información) o información relacionada con la seguridad. Probablemente haya algo de "gordura óptima" para este tipo de cosas, y si tuviera que adivinar, todavía lo limitaría a 128 bits. no Parece que tiene sentido ir a punteros de 256 bits, no importa 512. Los punteros más gruesos tienen una desventaja: inflan todas las estructuras de datos que contienen punteros. Y, en general, desea que los punteros tengan el mismo tamaño; de lo contrario, necesita complicaciones en la arquitectura del conjunto de instrucciones (como segmentos de memoria) por lo que luego tiene punteros completos (descriptor de segmento y desplazamiento) o solo punteros locales (desplazamiento dentro de algún segmento entendido) .

  3. Tipos de coma flotante: Más bits en números de coma flotante significan más precisión. Diría que los tipos de coma flotante son los que más se benefician de una representación más amplia. Un tipo flotante de 256 o 512 bits mejorará la estabilidad del código numérico y la calidad de los cálculos científicos que requieren muchas iteraciones y acumulan errores en el camino. La precisión en punto flotante no es lo mismo que la precisión en números enteros: no podemos separar el tipo de punto flotante en rangos como números fijos versus números grandes. Una mayor precisión en el punto flotante afecta la calidad de todos los números inexactos, ya sean cercanos a cero o de gran magnitud. Más bits en los exponentes de coma flotante también pueden ampliar enormemente el rango de números de coma flotante, y mucho más rápido que agregar bits a un número entero grande.

Por estas razones, sospecho que la tendencia futura predominante serán los aumentos en el ancho de los números de punto flotante de hardware, no necesariamente seguidos por aumentos en el ancho de los punteros y los números enteros.

Recuerde que los números de punto flotante ya se han adelantado a los otros tipos en el pasado. Por ejemplo, durante un tiempo tuvimos un predominio de procesadores de 32 bits compatibles con flotadores dobles IEEE de 64 bits. Esto se debe a que, si bien puede hacer mucho con punteros y números enteros de 32 bits, los números flotantes de 32 bits son muy limitados para cualquier trabajo numérico serio.

Una característica muy, muy útil que sería bueno ver emerger en las representaciones de coma flotante serían algunos bits de repuesto para una etiqueta de tipo. La implementación de tipos de punto flotante en lenguajes dinámicos de alto nivel (en los que los objetos tienen tipo, pero las ubicaciones de almacenamiento contienen valores de cualquier tipo) es una lucha porque, mientras que los bits de repuesto se pueden encontrar en punteros y objetos de tipo entero para poner partes de un etiqueta de tipo de identificación, esto es difícil de hacer con números de coma flotante. Entonces, lo que sucede a menudo es que los números de punto flotante se asignan en montón. Algunos esquemas roban bits de la mantisa, por lo que los tipos de coma flotante en ese idioma pierden precisión en comparación con los flotantes en otros idiomas en la misma máquina.

Buena descripción. Por cierto, los procesadores x86 comunes han tenido punto flotante de 80 bits durante mucho tiempo, desde la primera unidad de punto flotante de hardware para ellos, si no recuerdo mal. Los 80 bits son internos a la FPU, luego generalmente se exportan 32 o 64 bits.
Técnicamente, ya está hecho. Google "boxeo nan" o "boxeo monja". Lo que es más prometedor son las etiquetas de tipo de hardware en ARM de 64 bits, pero lamentablemente no será pronto.
Era posible acceder a la versión 80 directamente. En los años 90, cuando estaba aprendiendo a programar en TurboPascal, había un tipo flotante de 80 bits.
@DanNeely: A veces he pensado que los procesadores se beneficiarían de los tipos de punto flotante de coordenadas 3D, combinando tres números de 80 bits en un fragmento de 256 bits, o tres números de 42 bits en un fragmento de 128 bits, o tres números de 21 bits en un fragmento de 64 bits. Me pregunto qué tan difícil sería implementar tal cosa y qué tan útil podría terminar siendo.
@supercat GPGU Wikipedia: La mayoría de las operaciones en la GPU [NVidia] funcionan de manera vectorizada: una operación se puede realizar en hasta cuatro valores a la vez. Por ejemplo, si un color <R1, G1, B1> debe ser modulado por otro color <R2, G2, B2>, la GPU puede producir el color resultante <R1*R2, G1*G2, B1*B2> en una operación.
@Kaz: mi pregunta se basó en la observación de que, si bien 256 bits serían suficientes para almacenar solo dos valores de 80 bits que se ampliaron a 128 bits cada uno, el relleno de tripletes a 256 bits produciría una mejor eficiencia de almacenamiento/bus/caché, y los números a menudo se usan en trillizos. Echo de menos los tipos de punto flotante de hardware de 80 bits que mis compiladores de Borland solían admitir, y me gustaría que se usaran más. Más lejos. Los tipos de bits 40ish serían mejores que 32, y 20ish mejor que 16, en los casos que necesiten formatos pequeños para valores XYZ.

En realidad, no te ayuda a hacer nada útil. Los números de 64 bits le brindan suficiente precisión para casi todos los propósitos (aunque los sistemas Intel tienen un punto flotante de 80 bits), pero las líneas adicionales aumentan el costo y el consumo de energía al tiempo que tienen un pequeño impacto negativo en la velocidad del reloj.

Históricamente, las CPU usan la cantidad mínima de bits que tiene sentido práctico para su propósito previsto. Con los avances en tecnología, se hicieron posibles autobuses y ALU más anchos, de ahí el aumento en el tamaño del autobús para servir a una aplicabilidad más amplia:

  • 4 bits: suficiente para un dígito, por lo tanto, práctico para calculadoras (estilo BCD), cajas registradoras, etc. (que es un área bastante limitada)
  • 8 bits: suficiente para un carácter (ASCII), práctico para sistemas de procesamiento de texto (que es un área MUY amplia), también para sonido de baja calidad
  • 16 bits: cuando los 16 bits eran populares, 2^16 direcciones de memoria eran una cantidad razonable (al menos mucho más razonable que 2^8 o 2^32). 16 bits producen una calidad de audio bastante aceptable, y la mayoría de los convertidores A/D producen menos de 16 bits de resultado, por lo tanto, tiene sentido calcular estos valores en 16 bits.
  • 32 bits: 32 bits se ajusta a la precisión de la mayoría (pero no de todas) las cantidades medidas por humanos y, a menos que se trate de grandes bases de datos, 2^32 direcciones eran adecuadas para la mayoría de los propósitos prácticos.
  • 64 bits: tener > 2^32 bytes de memoria ahora es práctico.
  • 128 bits: en este momento poca ventaja sobre 32, excepto en criptografía. ¿Cuándo esperamos más de 2^64 bytes en un disco duro? probablemente no pronto.
Probablemente necesites leer los enlaces de stevenvh e investigar más antes de decir eso.
"640K debería ser suficiente para cualquiera". -Bill Gates (1981)
@jippie: Gates nunca dijo eso.
@Rocketmagnet Pensé que eso también era cierto, pero supongo que tienes razón wired.com/politics/law/news/1997/01/1484
En realidad, la mayoría de las CPU de 8 bits pudieron abordar 2 ^ 16 bytes de memoria y 16 bits amargos 2 ^ 32, el 80386 (32 bits) en teoría también podría abordar 2 ^ 64 bytes (4 GB) de memoria que habría sido bastante inútil en esos días de todos modos...
@Rocket: pertenece a la lista de citas famosas que no son ciertas, como "Tócala de nuevo, Sam", que Bogart tampoco dijo nunca.
@Axel: el 8086 de 16 bits solo podía abordar 2 20 bytes de memoria, y cuando descubrieron que no era suficiente, tuvieron que idear cosas horribles como administradores de memoria extendidos y expandidos.
@stevenvh El 8086 salió en 1978 (los esfuerzos de diseño comenzaron unos años antes), momento en el que 1 MiB de RAM debe haber parecido tan extremo como 4 GiB de RAM cuando debutó el 80386 en 1985-1986. Compare el TRS-80 que inicialmente se envió con 4 KiB de RAM en 1977. Hoy en día, tener más de 4 GiB de RAM es común incluso en las PC domésticas de gama baja a media (mi PC en casa tiene 32 GiB de RAM, que era casi inconcebible incluso como almacenamiento secundario para algo parecido a una PC en la época en que se introdujo el 80386 y un disco duro de quizás 100 MB se consideraba grande).
Sí, recuerdo los días... no todo era mejor entonces ;-)
@MichaelKjörling: No estoy seguro de si los discos duros de 100 MB existían en ese entonces. FAT solo podía manejar razonablemente particiones hasta un cierto tamaño, y la cantidad de particiones por disco tampoco era ilimitada. La primera computadora con disco duro que vi tenía 10 MB increíbles (IBM XT). Nadie sabía qué hacer con tanto almacenamiento en ese momento...
@Axel: mi primera PC tenía un disco duro gigantesco de 80 MB, que tuve que particionar en dos 32 MB y una partición de 16 MB, ya que 32 MB era el máximo que DOS podía manejar.
@Axel Ese es mi punto. Una PC basada en 386 que teníamos en casa en ese momento tenía un disco duro de 40 MB, según recuerdo. Sé que había discos más grandes destinados al mercado de servidores de red y de gama alta, pero no sé si existían unidades de 100 MB en ese entonces. Sin embargo, eso no viene al caso, ya que una unidad de este tipo se habría considerado grande en ese momento, en contraste con el hecho de que en estos días, muchas PC domésticas tienen varios GB de RAM .
En realidad, Wikipedia menciona para noviembre de 1985 "muchos discos de 40 y 80 megabytes estaban en uso" fuente (aproximadamente a la mitad de la página)
@Michael: es de todos los tiempos, y lo he visto a lo largo de toda mi carrera: hay muy pocos gerentes de producto realmente visionarios. Anécdota: principios de la década de 1970, en una conferencia de Robert Noyce sobre el futuro de los microprocesadores, predice la miniaturización actual, y alguien en la audiencia dice: "Maldita sea, no me gustaría perder una computadora entera en una grieta en el piso". A lo que Noyce respondió con desprecio: "No lo entiendes para nada. No te importa ese que perdiste; tendrás miles de otros". Eso fue a principios de la década de 1970. Robert Noyce fue un visionario.
@Michael: el procesador 6809 de 8 bits tenía un chip MMU complementario, el 6829, que podía manejar 2 MB. Para un 8-bitter, anterior a 1980.
@stevenvh Esto comienza a parecer una discusión extensa, pero, por supuesto, puede idear una arquitectura que permita abordar más memoria incluso con una CPU de bajo número de bits. Estaba diciendo que con los tamaños de memoria de la época y la forma en que probablemente se imaginó que se usaría el 8086, podría no haber sido un criterio de diseño importante poder usar cantidades tan grandes como más de 1 MiB de RAM directamente. Esto se resolvió cuando apareció el 80286 en 1982 y podía abordar directamente 16 MiB de RAM, pero muy pocas aplicaciones de DOS aprovecharon esa capacidad y pocas PC tenían tanta RAM.
Si mis cálculos son correctos, ¡64 bits son suficientes para especificar el tamaño del universo a la longitud de Planck más cercana!
@Rocket - Universo observable de diámetro: 46 mil millones de años luz. 1 año luz = 9,5 x 10^15 m. -> el universo mide 4,4 x 10^26 m, = 2^88 m, que ya es mayor que 2^64. En longitudes de Planck: 2,7 x 10^61 = 2^204. ¡Parece que necesitaremos ese procesador de 256 bits después de todo! :-)
@stevenvh - ¡Maldita calculadora de Windows! Aparentemente tiene una longitud máxima de números binarios de 64 dígitos. Pensé que sonaba demasiado increíble para ser verdad.

En realidad, tales procesadores existen y son comunes, dependiendo de cómo definas el bitness. Es casi seguro que estás usando uno ahora. Como explicó Olin, no hay mucho uso para los números de 256 bits, pero ¿qué pasa con los números de 4 x 32 bits? ¿Y si la ALU pudiera sumar 4 pares de números de 32 bits al mismo tiempo? Tales ALU (que yo sepa) se implementaron por primera vez en supercomputadoras vectoriales en la década de 1970. La primera vez que tuve una computadora de este tipo fue cuando tuve uno de los Intel Pentium con MMX.

Chico Intel MMX

¿Recuerdas a esos tipos?

Los chips MMX tenían un conjunto de instrucciones de instrucción única - datos múltiples ( SIMD ), lo que le permitía agregar 1 par de 64 bits, 2 pares de 32 bits, 4 pares de 16 bits u 8 pares de 8 bits.

Pero eso no es nada. Una tarjeta gráfica moderna tiene una GPU (que solía significar Unidad de procesamiento de gráficos, pero ahora significa Unidad de procesamiento general). Suelen ser implementaciones SIMD amplias, capaces de bifurcarse, cargar y almacenar en 128 o 256 bits a la vez. La microarquitectura prototipo Larrabee de Intel incluye más de dos registros SIMD de 512 bits en cada uno de sus núcleos.

Tarjeta SIM de GPU

Tenga en cuenta que SIMD no debe confundirse con multinúcleo. Cada núcleo de una CPU tendrá su propia ALU amplia capaz de sumar un conjunto de números enteros.

"1 par de 16 bits, 2 pares de 32 bits, 4 pares de 16 bits o 8 pares de 8 bits" ¿Está seguro de que entendió bien esa parte?
A primera vista, parecía un Kraft Single con el logotipo de Intel.
Las variables de 4x32 bits siguen siendo solo 32 bits. El bit-ness es el número entero individual máximo en el que puede operar la ALU. Hacerlo muchas veces en paralelo no aumenta el ancho de bits. -1
@ConnorWolf: no creo que esté usando la misma definición de bits que RocketMagnet. Parece que estás mirando los bits por palabra, mientras que creo que él está mirando el total de bits procesados ​​en un ciclo de reloj. (Procesado o transferido). En mi humilde opinión, se trata del rendimiento, ya sea de MIPS o de la tasa de transferencia sin procesar entre el procesador y la RAM, etc. Así que reconsidere su -1. Gracias.
Para probar si la palabra puede hacer eso, sustitúyalo por "tamaño de bits" y vea si funciona. Está hablando del tamaño de bit del bus y de la potencia de procesamiento de SIMD, pero usted cree que solo debería hablar del tamaño de bit de la instrucción individual o del tamaño de bit del cálculo individual. Creo que bit-ness (tamaño de bit) funciona en ambas configuraciones. ¿no?

Porque aún no lo necesitamos.

Normalmente, el bitness (que yo definiría como el número de bits en un registro) se traduce más o menos directamente en la cantidad de memoria direccionable. Por supuesto, esto se simplifica, ya que dependiendo del procesador, puede haber registros que tengan 2 veces la longitud del valor de bits, o existen técnicas para eludir esas limitaciones de memoria (¿alguien por ahí recuerda haber hecho programación en ventanas de 16 bits?).

"¿Por qué no simplemente aumentan el número de líneas de datos y crean una de 256 bits?"

De hecho, todos los procesadores Intel que se ajustan al zócalo LGA-2011 tienen 256 pines de datos, que se conectan a 256 líneas de datos en la placa base que conducen a la DRAM. Me sorprendería un poco si la computadora portátil o de escritorio más reciente que usó no tuviera al menos 256 líneas de datos. ¿Puedo preguntar de dónde sacaste esta idea errónea de que "no... simplemente aumentan el número de líneas de datos"?

La hoja de datos del zócalo LGA-211 (era: hoja de datos del zócalo LGA-2011 ), sección 6.1, indica que estas CPU tienen 256 pines de datos y 76 pines de dirección (dirección de banco + dirección de memoria).

porque no hay aplicación que necesite o tenga las posibilidades de representar datos usando más de 128 bits a la vez.

y ya sabes, los procesadores multimedia y las tarjetas gráficas llegarán mucho antes que las CPU de las placas base, solo porque con foto/video tiene sentido usar longitudes de datos tan grandes para procesarlas a la vez.

Un sistema informático es, en su sentido, una máquina informática, que requiere algunas entradas y proporciona algunas salidas. Tenemos que satisfacer a la computadora en estas líneas, por lo tanto, los desarrolladores llegaron a tener un punto de referencia al tener 3 Buses, a saber, Bus de direcciones, Bus de datos y Bus de control. 1) El bus de direcciones busca/selecciona una dirección particular en la memoria, para operaciones de lectura/escritura. 2) El bus de datos luego obtiene los datos que presentan estos datos hacia/desde el procesador y la memoria para fines de procesamiento/almacenamiento. 3) El bus de control crea un protocolo de control de interfaz y le pide al sistema que lo respete.

Estos son necesarios para realizar cálculos útiles para un usuario/servidor/cliente. En general, el rendimiento (velocidad de finalización de tareas, menos fallas, etc.) depende de la eliminación de cuellos de botella en el sistema. es decir, si la CPU puede procesar a una velocidad mucho más alta que la velocidad de transferencia desde una unidad de disco duro, entonces el cuello de botella se produce en la unidad de disco duro. Del mismo modo, necesitamos tener una velocidad de procesamiento adecuada para velocidades de datos y ancho de código en particular.

Desde el principio, debido a varias razones como la complejidad de H/W, el costo, los requisitos, los algoritmos efectivos y la razón principal por la que el alcance del mercado son los principales obstáculos para la producción de ancho de bus de datos alto, como lo menciona el host de preguntas, digamos 256 bits o 512 bits ¡Estos son posibles! Pero el requisito aún no está presente, el alcance del mercado aún no es visible con las necesidades actuales y la ausencia de soporte de software complementario.

El procesador de 256 bits indica el ancho del bus de datos que ese procesador en particular puede manejar o que la ALU puede procesar en una sola ejecución. Empezamos de 4 bits, luego 8,16,32 y actualmente 64 y hasta 128 bits que son los Productos de Alcance de Mercado actuales.

Entonces, antes de hacer estas preguntas, siempre debe ver la demanda del lado del mercado y su alcance. En la historia, es la única forma directa de comprender las formas de vida. Si no puedes permitírtelo, ¿cómo puedes comprarlo? y si no puedes comprarlo, ¿cómo puede producir el productor? y si no puede producir, entonces no hay existencia para ese producto!!

Usar mayúsculas en los sustantivos hace que esto sea difícil de leer.
hmm, sí tengo que empezar a hacer eso.
@pjc50 ¿Tal vez sea de Alemania? Oh, espera, "Preguntar" y "Comprar" también están en mayúscula, tal vez no...