¿Escribir algoritmos DSP directamente en C o en ensamblador? [cerrado]

Siempre es mejor tener su algoritmo implementado en un lenguaje de nivel superior (qué C se compara con el ensamblaje), incluso si planea implementar todo en ensamblaje al final.

• es probable que ni siquiera necesite ensamblar . Si el código generado por su compilador cumple con sus objetivos de diseño, su trabajo está hecho.

• si no, no iniciará la codificación del ensamblaje desde cero . Deje que el compilador genere el código inicial para usted y utilícelo como base para su versión de ensamblaje optimizada.

• más adelante, cuando necesites probar tu código de ensamblaje optimizado , te alegrará tener la versión C En lugar de calcular manualmente la salida correcta para sus datos de entrada de prueba, simplemente puede enviar esos datos de entrada a su implementación de C no optimizada, y luego verificar que el ensamblaje produzca exactamente la misma salida después de las optimizaciones realizadas.

Si, después de algunos años, un nuevo desarrollador necesitará realizar modificaciones en su algoritmo y todo lo que tienen a mano es un código de ensamblaje altamente optimizado, existe una gran posibilidad de que tengan que comenzar desde cero.

Si los escritores del compilador ponen un gran esfuerzo en optimizarlo para ese objetivo, al menos hará uso de las instrucciones / arquitectura DSP especiales. Pero para obtener el máximo rendimiento, nunca será tan bueno como el montaje manual. Sin embargo, podría ser lo suficientemente bueno, depende de tu aplicación.

Otras alternativas incluyen:

1. Escriba la mayoría de su programa en C, y solo la parte numérica más crítica en el ensamblaje.
2. Escriba el programa en C y use las bibliotecas suministradas por el fabricante o terceros: si está realizando tareas DSP comunes como FFT, filtros FIR / IIR, etc., es probable que alguien ya haya escrito el código de máquina sintonizado a mano para hacerlo. , para que pueda usar eso (es posible que tenga que pagarlo) y vincularlo a su aplicación.

La optimización prematura es la raíz de todo mal. - Donald Knuth

Cuando descubra que no obtiene el rendimiento suficiente de su código, primero haga un perfil de su programa, encuentre los cuellos de botella, analice sus requisitos de rendimiento y solo entonces comience a hacer optimizaciones. Escribir código ensamblador es el último recurso.

  

Mi pregunta es si solo programo en C, ¿el compilador (que también proviene de la compañía de chips DSP) no lo optimizaría para ese DSP y usaría sus capacidades?

Sí, el compilador de C puede hacer una buena cantidad de optimización. Pero esto depende de la calidad del compilador. Con frecuencia, un ser humano puede escribir un código de ensamblaje más rápido que el código C compilado. A expensas del dolor y el sufrimiento humanos, es decir.

  

¿O realmente necesito escribir rutinas DSP directamente en ensamblaje?

Primero escriba en C, luego en el perfil, luego decida si necesita escribir en el ensamblaje. Con suerte, no necesitarías el montaje.

Su DSP se anunciará con un máximo de MAC sostenido, asumiendo que todas las canalizaciones están llenas. Eso es obviamente un límite superior a lo que se puede lograr. Usted sabe cuántos MAC tomarán sus filtros y otros procesamientos, a partir de su análisis. Trate de tener el primero al menos dos veces el segundo, ya que no podrá mantener el núcleo DSP funcionando al máximo. Al igual que no intentaría llenar un FPGA por encima del 70% del recurso (PAR se vuelve muy lento por encima de eso), el desarrollo podría ser muy lento al intentar eliminar los últimos MAC teóricos de un DSP.

Codificará toda su aplicación en C. No es práctico escribir todo lo adicional que sea necesario en el ensamblador, la prueba de inyección y la visibilidad, el mantenimiento, etc. Escriba una versión en C del filtro de prueba. Escriba una versión de ensamblador del mismo filtro para verificar que, de hecho, puede escribir un ensamblador para esta bestia.

Ahora haz algunos tiempos. Utilice un RTOS aprobado por el proveedor. Compare el tiempo de ejecución de su módulo ensamblador de prueba con una versión C. Si están dentro de un pequeño porcentaje, sigan adelante. Si es triple, entonces lea la documentación, pregunte al proveedor y descubra por qué el compilador no lo está ajustando. Es posible que tenga que aprender a escribir su sabor de C tanto como a establecer las marcas de compilación correctas, será más rápido descubrir cómo manejar el compilador correctamente que reescribir todo en el ensamblador.

