¿Por qué no hacer un gran núcleo de CPU? [cerrado]


25

No entiendo por qué los fabricantes de CPU hacen chips de múltiples núcleos. El escalado de múltiples núcleos es horrible, esto es altamente específico de la aplicación, y estoy seguro de que puede señalar cierto programa o código que funciona muy bien en muchos núcleos, pero la mayoría de las veces el escalado es basura. Es un desperdicio de espacio de matriz de silicio y un desperdicio de energía.

Los juegos, por ejemplo, casi nunca usan más de cuatro núcleos. Las simulaciones de ciencia e ingeniería como Ansys o Fluent tienen un precio por la cantidad de núcleos que tiene la PC en la que se ejecuta, por lo que paga más porque tiene más núcleos, pero el beneficio de más núcleos se vuelve realmente pobre después de los 16 núcleos, pero tiene estos 64 núcleos estaciones de trabajo ... es un desperdicio de dinero y energía. Es mejor comprar un calentador de 1500 W para el invierno, mucho más barato.

¿Por qué no hacen hacer una CPU con un solo núcleo grande?

Creo que si hicieran un equivalente de un núcleo de una CPU de ocho núcleos, ese núcleo tendría un aumento del 800% en IPC, por lo que obtendría el rendimiento completo en todos los programas, no solo aquellos que están optimizados para múltiples núcleos. Más IPC aumenta el rendimiento en todas partes, es una forma confiable y sencilla de aumentar el rendimiento. Múltiples núcleos aumentan el rendimiento solo en un número limitado de programas, y el escalado es horrible y poco confiable.


Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat . Cualquier conclusión alcanzada debe ser editada nuevamente en la pregunta y / o cualquier respuesta (s).
Dave Tweed

Te puede interesar este artículo: gotw.ca/publications/concurrency-ddj.htm
lvella

"pero el beneficio de más núcleos se vuelve realmente pobre después de 16 núcleos" Obviamente no sabes de qué estás hablando. Confía en mí, he trabajado en procesos que se ejecutan en algunas decenas de miles de CPU. Hay toda una clase de problema llamada "vergonzosamente paralelizable", donde arrojar más núcleos al problema funciona muy bien.
Aron

Respuestas:


93

El problema radica en la suposición de que los fabricantes de CPU pueden agregar más transistores para hacer que un solo núcleo de CPU sea más potente sin consecuencias.

Para hacer que una CPU haga más, debe planificar qué implica hacer más. Realmente hay tres opciones:

  1. Haga que el núcleo funcione a una frecuencia de reloj más alta : el problema con esto es que ya estamos llegando a las limitaciones de lo que podemos hacer.

    El uso de energía y, por lo tanto, la disipación térmica aumenta con la frecuencia: si duplica la frecuencia, nominalmente duplica la disipación de energía. Si aumenta el voltaje, su disipación de energía aumenta con el cuadrado del voltaje.

    Las interconexiones y los transistores también tienen retrasos de propagación debido a la naturaleza no ideal del mundo. No puede simplemente aumentar el número de transistores y esperar poder funcionar a la misma frecuencia de reloj.

    También estamos limitados por hardware externo, principalmente RAM. Para acelerar la CPU, debe aumentar el ancho de banda de la memoria, ya sea ejecutándola más rápido o aumentando el ancho del bus de datos.


  1. Agregue instrucciones más complejas : en lugar de ejecutar más rápido, podemos agregar un conjunto de instrucciones más rico: las tareas comunes como el cifrado, etc., pueden endurecerse en el silicio. En lugar de tomar muchos ciclos de reloj para calcular en software, tenemos aceleración de hardware.

    Esto ya se está haciendo en los procesadores de Conjunto de instrucciones complejas (CISC). Ver cosas como SSE2, SSE3. Un solo núcleo de CPU hoy en día es mucho más poderoso que un núcleo de CPU de hace incluso 10 años, incluso si se ejecuta a la misma frecuencia de reloj.

    El problema es que, a medida que agrega instrucciones más complicadas, agrega más complejidad y hace que el chip crezca. Como resultado directo, la CPU se vuelve más lenta : las frecuencias de reloj alcanzables disminuyen a medida que aumentan los retrasos de propagación.

    Estas complejas instrucciones tampoco le ayudan con tareas simples. No puede endurecer todos los casos de uso posibles, por lo que inevitablemente grandes partes del software que está ejecutando no se beneficiarán de las nuevas instrucciones y, de hecho, se verán perjudicadas por la reducción de la frecuencia de reloj resultante.

    También puede aumentar el ancho del bus de datos para procesar más datos a la vez; sin embargo, esto hace que la CPU sea más grande y alcanza una compensación entre el rendimiento obtenido a través de buses de datos más grandes y la caída de la velocidad del reloj. Si solo tiene datos pequeños (por ejemplo, enteros de 32 bits), tener una CPU de 256 bits realmente no lo ayuda.


  1. Haga que la CPU sea más paralela : en lugar de intentar hacer una cosa más rápido, haga varias cosas al mismo tiempo. Si la tarea que está realizando se presta para operar en varias cosas a la vez, entonces desea una sola CPU que pueda realizar múltiples cálculos por instrucción (Single Instruction Multiple Data (SIMD)), o tener múltiples CPU que puedan realizar una cálculo.

    Este es uno de los controladores clave para CPU de varios núcleos. Si tiene múltiples programas ejecutándose, o puede dividir su único programa en múltiples tareas, entonces tener múltiples núcleos de CPU le permite hacer más cosas a la vez.

    Debido a que los núcleos individuales de la CPU son efectivamente bloques separados (excluyendo cachés e interfaces de memoria), cada núcleo individual es más pequeño que el núcleo monolítico único equivalente. Debido a que el núcleo es más compacto, se reducen los retrasos de propagación y puede ejecutar cada núcleo más rápido.

    En cuanto a si un solo programa puede beneficiarse de tener múltiples núcleos, eso se debe totalmente a lo que ese programa está haciendo y cómo se escribió.


Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat . Cualquier conclusión alcanzada debe ser editada nuevamente en la pregunta y / o cualquier respuesta (s).
Dave Tweed

