¿Cómo puede un FPGA superar a una CPU?

Escuché de personas que usan FPGA para mejorar el rendimiento de los sistemas que hacen cosas como la minería de bit-coin, el comercio electrónico y el plegamiento de proteínas.

¿Cómo puede un FPGA competir con una CPU en cuanto al rendimiento cuando la CPU normalmente se ejecuta al menos un orden de magnitud más rápido (en términos de velocidad de reloj)?

Las CPU son dispositivos de procesamiento secuencial. Rompen un algoritmo en una secuencia de operaciones y las ejecutan una a la vez.

Los FPGA son (o pueden configurarse como) dispositivos de procesamiento en paralelo. Se podría ejecutar un algoritmo completo en una sola pulsación del reloj o, en el peor de los casos, muchas menos pulsaciones de reloj de las que requiere un procesador secuencial. Uno de los costos para el aumento de la complejidad lógica es típicamente un límite inferior en el que se puede sincronizar el dispositivo.

Teniendo en cuenta lo anterior, los FPGA pueden superar a las CPU que realizan ciertas tareas porque pueden hacer la misma tarea en menos tics de reloj, aunque a una velocidad de reloj general más baja. Las ganancias que se pueden lograr dependen en gran medida del algoritmo, pero al menos un orden de magnitud no es atípico para algo como una FFT.

Además, debido a que puede construir múltiples unidades de ejecución paralelas en un FPGA, si tiene un gran volumen de datos que desea pasar a través del mismo algoritmo, puede distribuir los datos entre las unidades de ejecución paralelas y obtener más órdenes de magnitud de mayor rendimiento. que se puede lograr incluso con una CPU multi-core.

El precio que paga por las ventajas es el consumo de energía y los $$$.

Markt tiene esto en su mayoría correcto, pero voy a tirar mis 2 centavos aquí:

Imagine que le dije que quería escribir un programa que invirtiera el orden de los bits dentro de un entero de 32 bits. Algo como esto:

int reverseBits(int input) {
    output = 0;
    for(int i = 0;i < 32;i++) {
        // Check if the lowest bit is set
        if(input & 1 != 0) {
            output = output | 1; // set the lowest bit to match in the output!
        }

        input = input >> 1;
        output = output << 1;
    }
    return output;
}

Ahora mi implementación no es elegante, pero estoy seguro de que está de acuerdo en que habría algunas operaciones involucradas en hacer esto, y probablemente algún tipo de bucle. Esto significa que en la CPU, ha gastado más de 1 ciclo para implementar esta operación.

En un FPGA, simplemente puede conectar esto como un par de pestillos. Obtiene sus datos en algún registro, luego los conecta a los diferentes registros en orden de bits inverso. Esto significa que la operación se completará en un solo ciclo de reloj en el FPGA. Por lo tanto, en un solo ciclo, el FPGS ha completado una operación que le tomó a su CPU de propósito general muchos miles de ciclos para completar. Además, puede conectar probablemente unos pocos cientos de estos registros en paralelo. Entonces, si puede moverse en unos pocos cientos de números al FPGA, en un solo ciclo finalizará esas miles de operaciones cientos de veces, todo en un ciclo de reloj FPGA.

Hay muchas cosas que puede hacer una CPU de propósito general, pero como limitación, configuramos instrucciones generales y simples que necesariamente tienen que expandirse en listas de instrucciones simples para completar algunas tareas. Por lo tanto, podría hacer que la CPU de propósito general tenga una instrucción como "orden de bits inverso para el registro de 32 bits" y darle a la CPU la misma capacidad que la FPGA que acabamos de construir, pero hay un número infinito de instrucciones útiles posibles, por lo que solo coloque los que garanticen el costo en las CPU populares.

Los FPGA, los CPLD y los ASIC le dan acceso al hardware en bruto, lo que le permite definir operaciones locas como "descifrar bytes cifrados AES256 con clave" o "decodificar el marco del video h.264". Estos tienen latencias de más de un ciclo de reloj en un FPGA, pero pueden implementarse de maneras mucho más eficientes que escribir la operación en millones de líneas de código de ensamblaje de propósito general. ¡Esto también tiene el beneficio de hacer que el FPGA / ASIC de propósito fijo para muchas de estas operaciones sea más eficiente en el consumo de energía porque no tienen que hacer tanto trabajo extraño!

El paralelismo es la otra parte que Markt señaló, y aunque eso también es importante, lo principal es cuando un FPGA paraleliza algo que ya era costoso en la CPU en términos de ciclos necesarios para realizar la operación. Una vez que comience a decir "Puedo realizar en 10 ciclos FPGA una tarea que requiere 100.000 ciclos de mi CPU, y puedo hacer esta tarea en paralelo 4 elementos a la vez", puede ver fácilmente por qué un FPGA podría ser muchísimo más rápido que una CPU!