Has hecho todo esto antes de comprometerte a un DSP, a una cadena de herramientas.

Una vez que tenga una cadena de herramientas con la que pueda trabajar, un compilador que pueda ajustar para estar razonablemente cerca del máximo, un DSP con un margen de tiempo restante, entonces puede estar razonablemente seguro de que muy pocas partes de su conjunto de códigos necesitarán ser puesto en ensamblador para terminar el trabajo.

Aunque ya respondí esta pregunta, agregaré otra respuesta para ilustrar un punto de vista diferente:

¡Escribe en C, lee en ensamblaje!

Entonces, en lugar de escribir en ensamblaje, escribirá la lógica en C, asegurándose cuidadosamente de que la salida del ensamblador del código C sea óptima. A menudo puede hacer ciertos trucos en el código C para afectar la salida del ensamblador. Utilice las funciones en línea estáticas cuando tenga sentido. Si necesita usar algunas instrucciones especiales que admite el DSP, haga una abstracción de la función en línea estática de la instrucción especial y llame a la instrucción especial usando la abstracción.

Aunque tengo que decir que nunca he programado DSP, este enfoque de escribir el código C mientras observaba cuidadosamente el ensamblaje compilado me ha funcionado extremadamente bien en las máquinas x86. Tan bien, de hecho, que nunca he tenido que escribir nada en el ensamblaje para obtener el mejor rendimiento posible. En lugar de optimizar el código de ensamblaje, modificaré el código C de tal manera que el ensamblaje sea óptimo.

Por supuesto, esto depende de que haya buenos compiladores de C disponibles. Para x86, tales compiladores están disponibles (a menudo es necesario especificar un nivel de optimización más alto que el predeterminado). Para los DSP, francamente no sé si los compiladores son tan buenos.

El beneficio de este enfoque es que tiene una base de código portátil única, optimizada para dar como resultado un ensamblaje óptimo para un DSP determinado, pero también funciona si el DSP se cambia a otra cosa. Por supuesto, es posible que tenga que ajustar ligeramente el código C para obtener el mejor rendimiento posible en el nuevo DSP.

En general, no es necesario escribir las fuentes del ensamblador si:

• optimiza C en las secciones críticas: un buen uso de "registro" palabra clave, funciones en línea, ...
• podrían ser algunas funciones del programa C usando asm bloques

Eso significa revisar manualmente el ensamblador generado por el compilador de C (para las partes críticas) y modificar la fuente hasta un nivel de optimización suficiente.

Yo diría aquí que si hace filtros FIR / IIR, es mucho más importante qué algoritmo usa (el algoritmo trivial en comparación con la transformada de Fourier rápida (FFT)) que el idioma que usa (C en comparación con el ensamblado).

¿Escribiría FFT en ensamblaje? Probablemente no.

¿Podría escribir FFT yo mismo? Probablemente, la respuesta a esto tampoco sea, ya que FFT ya se ha implementado muchas veces. Así que es probable que encuentre alguna biblioteca que ya tenga FFT implementado. Teniendo en cuenta que C es un lenguaje portátil, mientras que el ensamblaje no lo es, es mucho más probable que encuentre bibliotecas ya implementadas en C.

Si desea el rendimiento más extremo posible, obviamente puede ajustar manualmente un algoritmo FFT para que funcione lo más rápido posible en lenguaje ensamblador. Pero realmente no creo que tenga sentido hacerlo, excepto en circunstancias muy excepcionales.

Mi propia opinión FWIW es que cada vez que desee la máxima velocidad / eficiencia / rendimiento / lo que sea, el ensamblador es su amigo, siempre y cuando sea competente. Un compilador es tonto; "sabe" solo lo que su autor pensó en programar, y su autor no conocía su aplicación en absoluto.

Debo admitir que me encantan los ensambladores desde principios de los 80s micros de 8 bits (no muy diferentes a los MCU modernos en muchos aspectos) donde aprender "código de máquina" era un requisito previo para obtener un rendimiento útil de ellos, pero creo que su función sigue siendo la forma de programar para obtener la máxima eficiencia. Además, es altamente gratificante, ya que puedes lanzar todo tipo de métodos abreviados de optimización que un compilador no pensará, porque un compilador no puede pensar en absoluto.

C está bien, supongo. Pero si realmente sabe lo que quiere que haga su máquina a nivel de hardware, vaya al ensamblador.