compiler construction - ¿Alguien conoce algún compilador que optimice el código para el consumo de energía de los dispositivos integrados?
compiler-construction computer-architecture (4)
Es una opinión general de que un código más rápido consumirá menos energía porque puede poner la CPU en estado inactivo por más tiempo, pero cuando hablamos del consumo de energía, sigue una posibilidad:
Supongamos que hay una secuencia de instrucciones que se ejecuta en 1 ms y durante el proceso de ejecución el consumo de corriente promedio fue de 40 mA. .y tu Vdd es 3.3V
tan total energía consumida = V * I * t = 3.3 * 40 * 10 ^ -3 * 1 * 10 ^ -3 Joules = 13.2 * 10 ^ -6 Julios
y en otro caso hay una secuencia de instrucciones que se ejecuta en 2 ms y durante el proceso de ejecución, el consumo de corriente promedio es de 15 mA. .y Vdd es 3.3V
tan energía total consumida = V * I * t = 3.3 * 15 * 10 ^ -3 * 2 * 10 ^ -3 Joules = 9.9 * 10 ^ -6 Julios
así que la pregunta viene a. .. ¿Hay alguna arquitectura que tenga diferentes conjuntos de instrucciones para realizar la misma tarea con diferentes consumos actuales?
Y si hay ... ¿hay algún compilador que tenga esto en cuenta y genere un código que sea eficiente desde el punto de vista energético?
En el nivel de instrucción individual, cosas como cambiar en lugar de multiplicar disminuirían el consumo de energía y corriente, pero no estoy seguro de que compre el ejemplo de tomar el doble de tiempo pero usar la mitad de la corriente (para una frecuencia de reloj dada). ¿Reemplazar una multiplicación con un cambio y agregar, que dobla el tiempo, realmente toma la mitad de la corriente? Hay tantas otras cosas sucediendo en una CPU (solo la distribución del reloj en el chip toma corriente) que creo que domina el uso actual de fondo.
Bajar la frecuencia del reloj es probablemente lo más importante que puede hacer para reducir el consumo de energía. Y hacer tanto en paralelo como sea posible es la forma más fácil de reducir la velocidad del reloj. Por ejemplo, usar DMA sobre interrupciones explícitas permite que el procesamiento algorítmico termine en menos ciclos. Si tu CPU tiene modos de direccionamiento raros o instrucciones paralelas (te estoy mirando, TMS320), me sorprendería que no pudieras reducir a la mitad el tiempo de ejecución de los bucles apretados por debajo del doble de la corriente, lo que daría un ahorro neto de energía. Y en la familia de CPU Blackfin, bajar el reloj le permite reducir el voltaje del núcleo, lo que reduce drásticamente el consumo de energía. Me imagino que esto también es cierto en otros procesadores integrados.
Después de la velocidad del reloj, apuesto a que el consumo de energía está dominado por el acceso de E / S externo. En entornos de baja potencia, cosas como las fallas de caché te hacen daño dos veces: una vez en velocidad, una vez en ir a la memoria externa. Por lo tanto, desenrollar bucles podría empeorar las cosas, así como duplicar el número de instrucciones que necesita para esa multiplicación.
Todo lo cual quiere decir que la arquitectura del sistema creativo probablemente tendrá un mayor impacto de poder que decirle al compilador que favorezca un conjunto de instrucciones sobre otro. Pero no tengo números para respaldar esto, estaría muy curioso por ver algunos.
Prácticamente cualquier "optimización de código" hecha por un compilador, que computa la respuesta más rápidamente que el código no optimizado, es "ahorro de energía". (Como observó otro cartel, evitar errores de caché es una gran victoria). Entonces, la verdadera pregunta es, "¿qué optimizaciones están explícitamente destinadas a ahorrar energía, frente a reducir el tiempo de ejecución?" (Nota: algunas "optimizaciones" reducen el tamaño de la huella del código (al abstraer secuencias de código en subrutinas, etc.), lo que en realidad puede costar más energía).
Una inusual, que no he visto en ningún compilador, está cambiando la representación de los datos. Resulta que el costo de almacenar / transmitir un bit cero es diferente del costo de almacenar un bit. (Mi experiencia con TTL y CMOS es "cero" son más caros, porque se implementan en hardware como una especie de "pull-down activo" a través de una resistencia de la fuente de alimentación, causando flujo de corriente y calor, mientras que "ones" son implementado dejando que una señal "flote alto" a través de la misma extracción). Si hay un sesgo, entonces uno debe implementar el código del programa y los datos para maximizar el número de bits, en lugar de cero bits.
Para los datos, esto debería ser relativamente sencillo de hacer. Vea este documento para una muy buena encuesta y análisis del valor encontrado en la memoria; contiene algunos cuadros bastante maravillosos. Un tema común es Una gran cantidad de ubicaciones de memoria están ocupadas por miembros de un pequeño conjunto de valores distintos. De hecho, solo un número muy pequeño de valores (hasta 8) ocupan hasta el 48% de las ubicaciones de memoria , a menudo son números muy pequeños (los documentos muestran para algunos programas que una fracción significativa de las transferencias de datos son para valores pequeños, por ejemplo , De 0 a 4, siendo cero el valor más común). Si los ceros son realmente más caros de almacenar / transferir que los pequeños, los pequeños valores comunes sugieren almacenar valores en su formato de complemento . Esta es una optimización bastante fácil de implementar. Dado que los valores no son siempre los N naturales más pequeños, uno podría reemplazar el N-ésimo valor más frecuente en la memoria con N y almacenar el complemento de N, haciendo una búsqueda del valor real más cercano al procesador. (El autor del artículo sugiere un caché de "reutilización de valor" de hardware, pero eso no es una optimización del compilador).
Esto es un poco difícil de organizar para el código del programa, ya que el conjunto de instrucciones determina lo que puede decir, y generalmente el conjunto de instrucciones se diseñó independientemente de cualquier medición de energía. Sin embargo, uno podría elegir diferentes secuencias de instrucciones (eso es lo que hacen los optimizadores) y maximizarse para un bit en la secuencia de instrucciones. Dudo que esto sea muy efectivo en los códigos de operación de las instrucciones convencionales. Una vez, sin duda, podría colocar variables en ubicaciones cuya dirección tiene un gran número de bits, y prefiere usar registros con números más altos en lugar de inferiores (en el x86, EAX es el número de registro binario 000 y el EDI es el número de registro 111). hasta el punto de diseñar un conjunto de instrucciones de acuerdo con las frecuencias de ejecución de instrucciones, asignando código de operación con números mayores de un bit a las instrucciones ejecutadas frecuentemente.
Prueba " MAGEEC ". No tengo experiencia de primera mano del compilador. Pero la descripción en el sitio web indica que se puede generar un código de eficiencia energética.
No hay ninguno que yo sepa, pero creo que esto debería ser posible usando un marco de compilación como LLVM, adaptando el algoritmo de ponderación del planificador de instrucciones.
Editar: se ha hablado sobre el consumo de energía analítica en LLVM en FOSDEM.