Uno de los puntos planteados en los comentarios que aún no se ha abordado es que las CPU pueden ser paralelas ejecutando múltiples instrucciones por reloj (Superscalar). Eso es ortogonal a SIMD y frecuencia; instrucciones por reloj (IPC) es el tercer factor en el rendimiento real por hora. Todas las CPU modernas para cargas de trabajo de uso interactivo tienen al menos 2 de ancho.
Peter Cordes


37

Además de las otras respuestas, hay otro elemento: rendimientos de chips . Un procesador moderno tiene varios miles de millones de transistores, todos y cada uno de esos transistores tienen que funcionar perfectamente para que todo el chip funcione correctamente.

Al hacer procesadores multinúcleo, puede particionar limpiamente grupos de transistores. Si existe un defecto en uno de los núcleos, puede deshabilitar ese núcleo y vender el chip a un precio reducido de acuerdo con la cantidad de núcleos en funcionamiento. Del mismo modo, también puede ensamblar sistemas a partir de componentes validados como en un sistema SMP.

Para prácticamente todas las CPU que compra, comenzó a ser un modelo premium de alta gama para esa línea de procesadores. El resultado final depende de qué partes de ese chip funcionen incorrectamente y estén deshabilitadas. Intel no fabrica ningún procesador i3: todos son defectuosos i7, con todas las características que separan las líneas de productos deshabilitadas porque fallaron las pruebas. Sin embargo, las porciones que aún funcionan siguen siendo útiles y se pueden vender por mucho más barato. Cualquier cosa peor se convierte en baratijas de llavero.

Y los defectos no son infrecuentes. La creación perfecta de esos miles de millones de transistores no es una tarea fácil. Si no tiene oportunidades de usar selectivamente partes de un chip dado, el precio del resultado aumentará, muy rápido.

Con un solo procesador über, la fabricación es todo o nada, lo que resulta en un proceso mucho más derrochador. Para algunos dispositivos, como los sensores de imágenes con fines científicos o militares, donde se necesita un sensor enorme y todo tiene que funcionar, los costos de esos dispositivos son tan enormes que solo los presupuestos a nivel estatal pueden pagarlos.


44
Si / cuando los rendimientos mejoran y están produciendo más chips que funcionan completamente de lo que demanda el mercado, los proveedores generalmente comienzan a fusionar algunos de los núcleos / caché y / o agruparlos en SKU de frecuencia más baja, en lugar de ajustar la estructura de precios para hacer el alto chips finales relativamente más baratos. Con GPU / tarjetas gráficas, solía poder desbloquear unidades de sombreado deshabilitadas en algunas tarjetas con un pirateo de firmware, para ver si tuvo suerte y obtuvo una tarjeta donde solo estaban deshabilitadas para la segmentación del mercado, no defectos reales.
Peter Cordes

44
Intel ha fabricado matrices de doble núcleo para algunos de sus chips. Con todos sus SKU móviles ULV (voltaje ultra bajo) de doble núcleo, no había suficientes núcleos cuádruples defectuosos, y el área de matriz más pequeña (especialmente con un iGPU reducido también) proporciona más chips de doble núcleo en funcionamiento por oblea que fusionar troqueles de cuatro núcleos. en.wikichip.org/wiki/intel/microarchitectures/… tiene inyecciones de Sandybridge 131 mm² tamaño de matriz de doble núcleo + gráficos GT1, frente a 149 mm² de doble núcleo + gráficos GT2 + 216 mm² cuádruple + GT2. Todavía hay espacio para defectos en el caché, etc.
Peter Cordes

Y (algunos) defectos en parte de una unidad FMA pueden manejarse presumiblemente fundiéndolo y vendiéndolo como un chip Celeron o Pentium (sin AVX, por lo que solo son vectores de 128 bits). Incluso los modernos chips Skylake o Coffee Lake Pentium carecen de AVX . Las unidades SIMD FMA constituyen una fracción decente de un núcleo (y ejecutan muchas operaciones SIMD además de las matemáticas de FP, incluidos el número entero mul y el cambio de número entero), por lo que no me sorprendería si las unidades FMA de 2x 256 bits se pueden asignar a 2x 128 bits usando los 2 fragmentos que aún funcionan. Con Skylake Xeon, incluso hay SKU con un rendimiento reducido de AVMA FMA AVX512 (solo 1 FMA de 512 bits en funcionamiento)
Peter Cordes

@PeterCordes Si los rendimientos se vuelven tan buenos, entonces los vendedores sacarán diseños de mayor densidad y / o velocidad de reloj más rápida (y, por lo tanto, una mayor tasa de defectos) hasta que las tasas de defectos vuelvan a donde puedan deshabilitar los núcleos y / o sub-reloj los chips para vender con descuento ..
Monty Harder

@MontyHarder: Eso es cierto, pero la validación cuesta dinero y tiempo, y las líneas de producción existentes seguirán haciendo diseños existentes por un tiempo. Pero sí, algunos ejemplos de Intel de lo que estás hablando son Haswell Refresh , y varios refinamientos de Skylake básicamente sin cambios arquitectónicos y mejoras menores en su proceso de 14nm. (A veces con nueva iGPU). por ejemplo, Kaby Lake y luego Coffee Lake, etc., como pasos de "optimización" en la cadencia normal de Intel.
Peter Cordes

26

Dependencia de datos

Es bastante fácil agregar más instrucciones por reloj al hacer un chip "más ancho": este ha sido el enfoque "SIMD". El problema es que esto no ayuda a la mayoría de los casos de uso.

Hay aproximadamente dos tipos de carga de trabajo, independiente y dependiente. Un ejemplo de una carga de trabajo independiente podría ser "dadas dos secuencias de números A1, A2, A3 ... y B1, B2, ... etc., calcular (A1 + B1) y (A2 + B2) etc." Este tipo de carga de trabajo se ve en gráficos de computadora, procesamiento de audio, aprendizaje automático, etc. Mucho de esto se ha dado a las GPU, que están diseñadas especialmente para manejarlo.

Una carga de trabajo dependiente podría ser "Dado A, agregue 5 y busque eso en una tabla. Tome el resultado y agregue 16. Busque eso en una tabla diferente".

La ventaja de la carga de trabajo independiente es que se puede dividir en muchas partes diferentes, por lo que más transistores ayudan con eso. Para cargas de trabajo dependientes, esto no ayuda en absoluto: más transistores solo pueden hacerlo más lento . Si tiene que obtener un valor de la memoria, eso es un desastre para la velocidad. Se debe enviar una señal a través de la placa base, viajando a baja velocidad, la DRAM tiene que cargar una fila y esperar el resultado, luego enviarla de regreso. Esto toma decenas de nanosegundos. Luego, después de hacer un cálculo simple, debe enviar el siguiente.