Entonces, ¿por qué no usamos FPGA, CPLD y ASIC para todo? Porque en general es un chip completo que no hace más que una operación. Esto significa que aunque puede obtener un proceso para ejecutar muchos órdenes de magnitud más rápido en su FPGA / ASIC, no puede cambiarlo más tarde cuando esa operación ya no sea útil. La razón por la que no puede (generalmente) cambiar un FPGA una vez que está en un circuito es que el cableado de la interfaz es fijo, y normalmente el circuito no incluye componentes que le permitan reprogramar el FPGA en una configuración más útil. Hay algunos investigadores que intentan construir módulos híbridos FPGA-CPU, donde hay una sección de la CPU que puede volver a cablearse / reprogramarse como un FPGA, lo que le permite "cargar" una sección efectiva de la CPU,

Todas las otras respuestas populares presentadas aquí hablan de diferencias literales entre FPGA y CPU. Señalan la naturaleza paralela de la FPGA frente a la naturaleza secuencial de una CPU, o dan ejemplos de por qué ciertos algoritmos podrían funcionar bien en una FPGA. Todos estos son buenos y verdaderos, pero sugeriría sin embargo que hay una diferencia más fundamental entre CPU y FPGA.

¿Cuál es el denominador común entre un FPGA y una CPU? Es que ambos están construidos sobre silicio. Y en algunos casos, literalmente, los mismos procesos de silicio.

La diferencia fundamental son las abstracciones que acumulamos sobre ese silicio. No es posible que un humano comprenda todos los detalles de un diseño de CPU moderno único, desde silicio hasta IC empaquetado. Entonces, como parte del proceso de ingeniería, dividimos ese problema complejo en problemas manejables más pequeños que los humanos pueden resolver.

Considere lo que se necesita para convertir ese silicio en una CPU que funcione. Aquí hay una vista algo simplificada de las capas de abstracción necesarias para ese objetivo:

1. Primero tenemos ingenieros que saben cómo crear transistores a partir de silicio. Saben cómo diseñar transistores pequeños que consumen energía y cambian a una velocidad de 10 o incluso 100 gigahercios, y saben cómo diseñar transistores robustos que pueden conducir señales con suficiente potencia para enviarlos desde un paquete IC y a través de una PCB a otro chip.

2. Luego tenemos diseñadores de lógica digital que saben cómo juntar esos transistores en bibliotecas con cientos de celdas lógicas diferentes. Puertas lógicas, chanclas, muxes y sumadores, por nombrar algunos. Todo en una variedad de configuraciones.

3. A continuación, tenemos varios grupos de ingenieros que saben cómo juntar esos bloques digitales (y a veces analógicos) para formar bloques funcionales de nivel superior, como transceptores de alta velocidad, controladores de memoria, predictores de rama, ALU, etc.

4. Luego tenemos diseñadores de CPU para diseñar diseños de CPU de gama alta al reunir esas unidades funcionales en un sistema completo.

Y no se detiene ahí. En este punto, tenemos una CPU en funcionamiento que ejecuta código de ensamblaje, pero ese no es un lenguaje al que la mayoría de los programadores escriben en estos días.

5. Podríamos tener un compilador de C que compila el código de ensamblaje (probablemente a través de alguna representación intermedia)
6. Podríamos agregar otra abstracción sobre C para obtener un lenguaje orientado a objetos
7. Incluso podríamos escribir una máquina virtual encima de C o C ++ para poder interpretar cosas como el código de bytes de Java

Y las capas de abstracción pueden continuar desde allí. El punto importante aquí es que esas capas de abstracción se combinan para producir un sistema basado en CPU que se escala masivamente y cuesta una pequeña fracción de un diseño de silicio personalizado.

SIN EMBARGO, el punto importante a destacar aquí es que cada abstracción también conlleva un costo en sí mismo. El diseñador de transistores no construye el transistor perfecto para cada caso de uso. Construye una biblioteca razonable, por lo que a veces se usa un transistor que consume un poco más de energía o un poco más de silicio del que realmente se necesita para el trabajo en cuestión. Y de manera similar, los diseñadores lógicos no construyen todas las celdas lógicas posibles. Pueden construir una compuerta NAND de 4 entradas y una compuerta NAND de 8 entradas, pero ¿qué sucede cuando otro ingeniero necesita una compuerta NAND de 6 entradas? Utiliza una compuerta NAND de 8 entradas y conecta 2 entradas no utilizadas, lo que da como resultado la pérdida de recursos de silicio y la potencia de la energía. Y así sube la cadena de abstracciones. Cada capa nos brinda una forma de manejar la complejidad,

Ahora compare esas abstracciones con lo que se necesita para un FPGA. Esencialmente, las abstracciones FPGA se detienen en el n. ° 2 en la lista anterior. El FPGA permite a los desarrolladores trabajar en la capa de lógica digital. Es algo más sofisticado que eso porque las CPU están 'codificadas' en esta capa y los FPGA deben configurarse en tiempo de ejecución (lo que, por cierto, es por eso que las CPU suelen ejecutar frecuencias mucho más altas), pero la verdad esencial es que están lejos pocas abstracciones para FPGAs que para CPUs.

