El primer paso es desarrollar lo que quieres decir con optimizar . Dices “reduce los ciclos y la cantidad de instrucciones”. Eso no es realmente suficiente para continuar.
- ¿Tiene un objetivo de rendimiento, en términos de tiempo real? Por ejemplo, μsec para una función particular?
- ¿Tiene un objetivo de potencia / energía, en términos de vatios o julios? ¿Está tratando de funcionar con una batería AA, o puede enfriarlo con agua y hacerlo funcionar con una fuente de alimentación industrial? ¿En algún lugar entremedio?
- ¿Tiene un área / precio objetivo? ¿Será esto algo pequeño en un pequeño controlador integrado del tamaño de un guisante que se vende por $ 0.50, o un chip gigante del tamaño del servidor que cuesta> $ 1K?
- ¿Tienes un presupuesto complejo? ¿Es esto algo que espera de un equipo pequeño y enfocado (1 a 4 ingenieros) con habilidades básicas para implementar, o se necesitará un gran equipo de ingenieros experimentados para construirlo?
- ¿Qué tan flexible debe ser? Desea optimizar un conjunto determinado de algoritmos, pero ¿qué parámetros espera que varíen?
- ¿Con qué necesita interactuar? ¿De dónde está obteniendo los datos que está procesando y a qué está pasando sus resultados?
- ¿Está limitado por una arquitectura existente que está intentando modificar y / o ampliar?
Es trivial reducir la cantidad de instrucciones y la cantidad de ciclos. Tenga una instrucción, GO , que activa un montón de lógica de función fija que implementa directamente la función. Esa es una instrucción. Y es trivial reducir la cantidad de ciclos, arrojando mucho hardware al problema. En teoría, podría desenrollar completamente la mayoría de los algoritmos a la lógica combinatoria por completo , y se ejecutaría en un “ciclo” muy largo y muy lento.
Pero, tal diseño sería extremadamente inflexible y posiblemente bastante grande. Dependiendo de la tecnología del proceso, podría consumir mucha energía debido a fugas. Puede ser poco práctico construirlo a menos que tenga un presupuesto muy grande.
Recuerdo haber revisado una patente que describía, en parte, un algoritmo para acelerar la división al realizar múltiples divisiones de prueba en paralelo. En principio, el recuento cíclico del algoritmo solo estaba limitado por el número de sumadores que estaba dispuesto a comprometer con el silicio. Incluso mostraron una tabla que sugería que, si deseaba hacer una división de 64 bits por 32 bits en un solo ciclo, solo tenía que dejar 4 mil millones de sumadores. Estoy seguro de que cuando escribieron esa línea en la tabla, sus lenguas estaban incrustadas firmemente en la mejilla. (Mi abogado de patentes, que coescribió la patente, siempre mencionó esa tabla con una sonrisa.) Pero muestra el peligro de un estudio en papel sin restricciones frente a considerar las verdaderas compensaciones impuestas al tratar de construirla.
(Tabla 65, patente de los Estados Unidos 5.446.651.)
Menciona que tiene un procesador ARM como línea de base. ¿Cúal? En la alineación actual, esos se extienden desde pequeños núcleos Cortex-M0 hasta núcleos gigantes Cortex-A73. Una vez que elija uno, tal vez pueda establecer su objetivo en relación con él: “La mitad del ciclo cuenta con foo , con un 10% de frecuencia de reloj, 30% de aumento de área y 40% de reducción de energía por función”.
Una vez que tenga un objetivo en mente, puede usarlo para comenzar a medir su arquitectura en función de sus objetivos. Puede decidir que está bien consumir más ciclos para algunas tareas si obtiene un mayor beneficio del aumento de la velocidad del reloj. O, si su algoritmo tiene mucho paralelismo inherente, puede aceptar una velocidad de reloj reducida si le permite colocar grandes cantidades de unidades funcionales en paralelo. O tal vez, solo está tratando de encontrar algunas instrucciones de elección para calzar zapatos en una tubería existente como un pequeño delta para darle un impulso modesto a un algoritmo suyo.
Hasta que establezca el problema que está tratando de resolver, establezca criterios para evaluar las compensaciones y establezca cómo va a medir el éxito, es probable que fracase y luego falle.
Puede estudiar algunas arquitecturas existentes que ya funcionan bien en el área que desea optimizar. Los DSP VLIW tienen sus puntos fuertes. Las arquitecturas vectoriales tienen sus puntos fuertes. Las arquitecturas de memoria-memoria, aunque impopulares en la actualidad, tienen sus propios puntos fuertes, incluso. Saber qué hacen los procesadores prácticos existentes y qué tan bien funcionan le dará una idea de un objetivo razonable para disparar.