Administración de energía

Los núcleos de repuesto están apagados la mayor parte del tiempo. De hecho, en muchos procesadores, no puede ejecutar todos los núcleos todo el tiempo sin que la cosa se incendie, por lo que el sistema los apagará o los bloqueará por usted.

Reescribir el software es la única forma de avanzar

El hardware no puede convertir automáticamente las cargas de trabajo dependientes en cargas de trabajo independientes. Tampoco el software. Pero un programador que está preparado para rediseñar su sistema para aprovechar muchos núcleos podría hacerlo.


2
Cita necesaria para "no se pueden ejecutar todos los núcleos al mismo tiempo". A menos que considere que la velocidad máxima del reloj turbo de un solo núcleo es la velocidad de reloj "real" de la CPU. En el sentido clásico (antes de llegar a la pared de potencia y la velocidad del reloj estaba limitada por retrasos críticos en la propagación de la ruta), sí, eso es cierto, pero en el mundo moderno tiene más sentido mirar la velocidad del reloj de referencia como lo que se puede mantener con todos núcleos activos ejecutando cargas de trabajo pesadas. Cualquier cosa más alta que eso es salsa que puede usar de manera oportunista según lo permitan los límites de potencia / térmica. (por ejemplo, el Turbo de Intel).
Peter Cordes

1
Pero en términos de potencia, incluso el reloj máximo de un solo núcleo está limitado por las temperaturas más que por los retrasos de propagación (aunque probablemente los límites de la etapa de la tubería se seleccionen para que esté cerca de ese límite en el turbo máximo objetivo). Y el voltaje también es una variable: peor potencia pero retardos de puerta más cortos. De todos modos, no tiene sentido considerar el turbo máximo de un solo núcleo como algo en lo que "debería" poder ejecutar todos los núcleos, porque ese límite ya proviene del poder.
Peter Cordes

El contexto de la pregunta original definitivamente era preguntar sobre la velocidad máxima de un solo núcleo, y para muchos propósitos prácticos que (y sus errores de caché) son el factor limitante real para la velocidad percibida por el usuario.
pjc50

Sí, si pudiéramos, todos tomaríamos un rendimiento 8x de un solo hilo en lugar de una CPU de 8 núcleos. (Con SMT para permitirle ejecutar cargas de trabajo separadas de forma natural sin sobrecarga de cambio de contexto. Vea mi respuesta. :) Un núcleo súper ancho hipotético probablemente podría sincronizarse más rápido cuando la carga de trabajo causó muchas paradas, en lugar de mantener todas los transistores en las unidades SIMD FMA se activan y cambian cada reloj (La activación de energía dentro de un solo núcleo también es clave para no fundirse en relojes altos; en.wikipedia.org/wiki/Dark_silicon ). Entonces, tener un solo núcleo ancho no lo haría diferente.
Peter Cordes

Aunque tiene un punto de vista, el rendimiento de un solo subproceso que vemos en las CPU actuales es mejor que si estuvieran limitados a una velocidad de reloj que pudieran mantener en todos los núcleos simultáneamente, incluso con una carga de trabajo en el peor de los casos. es decir, Turbo es clave, especialmente para partes de bajo TDP como chips de computadoras portátiles ( ¿Por qué mi CPU no puede mantener el máximo rendimiento en HPC? ): generalmente una gran relación entre la línea base y el turbo máximo, a diferencia de los chips de escritorio de alta potencia pero bajo conteo de núcleos , p. ej., i7-6700k Skylake es una base de 4 GHz, un turbo de núcleo único de 4.2 GHz (sin overclocking; más alto es posible con TDP de 95 W).
Peter Cordes

20

Retrocediendo en el tiempo, los procesadores no pudieron funcionar tan rápido. Como resultado, si deseaba hacer más procesamiento, necesitaba más procesadores. Esto podría ser con un coprocesador matemático, o simplemente podría ser con más del mismo procesador. El mejor ejemplo de esto es el Inmos Transputer de los años 80, que fue diseñado específicamente para el procesamiento masivo en paralelo con múltiples procesadores conectados entre sí. Todo el concepto dependía del supuesto de que no había mejor manera de aumentar la potencia de procesamiento que agregar procesadores.

El problema es que esa suposición fue (temporalmente) incorrecta. También puede obtener más potencia de procesamiento haciendo que un procesador haga más cálculos. Intel y AMD encontraron formas de aumentar aún más la velocidad del reloj y, como usted dice, es mucho más fácil mantener todo en un procesador. El resultado fue que hasta mediados de la década de 2000, el rápido procesador de un solo núcleo era el propietario del mercado. Inmos murió de muerte a principios de los 90, y toda su experiencia murió con ellos.

Sin embargo, los buenos tiempos tuvieron que terminar. Una vez que las velocidades de reloj llegaron a GHz, realmente no había margen para ir más allá. Y de regreso fuimos a múltiples núcleos nuevamente. Si realmente no puedes ir más rápido, más núcleos es la respuesta. Sin embargo, como usted dice, no siempre es fácil usar esos núcleos de manera efectiva. Estamos mucho mejor en estos días, pero todavía estamos lejos de hacerlo tan fácil como lo hizo el Transputer.

Por supuesto, también hay otras opciones de mejora: en su lugar, podría ser más eficiente. SIMD y conjuntos de instrucciones similares obtienen más procesamiento para la misma cantidad de tics de reloj. DDR introduce y saca sus datos del procesador más rápido. Todo ayuda. Pero cuando se trata de procesamiento, volvemos a los 80 y a los núcleos múltiples nuevamente.


Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat . Cualquier conclusión alcanzada debe ser editada nuevamente en la pregunta y / o cualquier respuesta (s).
Dave Tweed

20

Buena pregunta, o al menos una con una respuesta interesante. Parte de esta respuesta muestra un mundo en el que las CPU podrían escalar eficientemente en ancho en lugar de con múltiples núcleos separados. ¡Los modelos de licencia / precio serían diferentes!

