Pregunta:
¿Debo intentar hacer mis bocetos lo más pequeños posible, incluso cuando tenga suficiente espacio?
Anonymous Penguin
2014-03-19 05:15:30 UTC
view on stackexchange narkive permalink

Recientemente se ha hablado mucho sobre la reducción de bocetos, pero si no necesita el espacio, ¿debería hacerlo? ¿Acelerará mi programa?

Tome este código:

  int led = 13; int val; void setup () {pinMode (led, OUTPUT); } bucle vacío () {digitalWrite (led, HIGH); // enciende el LED (ALTO es el nivel de voltaje) delay (1000); // esperar un segundo digitalWrite (led, LOW); // apaga el LED haciendo que la tensión sea BAJA (1000); // esperar un segundo digitalWrite (led, HIGH); // enciende el LED (ALTO es el nivel de voltaje) delay (1000); // esperar un segundo digitalWrite (led, LOW); // apaga el LED haciendo que la tensión sea BAJA (1000); // esperar un segundo digitalWrite (led, HIGH); // enciende el LED (ALTO es el nivel de voltaje) delay (1000); // esperar un segundo digitalWrite (led, LOW); // apaga el LED haciendo que la tensión sea BAJA (1000); // esperar un segundo digitalWrite (led, HIGH); // enciende el LED (ALTO es el nivel de voltaje) delay (1000); // esperar un segundo digitalWrite (led, LOW); // apaga el LED haciendo que la tensión sea BAJA (1000); // espera un segundo val = digitalRead (10);}  

1396 bytes en Arduino Uno. Ahora achiquémoslo un poco:

  int led = 13; int val; void setup () {pinMode (led, OUTPUT); } bucle vacío () {parpadeo (); val = digitalRead (10);} void blink () {digitalWrite (led, HIGH); // enciende el LED (ALTO es el nivel de voltaje) delay (1000); // esperar un segundo digitalWrite (led, LOW); // apaga el LED haciendo que la tensión sea BAJA (1000); // espera un segundo}  

1270 bytes. ¡Una disminución del 10%! Podría encogerse aún más. Tengo el espacio ... ¿es más eficiente (en cuanto a velocidad) hacerlo lo más compacto que pueda o dejarlo "descomprimido"? Me imagino que sería un poco más de trabajo (no mucho) llamando a blink (); , lo que ralentiza mi código. ¿Es esto cierto? ¿Existen otras ventajas / desventajas de hacerlo lo más pequeño posible (además del almacenamiento / distribución de archivos C ++)?

Creo que uno debería ser meticuloso con su código, pero nunca recurrir a la microoptimización cuando no esté justificado.
Para mí, lo que viene primero con respecto al código es su ** legibilidad **. Si es más largo, puede ser más difícil o puede llevar más tiempo comprenderlo correctamente. Si una optimización de gvensize hace que el código sea más claro, entonces debería usarlo.
Cinco respuestas:
#1
+12
alexan_e
2014-03-19 13:30:20 UTC
view on stackexchange narkive permalink

Es posible que el segundo código sea más pequeño, pero debido a la sobrecarga de llamadas a la función, la velocidad máxima de ejecución se reduce.
¿Es esto importante en su caso? No, porque tiene grandes retrasos de todos modos, pero si el código fuera una serie real de cálculos repetidos que deberían ejecutarse lo más rápido posible, entonces haría una diferencia.

Como regla general, el código más pequeño no necesariamente más rápido también.

Para la optimización del código (ya sea de tamaño o velocidad), puede consultar esta nota de aplicación de Atmel AVR4027: Consejos y trucos para optimizar su código C para microcontroladores AVR de 8 bits

Podría repetir todo lo que dice aquí pero no creo que tenga sentido, puedes leer el artículo original directamente.


Respecto a la optimización del compilador nivel. Arduino IDE utiliza el compilador avr-gcc con una configuración para la optimización Os .
Los niveles de optimización disponibles de avr-gcc son ( fuente1 fuente2 )

  • O0 o sin opción -O
    En este nivel de optimización, GCC no realiza ninguna optimización y compila el código fuente de la manera más sencilla posible. Cada comando en el código fuente se convierte directamente en las instrucciones correspondientes en el archivo ejecutable, sin reorganización. Esta es la mejor opción para usar cuando se depura un programa y es la predeterminada si no se especifica ninguna opción de nivel de optimización.

  • O1 o -O
    Este nivel activa las formas más comunes de optimización que no requieren ningún compromiso entre velocidad y espacio. Con esta opción, los ejecutables resultantes deberían ser más pequeños y rápidos que con -O0. Las optimizaciones más caras, como la programación de instrucciones, no se utilizan en este nivel. Compilar con la opción -O1 a menudo puede llevar menos tiempo que compilar con -O0, debido a la cantidad reducida de datos que deben procesarse después de optimizaciones simples.

  • O2
    Esta opción activa más optimizaciones, además de las utilizadas por -O1. Estas optimizaciones adicionales incluyen la programación de instrucciones. Solo se utilizan optimizaciones que no requieren ninguna compensación de espacio de velocidad, por lo que el ejecutable no debe aumentar de tamaño. El compilador tardará más en compilar programas y requerirá más memoria que con -O1. Esta opción es generalmente la mejor opción para la implementación de un programa, ya que proporciona la máxima optimización sin aumentar el tamaño del ejecutable. Es el nivel de optimización predeterminado para las versiones de paquetes GNU.

  • O3
    Esta opción activa optimizaciones más caras, como la función inlining, además de todas las optimizaciones de los niveles inferiores -O2 y -O1. El nivel de optimización -O3 puede aumentar la velocidad del ejecutable resultante, pero también puede aumentar su tamaño. En algunas circunstancias en las que estas optimizaciones no son favorables, esta opción puede hacer que un programa sea más lento.

  • Os
    Esta opción selecciona optimizaciones que reducen el tamaño de un ejecutable. El objetivo de esta opción es producir el ejecutable más pequeño posible, para sistemas restringidos por memoria o espacio en disco. En algunos casos, un ejecutable más pequeño también se ejecutará más rápido, debido a un mejor uso de la caché.

+1 Es mejor decirle al compilador que haga su código más grande / más rápido o más pequeño / más lento en lugar de hacer cosas tan tontas como desenrollar bucles innecesariamente.
#2
+7
CaseyS
2014-03-19 07:02:14 UTC
view on stackexchange narkive permalink

En términos generales, cuanto más pequeño, mejor. Sin embargo, hay un punto en el que demasiado pequeño hace que el programa se ejecute más lento.

Mi sugerencia es que si está trabajando en un boceto y es claramente obvio que está repitiendo el código una y otra vez, lo haría extraer eso y ponerlo en una función, no solo hace que el programa sea más pequeño, sino que lo hace más fácil de leer.

También hay algo de optimización detrás de escena durante la compilación, por lo que aunque el código C / C ++ parece ser grande, es probable que el compilador / enlazador esté determinando que algo se repite y lo consolida ... O al menos el compilador AVR que utilicé anteriormente lo hizo, no puedo recordar si Arduino hace esto.

Creo que tiene algunas optimizaciones ... Arduino IDE se compila con avr-gcc.
Poner código repetido en una función también crea solo una pieza de código que brinda la oportunidad de cometer errores, y solo un lugar para corregirlos. Además, solo hay un lugar para actualizar más tarde cuando necesite cambiar algo.
#3
+2
AMADANON Inc.
2015-01-20 08:34:29 UTC
view on stackexchange narkive permalink

Al considerar la optimización, piense detenidamente qué recurso es más valioso.

Puede optimizar el tamaño del código; esto le permitirá poner más código en su procesador. ¿Para qué se utilizará el resto del espacio? Si su código no encaja en su arduino y su alternativa es comprar un chip más grande, entonces vale la pena el esfuerzo.

Puede optimizar la velocidad: puede ejecutar más código en la misma cantidad de hora. Si está muestreando datos una vez por segundo y durmiendo el resto del tiempo, entonces esto no ayudará.

Puede optimizar el uso de energía, muy importante si tiene batería, menos importante si estás en red. Esto también podría ser no solo la energía consumida por el arduino, sino también los sensores de los motores &: ¿se pueden apagar por un tiempo?

Hay dos optimizaciones que muchos programadores olvidan: optimizar para el tiempo de desarrollo, y optimizar la legibilidad.

Cualquier optimización para una cosa tenderá a desoptimizarse para al menos una (a menudo varias) otras cosas. Si no sabe qué optimización será más útil, busque la legibilidad, luego el tiempo de desarrollo (¡porque la legibilidad de hoy = el tiempo de desarrollo de mañana x 10!)

Por lo general, lo más caro es el tiempo de desarrollo (es decir, SU tiempo, especialmente si está en el reloj de un cliente). La mayoría de las otras optimizaciones tienen un umbral: siempre que supere (¿esté por debajo?) De un umbral específico, una mayor optimización no ayuda. El tamaño del código y la velocidad de ejecución (excepto cuando se comparten entre tareas de la competencia) son así: si su código cabe en el chip, entonces es lo suficientemente pequeño. Si necesita hacer algo más más adelante, puede optimizarlo en ese momento. Si su programa puede hacer todo lo que necesita (asumiendo que es en tiempo real; calcular Pi es un caso diferente), entonces eso es tan rápido como debe ser.

#4
+1
Mud
2014-03-20 02:38:42 UTC
view on stackexchange narkive permalink

Su refactorización debe realizarse simplemente porque es mejor código, no porque sea más pequeño. La ventaja es que es más fácil de modificar.

Si reducir el tamaño del código da como resultado una pérdida de claridad (no es así en su caso), probablemente debería verlo como una optimización prematura.

#5
  0
JRobert
2014-04-07 05:40:00 UTC
view on stackexchange narkive permalink

Cuando su tiempo valga más que las ganancias, deje de optimizar.

¿Está escribiendo para alguien a cambio de una paga? Entonces esta debería ser su decisión. Pero en este caso, la legibilidad y claridad de su código es primordial; algún día, alguien más tendrá que modificar su código en su ausencia. Si entrega un código de alto rendimiento que funcione y que otra persona no pueda leer y manejar, no habrá cumplido con su obligación (a menos que se haya acordado específicamente).



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...