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?
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.
(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).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 = .
Lectura adicional
Arquitectura VLIW
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.
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.
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).
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) .
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.
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:
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.
¿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.
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.
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!!
olin lathrop
Ignacio Vázquez-Abrams
Rocketmagnet
olin lathrop
Brendan largo
Russel McMahon
Rocketmagnet
olin lathrop
yippie
Russel McMahon
mikebabcock
Indemnización de Shannon
Mateo Campanarios
Chetan Bhargava
Juan U.