El resto explica por qué no pueden. Resumen:

  • El costo de múltiples núcleos escala de forma lineal
  • El costo de ampliar las escalas de la tubería superescalar de 1 núcleo ~ cuadráticamente Esto es factible con suficiente fuerza bruta, hasta cierto punto de todos modos. El rendimiento de un solo subproceso es muy importante para el uso interactivo (la latencia de extremo a extremo es importante, no solo el rendimiento), por lo que las CPU de gama alta de núcleo grande actuales pagan ese precio. por ejemplo, Skylake (4 de ancho), Ryzen (5 o 6 de ancho) y Apple A12 (7 de ancho para los núcleos grandes, 3 de ancho para los núcleos pequeños con eficiencia energética)
  • El IPC decreciente grave regresa de solo ampliar la tubería más allá de 3 o 4 de ancho, incluso con la ejecución fuera de orden para encontrar el ILP . Las fallas de ramificación y de caché son difíciles, y todavía bloquean toda la tubería.
  • No mencionó la frecuencia, solo IPC, pero la frecuencia de escala también es difícil. Una frecuencia más alta requiere un voltaje más alto, por lo que la potencia se escala con frecuencia en cubos : ^1desde la frecuencia directamente y ^2desde el voltaje. (La energía almacenada por el capacitor se escala con V ^ 2, y la mayor parte de la potencia dinámica más allá de la corriente de fuga proviene de la carga de bombeo hacia las cargas capacitivas de las puertas FET + cables).

    Rendimiento = frecuencia multiplicado por IPC. (Dentro de la misma arquitectura. El SIMD más amplio le permite realizar el mismo trabajo con menos instrucciones, y algunos ISA son más densos que otros, por ejemplo, MIPS a menudo toma más instrucciones para hacer el mismo trabajo que x86 o AArch64).

Los costos están en el área de la matriz (costo de fabricación) y / o energía (lo que indirectamente limita la frecuencia porque el enfriamiento es difícil). Además, una menor potencia y rendimiento por vatio es un objetivo en sí mismo, especialmente para dispositivos móviles (batería) y servidores (densidad de energía / costos de enfriamiento / costos de electricidad).

Antes de que fuera multinúcleo por zócalo, tenía sistemas de múltiples zócalos para casos de uso de alta gama en los que deseaba un mayor rendimiento del que se podía lograr con una sola CPU que pudiera fabricarse, por lo que esos eran los únicos sistemas SMP. (Servidores, estaciones de trabajo de alta gama).

Si un solo núcleo pudiera escalar tan eficientemente como lo desea, tendríamos sistemas con 1 núcleo físico por socket, y SMT (por ejemplo, HyperThreading) para permitirles actuar como múltiples núcleos lógicos. Las computadoras de escritorio / portátiles típicas solo tendrían 1 núcleo físico, y no tendríamos problemas para paralelizar cosas que no se escalen linealmente con más núcleos. por ejemplo, make -j4para aprovechar los servidores de múltiples sockets y / o para ocultar la latencia de E / S en un escritorio. (O tal vez aún intentaríamos paralelizar mucho si el ancho de la tubería se escalara fácilmente, pero IPC no lo hizo, por lo que tuvimos que usar más subprocesos SMT). Su núcleo del sistema operativo aún necesitaría ejecutarse en todos los núcleos lógicos, a menos que la CPU Presentar SMT al sistema operativo era muy diferente, por lo que los algoritmos de programación paralela y el bloqueo aún serían necesarios allí.


Donald Knuth dijo en una entrevista de 2008

También podría hablar un poco sobre mi infelicidad personal con la tendencia actual hacia la arquitectura multinúcleo. Para mí, parece más o menos que los diseñadores de hardware se han quedado sin ideas, y que están tratando de pasar la culpa de la futura desaparición de la Ley de Moore a los escritores de software al darnos máquinas que funcionan más rápido solo en unos pocos puntos de referencia clave!

Sí, si pudiéramos tener CPUs milagrosas de un solo núcleo con un rendimiento 8 veces mayor en programas reales , probablemente aún las estaríamos usando. Con sistemas de doble socket solo cuando valía la pena pagar mucho más por un mayor rendimiento (no un rendimiento de subproceso único).

Múltiples CPU reducen los costos de cambio de contexto cuando se ejecutan múltiples programas (al permitir que realmente se ejecuten en paralelo en lugar de cambiar rápidamente entre ellos); la multitarea preventiva que interrumpe la maquinaria masiva fuera de servicio que tal CPU requeriría probablemente dañaría aún más de lo que lo hace ahora.

Físicamente, sería un solo núcleo (para una jerarquía de caché simple sin interconexiones entre núcleos) pero admitiría SMT (por ejemplo, HyperThreading de Intel) para que el software pudiera usarlo como 8 núcleos lógicos que compiten dinámicamente por los recursos de rendimiento. O cuando solo 1 hilo se está ejecutando / no está parado, obtendría el beneficio completo.

Por lo tanto, usaría múltiples subprocesos cuando eso fuera realmente más fácil / natural (por ejemplo, procesos separados que se ejecutan a la vez) o para problemas fácilmente paralelizados con cadenas de dependencia que evitarían maximizar el IPC de esta bestia.

Pero desafortunadamente es una ilusión de parte de Knuth que las CPU multi-core dejarán de ser una cosa en este momento.


Escalado de rendimiento de un solo hilo

Creo que si hicieran un equivalente de 1 núcleo de una CPU de 8 núcleos, ese núcleo tendría un aumento del 800% en IPC, por lo que obtendría el rendimiento completo en todos los programas, no solo aquellos que están optimizados para múltiples núcleos.

Sí, eso es verdad. Si fuera posible construir una CPU de este tipo, sería muy sorprendente. Pero creo que es literalmente imposible en el mismo proceso de fabricación de semiconductores (es decir, la misma calidad / eficiencia de los transistores). Ciertamente, no es posible con el mismo presupuesto de energía y área de matriz que una CPU de 8 núcleos, a pesar de que ahorraría en lógica para unir los núcleos, y no necesitaría tanto espacio para las cachés privadas por núcleo.

Incluso si permite aumentos de frecuencia (dado que el criterio real es trabajar por segundo, no trabajar por reloj), hacer incluso una CPU 2 veces más rápida sería un gran desafío.

Si fuera posible en cualquier lugar cerca del mismo presupuesto de energía y área de troquel (por lo tanto, costo de fabricación) construir una CPU de este tipo, sí, los proveedores de CPU ya las estarían construyendo de esa manera.

