Análisis estadístico de series de tiempo con FPGA

En teoría, podrías hacerlo en un tiempo constante, pero solo hasta que te quedes sin recursos. Consideremos, por ahora, que el hardware se multiplica, ya que es probable que limiten el diseño. Por ejemplo, el Xilinx Spartan-6 más grande (la línea de valor) contiene 180 multiplicadores; El Virtex-6 más grande contiene 2128 multiplicadores (y probablemente costará decenas de miles). Estos son multiplicadores de 18 bits, pero en aras de la discusión los tratan como abstracciones. El número de multiplicadores luego te da el número de multiplicaciones que puedes hacer al mismo tiempo. Si entiendo bien el problema, la raíz cuadrada de ese número le brinda el conjunto de datos que se puede ejecutar en un ciclo de reloj.

En la práctica hay sumas / restas de las que preocuparse, la precisión requerida reducirá la cantidad de multiplicaciones que puede hacer, y las conexiones que necesitará hacer a través del tejido de FPGA serán muy densas. Todos estos factores reducen la velocidad máxima a la que puede sincronizar el FPGA. Además, debe ingresar los datos dentro y fuera del FPGA. Por lo tanto, mi intuición es que esta no es una 'aplicación asesina' para los FPGA. Los procesadores convencionales y las GPU son probablemente una mejor opción. (Consulte R + GPU .)

Sí, esto se puede hacer en un tiempo constante en un FPGA, pero solo por un valor de \ $ n \ $ limitado por el número de puertas en su FPGA. Usted malinterpreta o tergiversa la definición de \ $ O (n ^ 2) \ $ - Cualquier cosa que se pueda hacer en paralelo puede hacerse \ $ O (1) \ $ por un valor pequeño y finito de \ $ n \ $ por implementación en una CPU de múltiples núcleos, tarjeta gráfica, FPGA o una matriz de supercomputadora en red.

Veamos el ejemplo de cálculo de covarianzas de stocks. En este momento hay aproximadamente 3500 acciones en la NYSE, así que construyamos el sistema para admitir 4096 artículos.

En una CPU de un solo núcleo, eso requeriría \ $ \ left (2 ^ {12} \ right) ^ 2 = 2 ^ {24} \ approx 16,000,000 \ mbox {} \ $ calculations (que es no mucho tiempo, considere que una CPU de 4GHz puede hacer eso 250 veces por segundo), porque el algoritmo es \ $ O (n ^ 2) \ $, como se indicó anteriormente.

Si tuvieras una CPU de 4096 núcleos, ignorando las ineficiencias, podrías hacer esto en 4096 instrucciones. Simplemente ha dividido el número de operaciones por el número de núcleos paralelos sobre los cuales realizar las operaciones.

Si tuviera un algoritmo FPGA que pudiera calcular la covarianza de 4096 artículos simultáneamente, y espacio en el FPGA para ensamblar 4096 de estos bloques, teóricamente podría calcular la covarianza de 4096 o menos elementos en una sola operación.

Eso no significa que el algoritmo es ahora \ $ O (1) \ $, significa que has dividido \ $ n \ $ por \ $ 2 ^ {24} \ $. El algoritmo sigue siendo \ $ O (n ^ 2) \ $. Los FPGA son excelentes para algunas tareas, pero no son mágicos.

Sí, si no hay dependencias de datos, entonces debería ser una aceleración fácil. Pero será una aceleración fácil para cualquier otro tipo de paralelismo (como el uso de GPU o SSE) y probablemente encontrará que pueden superar a un FPGA en la mayoría de las aplicaciones para eso.

Para problemas suficientemente grandes, podría ser capaz de construir una implementación de menor potencia o rendimiento en FPGA, pero no olvide tener en cuenta la potencia y el tiempo necesarios para obtener conjuntos de datos de un procesador para el FPGA y volver a obtener los resultados.

Los FPGA en un lugar pueden obtener aceleraciones espectaculares sobre otras implementaciones es cuando hay mucho paralelismo y sabes mucho sobre cómo se configuran los accesos de memoria y el controlador de caché del procesador no puede "ver" esos patrones. Puede aprovechar esto para programar accesos a la memoria para asegurarse de que el bus de memoria nunca esté inactivo (o que se vaciarán las cosas que se necesitarán en un futuro cercano)