Entonces, ¿por qué un FPGA puede ser más rápido que una CPU? En esencia, es porque el FPGA usa muchas menos abstracciones que una CPU, lo que significa que el diseñador trabaja más cerca del silicio. No paga los costos de todas las capas de abstracción que se requieren para las CPU. Codifica en un nivel inferior y tiene que trabajar más para lograr una funcionalidad determinada, pero la recompensa que obtiene es un mayor rendimiento.

Pero, por supuesto, también hay un lado negativo para menos abstracciones. Todas esas abstracciones de CPU están ahí por una buena razón. Nos dan un paradigma de codificación mucho más simple, lo que significa que más personas pueden desarrollar fácilmente para ellos. Eso a su vez significa que existen muchos más diseños de CPU y, por lo tanto, tenemos beneficios masivos de precio / escala / tiempo de comercialización de las CPU.

Entonces ahí lo tienes. Los FPGA tienen menos abstracciones, por lo que pueden ser más rápidos y más eficientes, pero difíciles de programar. Las CPU tienen muchas abstracciones diseñadas para facilitar su desarrollo, escalabilidad y bajo costo. Pero abandonan la velocidad y el poder en el comercio por esos beneficios.

Si bien las otras respuestas son correctas, ninguna de ellas aborda el ejemplo de minería de bitcoin de su pregunta, que de hecho es un ejemplo decente. La minería de Bitcoin implica calcular repetidamente una función hash criptográfica, SHA-256 del resultado de otro cálculo SHA-256, de datos donde solo cambia un entero de 32 bits, hasta que el hash resultante tenga ciertas propiedades. Cada SHA-256 consta de 64 repeticiones del mismo algoritmo que implica adiciones de 32 bits, cambios de bits y algunas operaciones más de manipulación de bits.

Si programa este bucle en una CPU de 32 bits (o más), encontrará su conjunto de instrucciones muy adecuado para la tarea --- SHA-256 fue diseñado para ejecutarse eficientemente en las CPU. Aún así, solo usará aproximadamente el 2% del área de silicio de una CPU moderna, con una funcionalidad de área intensiva como almacenamiento en caché, multiplicación, división, operación de punto flotante, predicción de ramificación y ramificación, etc., o no se usa en absoluto o no puede proporcionar una cantidad significativa aumento de rendimiento para esta tarea en particular.

En hardware configurable como un FPGA, simplemente implementa ese 2% y optimiza aún más al olvidar todo acerca de la ejecución de código, en lugar de diseñar compuertas para calcular directamente cada una de esas subfunciones que se repiten a menudo. Canalizado de manera tal que cada uno de ellos pasa un resultado al siguiente cada ciclo de reloj, y repetido 128 veces (y con una lógica adicional especial donde cada SHA-256 comienza y termina), termina obteniendo un resultado en cada ciclo de reloj (por quizás 100 millones de hashes por segundo en un FPGA anunciado para admitir 300 MHz en una lógica más simple que esta) mientras que en una CPU moderna, puede esperar un resultado cada pocos miles de ciclos de reloj por núcleo, digamos 10 millones de hash por segundo en un multi-core multi -GHz CPU.

Si este ejemplo en particular es de su interés, es posible que desee ver mi respuesta relacionada sobre las partes internas de los mineros ASIC en bitcoin.stackexchange, ya que muchos mineros FPGA trabajan de la misma manera usando hardware configurable en lugar de hardware personalizado. Solo por completar: existen otras posibilidades, como limitar o evitar la canalización que describí a favor de una paralelización más trivial mediante el uso de múltiples hash SHA-256 independientes. Dependiendo de las restricciones dadas por las partes internas de su FPGA y su tamaño total, eso puede incluso brindar un mejor rendimiento, aunque sería menos eficiente en términos de conteo de puertas y sobrecarga de enrutamiento si tuviera la libertad perfecta para diseñar todo el chip, no solo la configuración de un FPGA .

Las respuestas anteriores, aunque correctas, pierden el punto sobre por qué los FPGA (y los ASIC personalizados) son especialmente buenos para los cálculos de bitcoin.

La ventaja real es que una gran proporción de los cálculos SHA-256 son operaciones lógicas (por ejemplo, cambios de bits) que se pueden realizar en el cableado. Cuando se hace de esta manera, requieren 0 ciclos de reloj.

Otra ventaja importante es que los FPGA son mucho más eficientes (es decir, MIPS por vatio) que las CPU, por lo que la cantidad de energía requerida para los cálculos es mucho menor. Esto es importante porque el costo de extraer un bitcoin depende de la cantidad de electricidad que use para fabricarlo.

Los chips ASIC son más eficientes energéticamente que los FPGA, por lo que pueden ejecutar el mismo código de manera mucho más económica. También puedes meter más unidades de ejecución a bordo para que sean más rápidas. La desventaja es que el costo de hacer un ASIC personalizado es muy alto, por lo que necesitaría vender bastantes chips para cubrir el costo de fabricación.

Las GPU también se utilizan para fabricar bitcoins, pero dado que son mucho menos eficientes energéticamente, han perdido terreno frente a FPGA y ASIC personalizados.