Ver microprocesadores modernos ¡Una guía de 90 minutos!

¿Específicamente los núcleos más o núcleos más anchos? sección, para obtener los antecedentes necesarios para comprender esta respuesta; comienza simple con el funcionamiento de las CPU canalizadas en orden, luego superescalar (varias instrucciones por reloj). Luego explica cómo llegamos a la pared de potencia en la era P4, lo que lleva al final del escalado de frecuencia fácil, dejando principalmente solo IPC y haciendo más trabajo por instrucción (por ejemplo, SIMD) como el camino hacia adelante, incluso con transistores más pequeños.

Ampliar una tubería (instrucciones máximas por reloj) generalmente aumenta el costo como ancho al cuadrado . Ese costo se mide en el área y / o la potencia del troquel, para una verificación de dependencia paralela más amplia (detección de peligros) y un planificador fuera de servicio más amplio para encontrar instrucciones listas para ejecutar. Y más puertos de lectura / escritura en su archivo de registro y caché si desea ejecutar instrucciones distintas a nop. Especialmente si tiene instrucciones de 3 entradas como FMA o add-with-carry (2 registros + banderas).

También hay rendimientos decrecientes de IPC para ampliar las CPU ; la mayoría de las cargas de trabajo tienen un ILP (Paralelismo de nivel de instrucción) limitado a pequeña escala / corto alcance para que las CPU exploten, por lo que hacer que el núcleo sea más ancho no aumenta el IPC (instrucciones por reloj) si el IPC ya está limitado a menos del ancho del núcleo por cadenas de dependencia, errores de rama, errores de caché u otros bloqueos. Seguro que obtendrás una aceleración en algunos bucles desenrollados con iteraciones independientes, pero eso no es lo que la mayoría del código pasa la mayor parte del tiempo haciendo. Las instrucciones de comparación / ramificación constituyen el 20% de la mezcla de instrucciones en el código "típico", IIRC. (Creo que he leído números del 15 al 25% para varios conjuntos de datos).

Además, una falta de caché que detiene todas las instrucciones dependientes (y luego todo una vez que se alcanza la capacidad ROB) cuesta más para una CPU más amplia. (El costo de oportunidad de dejar inactivas más unidades de ejecución; no se realiza más trabajo potencial). O una omisión de rama de manera similar provoca una burbuja.

Para obtener 8 veces el IPC, necesitaríamos al menos una mejora de 8 veces en la precisión de predicción de rama y en las tasas de aciertos de caché . Pero las tasas de aciertos de caché no se escalan bien con la capacidad de caché más allá de cierto punto para la mayoría de las cargas de trabajo. Y la captación previa de HW es inteligente, pero no puede ser tan inteligente. Y a 8 veces el IPC, los predictores de rama necesitan producir 8 veces más predicciones por ciclo, además de hacer que sean más precisos.


Las técnicas actuales para construir CPU de ejecución fuera de orden solo pueden encontrar ILP en rangos cortos . Por ejemplo, el tamaño ROB de Skylake es 224 uops de dominio fusionado, el planificador para uops no ejecutados es 97 dominio no fusionado. Consulte Comprender el impacto de lfence en un bucle con dos cadenas de dependencia largas para conocer las longitudes de un caso en el que el tamaño del planificador es el factor limitante para extraer ILP de 2 cadenas largas de instrucciones, si son demasiado largas. Y / o vea esta respuesta más general e introductoria ).

Por lo tanto, encontrar ILP entre dos bucles largos separados no es algo que podamos hacer con el hardware. La recompilación binaria dinámica para la fusión en bucle podría ser posible en algunos casos, pero difícil y no es algo que las CPU realmente puedan hacer a menos que sigan la ruta Transmeta Crusoe. (capa de emulación x86 en la parte superior de un ISA interno diferente; en ese caso, VLIW). Pero los diseños x86 modernos estándar con cachés uop y decodificadores potentes no son fáciles de superar para la mayoría de los códigos.

Y fuera de x86, todos los ISA que todavía están en uso son relativamente fáciles de decodificar, por lo que no hay motivación para la recopilación dinámica que no sean optimizaciones de larga distancia. TL: DR: esperar que los compiladores mágicos puedan exponer más ILP al hardware no funcionó para Itanium IA-64 , y es poco probable que funcione para una CPU súper ancha para cualquier ISA existente con un modelo de ejecución en serie.


Si tuvieras una CPU súper ancha, definitivamente querrías que sea compatible con SMT para que puedas mantenerlo alimentado con trabajo para hacer ejecutando múltiples subprocesos de bajo ILP.

Dado que Skylake actualmente tiene 4 uops de ancho (y logra un IPC real de 2 a 3 uops por reloj, o incluso más cerca de 4 en el código de alto rendimiento), ¡una CPU hipotética 8x más ancha tendría 32 de ancho!

Sería fantástico poder volver a dividir eso en 8 o 16 CPU lógicas que compartan dinámicamente esos recursos de ejecución: los subprocesos no bloqueados obtienen todo el ancho de banda de front-end y el rendimiento de back-end.

Pero con 8 núcleos separados, cuando un hilo se detiene, no hay nada más para mantener alimentadas las unidades de ejecución; los otros hilos no se benefician.

La ejecución a menudo es explosiva: se detiene esperando una carga perdida de caché, luego, una vez que llega, muchas instrucciones en paralelo pueden usar ese resultado. Con una CPU súper ancha, esa explosión puede ir más rápido y, de hecho, puede ayudar con SMT.


Pero no podemos tener CPU mágicas súper anchas

Por lo tanto, para obtener un rendimiento, debemos exponer el paralelismo al hardware en forma de paralelismo a nivel de hilo . En general, los compiladores no son buenos para saber cuándo / cómo usar hilos, excepto para casos simples como bucles muy grandes. (OpenMP o gcc's -ftree-parallelize-loops). Todavía se necesita inteligencia humana para reelaborar el código para realizar eficientemente un trabajo útil en paralelo, porque la comunicación entre subprocesos es costosa, y también lo es el inicio del subproceso.

TLP es un paralelismo de grano grueso, a diferencia del ILP de grano fino dentro de un solo hilo de ejecución que HW puede explotar.


Las CPU dirigidas a cargas de trabajo interactivas (como Intel / AMD x86 y los núcleos de gama alta Apple / ARM AArch64) definitivamente influyen en los rendimientos decrecientes del escalado de IPC, porque el rendimiento de un solo subproceso sigue siendo tan valioso cuando la latencia importa, no solo el rendimiento para problemas masivamente paralelos.

Poder ejecutar 8 copias de un juego en paralelo a 15 fps cada una es mucho menos valioso que poder ejecutar una copia a 45 fps. Los proveedores de CPU saben esto, y es por eso que las CPU modernas utilizan la ejecución fuera de orden a pesar de que cuesta una gran cantidad de energía y área muerta. (Pero las GPU no lo hacen porque su carga de trabajo ya es masivamente paralela).

El hardware Xeon Phi de muchos núcleos de Intel (Knight's Landing / Knight's Mill) es un punto intermedio interesante: ejecución fuera de orden muy limitada y SMT para mantener núcleos de 2 anchos alimentados con instrucciones SIMD AVX512 para descifrar números. Los núcleos se basan en la arquitectura Silvermont de bajo consumo de Intel. (Ejecutivo fuera de servicio pero con una pequeña ventana de reordenamiento, mucho más pequeña que la familia Sandybridge de núcleo grande. Y una tubería más estrecha).


Por cierto, todo esto es ortogonal a SIMD. Hacer más trabajo por instrucción siempre ayuda, si es posible para su problema.


Modelos de precios

Los modelos de precios de software se basan en el panorama actual del hardware.

Los modelos de licencia por núcleo se generalizaron (y fueron relevantes incluso para equipos de escritorio de un solo socket) con la llegada de las CPU de múltiples núcleos. Antes de eso, solo era relevante para servidores y grandes estaciones de trabajo.

Si el software no necesitara múltiples núcleos para funcionar a la máxima velocidad, realmente no habría una forma de venderlo más barato a las personas que no obtienen tantos beneficios porque lo ejecutan en una CPU más débil. A menos que tal vez el ecosistema de software / hardware haya desarrollado controles en los "canales SMT" que le permiten configurar un ancho de ejecución máximo para el código que se ejecuta en ese núcleo lógico. (Nuevamente imaginando un mundo donde las CPU escalan en el ancho de la tubería en lugar de múltiples núcleos separados).


2
"el inicio de subprocesos es costoso", eso no es un hecho difícil; Es un artefacto de los sistemas operativos modernos comunes.
MSalters

1
@MSalters Y, de hecho, algunos proyectos de investigación han explorado lo maravilloso que sería abandonar este enfoque. Lo mismo con la "inteligencia humana para modificar el código": hay formas de escribir código que son naturalmente más fáciles de paralelizar, simplemente no han sido muy populares en las últimas décadas. En los que se utilizan, por lo general puede ver la escala horizontal masiva a muy bajo costo; de hecho, hasta el punto de que el escalado horizontal está comenzando a ser mucho más barato que el vertical en muchas aplicaciones. Simplemente significa que no debe dar a los desarrolladores la opción; si las circunstancias lo obligan, funciona bien: D
Luaan

11

Déjame dibujar una analogía:

Si tienes un mono escribiendo en una máquina de escribir y quieres que se escriba más, puedes darle café al mono, lecciones de escritura y tal vez hacer amenazas para que funcione más rápido, pero llega un momento en que el mono lo hará estar escribiendo a la máxima capacidad.

Entonces, si quieres hacer más mecanografía, debes obtener más monos.


Para ampliar aún más la analogía, necesita una máquina de escribir separada para cada mono (que representa el bus de datos que necesitará cada núcleo), necesita una forma de llevar plátanos a cada mono y algo para recoger sus excrementos (análogo a la distribución de energía y el calor disipación) y necesita una forma de asegurarse de que los monos no estén todos tratando de escribir el mismo pasaje en la Noche de Reyes (análogo a dividir correctamente la carga de trabajo entre los procesadores). Pero todo esto es menos trabajo para obtener más ganancias que tratar de obtener más mecanografía de un mono.


7

Usted señala que mucho software no usa más de (x) núcleos. Pero esto es completamente una limitación impuesta por los diseñadores de ese software. Las PC domésticas que tienen múltiples núcleos aún son nuevas (ish) y el diseño de software multiproceso también es más difícil con las API e idiomas tradicionales.

Su PC tampoco solo ejecuta ese 1 programa. Está haciendo un montón de otras cosas que se pueden poner en núcleos menos activos para que su software principal no se vea interrumpido por ellos tanto.

Actualmente no es posible aumentar la velocidad de un solo núcleo para que coincida con el rendimiento de 8 núcleos. Es probable que tenga que venir más velocidad de la nueva arquitectura.

A medida que más núcleos están disponibles y las API se diseñan con esa suposición, los programadores comenzarán comúnmente a usar más núcleos. Continúan los esfuerzos para hacer que los diseños de subprocesos múltiples sean más fáciles de realizar. Si hiciste esta pregunta en unos años, probablemente estarías diciendo "Mis juegos solo usan 32 núcleos, entonces ¿por qué mi CPU tiene 256?".


3
La diferencia entre 1 y múltiples núcleos es enorme en términos de lograr que el software aproveche. La mayoría de los algoritmos y programas son seriales. por ejemplo, Donald Knuth ha dicho que las CPU multinúcleo parecen diseñadores de hardware "están tratando de pasar la culpa de la futura desaparición de la Ley de Moore a los escritores de software al darnos máquinas que funcionan más rápido solo en unos pocos puntos de referencia clave "
Peter Cordes

Desafortunadamente, nadie ha encontrado una manera de hacer que un solo núcleo ancho / rápido ejecute un programa de un solo subproceso en cualquier lugar tan rápido como podamos obtener un código paralelo eficiente para ejecutarse en múltiples núcleos. Pero, afortunadamente, los diseñadores de CPU se dan cuenta de que el rendimiento de un solo subproceso sigue siendo crítico y hacen que cada núcleo individual sea mucho más grande y más potente de lo que sería si buscaran un rendimiento puro en problemas paralelos. (Compare un Skylake (4-wide) o Ryzen (5-wide) vs. un núcleo de un Xeon Phi (Knight's Landing / Knight's Mill basado en Silvermont + AVX512) (2-wide y limitado OoO exec)
Peter Cordes

2
De todos modos, sí, tener al menos 2 núcleos a menudo es útil para un sistema operativo multitarea, pero la multitarea preventiva en un solo núcleo que era 4x u 8x tan rápido como una CPU actual sería bastante buena. Para muchos casos de uso interactivos, sería mucho mejor, si fuera posible construir en absoluto / con el mismo presupuesto de energía. (Sin embargo, el doble núcleo ayuda a reducir los costos de cambio de contexto cuando varias tareas quieren tiempo de CPU).
Peter Cordes

1
Todo cierto, pero históricamente multi-core fue más caro. No había muchas razones para diseñar algoritmos paralelos fuera de las aplicaciones científicas. Hay mucho espacio para la paralelización, incluso en algoritmos que requieren una ejecución mayormente en serie. Pero la generación actual de IPC no es excelente y es fácil de estropear. Lo que generalmente produce errores que son realmente difíciles de encontrar y corregir. Por supuesto, una CPU 4 veces más rápida sería increíble (pero aún querría múltiples núcleos).
Hekete

2
@PeterCordes Bueno, la mayoría de los algoritmos y programas no son seriales porque tienen que serlo, sino principalmente porque es la forma en que siempre se ha hecho (con la aspersión de "fue una buena compensación"). Los casos más atroces son donde puede ejecutar el mismo programa cuatro veces en cuatro cargas de trabajo separadas y hacer que se ejecuten en paralelo sin problemas. Pero eso enfrenta otro problema: la CPU no es un cuello de botella con tanta frecuencia, y generalmente la forma de evitarlo es usar mejores algoritmos, no más CPU. A veces, eso también ayuda con otros cuellos de botella (memoria, disco, red ...).
Luaan

3

La razón más convincente desde un punto de vista histórico es la disipación de poder .

Después del Pentium IV, Intel trató de buscar un procesador de próxima generación llamado Tejas que se suponía que debía ejecutarse en el rango de 4 GHz a 12 GHz. El problema era que correr a esa velocidad generaba demasiado calor para ser viable.

Después de que Tejas fue cancelado, Intel tardó entre 10 y 15 años antes de que finalmente tuvieran núcleos funcionando a 4 GHz con niveles aceptables de calor.

Ver Tejas y Jayhawk .

Intel tenía otro proyecto en paralelo con Tejas que involucraba el uso de múltiples núcleos. Ese proyecto tenía niveles aceptables de calor, así que así fueron. Les permitió aumentar el rendimiento ahora en lugar de esperar otros 10 años para procesos de fabricación de 10 nm.

Suponiendo que los núcleos no carecen de recursos, entonces para obtener la misma cantidad de instrucciones por segundo de un solo núcleo en lugar de N núcleos, necesitaría que la tasa de instrucción de ese único núcleo sea N veces más rápida. La disipación dinámica de potencia de un núcleo de CPU es linealmente proporcional a la frecuencia de funcionamiento. También es proporcional al cuadrado del voltaje de operación. El funcionamiento a frecuencias más bajas permite el uso de voltajes operativos más bajos. El uso de voltajes más bajos a frecuencias más bajas significa que prácticamente el calor generado disminuye con el cubo de la frecuencia de operación.

Un ejemplo extremo de esto es el cerebro humano, que puede realizar el equivalente a 2 ^ 18 operaciones por segundo usando solo 20 W de potencia. Lo logra mediante el uso de miles de millones de neuronas que se ejecutan en paralelo a unos pocos cientos de Hz.

También tenga en cuenta que generalmente hay cientos o miles de hilos ejecutándose a la vez en una PC. El sistema operativo maneja la asignación de tiempo en un núcleo a cada subproceso. Entonces, incluso si un programa individual no aprovecha todos los núcleos, aún se beneficia porque los otros programas están tomando menos tiempo de su CPU si se ejecutan en otro núcleo.

En todo caso, el mercado de alto rendimiento se está moviendo hacia un procesamiento más paralelo en forma de FPGA. Intel compró recientemente Altera (el segundo mayor fabricante de FPGA) y ahora está vendiendo placas con un acelerador de hardware FPGA. El software puede cargar el FPGA con una imagen en tiempo de ejecución mediante una llamada API. La CPU luego introduce datos en el FPGA y le permite hacer la mayor parte del trabajo. Los tipos de aplicaciones suelen ser codificación de video, IA, renderizado, búsqueda en bases de datos, etc.


También tenga en cuenta que generalmente hay cientos o miles de hilos ejecutándose a la vez en una PC. No, no corriendo . Existen muchos hilos en los escritorios modernos, pero casi todos están dormidos esperando E / S o un temporizador en un momento dado. por ejemplo, el promedio de carga (en el último minuto) en mi escritorio Linux es actualmente de 0.19 tareas listas para usar el tiempo de CPU en cualquier momento. Si estuviera ejecutando una codificación de video, x264 habría iniciado varios subprocesos para que el sistema operativo los programe en múltiples núcleos, pero solo tantos como tengo núcleos lógicos.
Peter Cordes

Y, por cierto, el OP (por alguna razón) omitió la frecuencia por completo, y preguntó sobre escalar IPC (instrucciones por ciclo de reloj), no por segundo. Lo que usted dice es cierto, pero estaban proponiendo hacer que las CPU sean más anchas , no más altas. Ya abordé eso en mi respuesta, por lo que su respuesta que explica la escala de potencia con frecuencia es una buena adición, +1.
Peter Cordes

@PeterCordes Eso es correcto, no quise decir que todos los hilos se ejecuten a la vez, por supuesto, se turnan. Gracias por aclararlo.
user4574

Bueno, no tanto por "turnos" como porque no están listos para correr, la mayoría de las veces. En su mayoría, están todos dormidos, por lo general solo se despiertan por una breve ráfaga de cómputo, por ejemplo, después de que el sistema operativo presiona una tecla incluso o una lectura de red, o los despierta porque expiró un temporizador. Es raro que más de 2 estén despiertos a la vez, a menos que realmente esté haciendo algo computacionalmente intensivo. Y si es así, no comienzas cientos de hilos, comienzas un número de hilos ~ = número de núcleos disponibles.
Peter Cordes

2

Solo para redondear la imagen de a dónde va todo esto ...

Las redes neuronales y la IA son los temas más candentes del momento. Una razón es que uno puede usar de manera eficiente un gran número de núcleos simples en paralelo y, por lo tanto, extraer un rendimiento de cómputo cercano al máximo. El requisito es intrínsecamente masivamente paralelo y se asigna con bastante facilidad en una matriz de procesadores sin mucha comunicación necesaria entre núcleos. Es por eso que las GPU fueron la primera tecnología de goto para la aceleración de la IA. En este momento estamos viendo chips optimizados incluso mejor que las GPU de video para las NN que salen al mercado. El siguiente paso, o quizás el último, es hacer NNs utilizando tecnologías analógicas como memristors.

Y, aparte, en algo como una PC para juegos hay mucho más rendimiento bruto en la tarjeta gráfica que la CPU Intel o AMD multinúcleo


2
Re "... inherentemente masivamente paralelo" : ¿Incluso vergonzosamente paralelo ?
Peter Mortensen

1

Básicamente, las pérdidas de CMOS son exponencialmente (^ 1.5) proporcionales a la frecuencia y el rendimiento paralelo de la CPU es algo menor que el lineal proporcional al número de CPU.

Por lo tanto, la relación entre potencia de computación y disipación de potencia se mejora para aplicaciones de múltiples CPU a diferentes velocidades de reloj al comparar la velocidad frente a la cantidad de CPU para una disipación de potencia fija.

Es más complejo que esto, pero estos son los fundamentos por los que las CPU paralelas son mejores por vatio en aplicaciones dinámicas. Siempre habrá excepciones cuando se optimice para un escenario.

No es el tamaño de una CPU más grande lo que lo hace más rápido para las aplicaciones de PC típicas de Intel / AMD, sino que es el tamaño reducido de la resolución litográfica y la capacitancia de la puerta más baja lo que reduce la potencia junto con el nivel de sub-umbral y el voltaje del núcleo reducidos.

La mejora no es lineal y no significa que 8 núcleos es 4 veces mejor que 2, pero el objetivo si se cumple es tener un mayor rango dinámico de procesamiento con la aceleración de la disipación de potencia, velocidad y voltaje para mejorar tanto el rendimiento como la eficiencia y la potencia máxima bajo demanda sin aumento excesivo de temperatura.

Para una respuesta más científica, lea https://www.sciencedirect.com/topics/computer-science/dynamic-power-consumption


-2

Los multinúcleos no suelen ser multiescalares. Y los núcleos multiescalares no son multinúcleos.

Sería perfecto encontrar una arquitectura multiescalar que se ejecute a varios megahercios, pero en general sus puentes no serían habilitados por el consumidor, pero serían costosos, por lo que la tendencia es la programación multinúcleo a una frecuencia más baja en lugar de instrucciones cortas a altas velocidades de reloj.

Múltiples núcleos de instrucción son más baratos y fáciles de manejar, y es por eso que es una mala idea tener arquitecturas multiescalar a varios gigahercios.


1
¿Te refieres a "superescalar", múltiples instrucciones por reloj? La mayoría de las CPU multinúcleo son superescalares. Por ejemplo, Ryzen tiene 5 de ancho. Los chips AArch64 de gama alta de Apple tienen 6 u 8 de ancho. Hay una gran cantidad de fruta baja para que una CPU de 2 anchos explote en la mayoría del código, por lo que vale la pena hacer que cada núcleo tenga al menos 2 anchos antes de escalar a múltiples núcleos que necesitan su propia caché privada y una interconexión entre núcleos ( por ejemplo, las tarjetas de cómputo de muchos núcleos Xeon Phi de Intel tienen muchos núcleos de doble problema Lo mismo para los núcleos de teléfonos inteligentes: los núcleos pequeños tienen al menos 2 de ancho. ¡El rendimiento de un solo subproceso es importante!
Peter Cordes

1
¿O quiso decir dl.acm.org/citation.cfm?id=224451 , un trabajo de investigación sobre lo que llaman núcleos "multiescalar" que buscan ILP en rangos más grandes en el gráfico de flujo de control de un programa de alto nivel, utilizando Una combinación de HW y SW. Las CPU convencionales que utilizamos en computadoras de escritorio y teléfonos inteligentes no son así, son simplemente superescalares ordinarios con ejecución fuera de orden, implementando un ISA en serie que pretende ejecutar las instrucciones de una en una.
Peter Cordes

Gracias. Afaik, la idea detrás del arco escalar es la capacidad de medir el calor detrás de conjuntos de instrucciones conocidas o predefinidas (el caso de AVX). <br/> El cálculo actual de las arquitecturas frente al calor se considera no predecible de manera computable. Esto mejora la improbabilidad de que los multinúcleos puedan ejecutarse a grandes frecuencias, ya que su capacidad para funcionar en un tiempo / calor ideal no es computable. eso es todo lo que sé hasta ahora. Estoy cavando máquinas de vectores con el propósito de comprender la física de los "multiescalares". el caso es xeon / phy, siga una curva térmica ideal como lo hizo el antiguo cpus. mejorando la experiencia del cliente
machtur

Los conjuntos de instrucciones SIMD como AVX son una forma de obtener más trabajo a través de la tubería sin tener que hacer que la tubería sea más ancha, solo las unidades de ejecución. Por ejemplo, Skylake puede ejecutar 3 vpaddd ymm0, ymm1, ymm2instrucciones por reloj, cada una con 8 adiciones enteras de 32 bits. Por lo tanto, se agregan 24 enteros por reloj, pero la maquinaria de ejecución fuera de orden "solo" debe realizar un seguimiento de 3 instrucciones en vuelo. Es mucho más barato construir que una CPU que pueda ejecutar 24 add eax, edxinstrucciones por reloj. SIMD es básicamente ortogonal al ancho de la tubería.
Peter Cordes

Skylake es un buen caso de optimización por ciclo de reloj. las variantes son numerosas, no estoy en ellas, que son casos interesantes de optimización de bus interno ya que los skylakes integran la descarga original de Xeon en la tubería SIMD de esa manera. Supongo que un gran núcleo integraría la descarga y la computación en pocos ciclos, como lo hace (por ejemplo) el fenómeno para AVX. es la forma en que la computación se ha integrado hacia adelante frente a la potencia requerida para las operaciones de bloque interno. como opuesto a múltiples instrucciones cortas como en Gpu-like con múltiples núcleos "virtuales" similares a las adiciones al Nehalem
machtur
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.