c++ exception embedded arm overhead

Sobrecarga de excepción C++



exception embedded (7)

Creo que es sobre todo FUD, en estos días.

Las excepciones tienen una pequeña sobrecarga en la entrada y salen a los bloques que crean objetos que tienen constructores / destructores, pero que en realidad no deberían equivaler a una lata de beans en la mayoría de los casos.

Medir primero, optimizar segundo.

Sin embargo, lanzar una excepción suele ser más lento que solo devolver una bandera booleana, por lo tanto, lanzar excepciones solo para eventos excepcionales .

En un caso, vi que el RTL estaba construyendo trazas de pila imprimibles completas de tablas de símbolos cada vez que se lanzaba una excepción para el posible uso de depuración. Como puedes imaginar, esto no fue algo bueno . Esto fue hace unos años y la biblioteca de depuración se corrigió rápidamente cuando salió a la luz.

Pero, IMO, la confiabilidad que puede obtener del uso correcto de las excepciones supera con creces la penalización de rendimiento menor. Úselos, pero con cuidado.

Editar:

@jalf hace algunos buenos comentarios, y mi respuesta anterior estaba dirigida a la pregunta relacionada de por qué muchos desarrolladores incrustados en general aún menosprecian las excepciones.

Pero, si el desarrollador de una plataforma en particular, SDK dice " no usar excepciones ", es probable que tenga que ir con eso. Quizás haya problemas particulares con la implementación de excepciones en su biblioteca o compilador, o tal vez estén preocupados por las excepciones generadas en las devoluciones de llamada que causan problemas debido a la falta de seguridad de excepción en su propio código.

¿Por qué los desarrolladores de plataformas integradas intentan continuamente eliminar las C++ exceptions de uso de C++ exceptions de sus SDKs ?

Por ejemplo, Bada SDK sugiere la siguiente solución para el uso de excepciones, que se ve excepcionalmente feo:

result MyApp::InitTimer() { result r = E_SUCCESS; _pTimer = new Timer; r = _pTimer->Construct(*this); if (IsFailed(r)) { goto CATCH; } _pTimer->Start(1000); if (IsFailed(r)) { goto CATCH; } return r; CATCH: return r; }

¿Cuáles son las razones de este comportamiento?

Por lo que sé, ARM compiladores ARM totalmente compatibles con las C++ exceptions y esto no podría ser el problema. ¿Qué más? ¿Es la sobrecarga del uso de excepciones y los desenrollamientos en las plataformas ARM realmente GRANDES para pasar mucho tiempo haciendo tales soluciones?

Tal vez algo más de lo que no estoy enterado?

Gracias.

El compilador moderno de C ++ puede reducir el uso en tiempo de ejecución de la excepción a menos del 3% de la sobrecarga. Aun así, si al programador extremo le resulta caro, entonces habrían recurrido a trucos tan sucios.

Vea aquí la página de Bjarne Strourstrup para, ¿Por qué usar Excepciones?

Esta actitud hacia las excepciones no tiene nada que ver con el rendimiento o el soporte del compilador, y todo tiene que ver con la idea de que las excepciones agregan complejidad al código .

Esta idea, hasta donde puedo decir, es casi siempre una idea errónea, pero parece tener poderosos defensores por alguna razón inconcebible.

Puedo pensar en un par de razones posibles:

  • Las versiones anteriores del compilador no admitían excepciones, por lo que se ha escrito una gran cantidad de código (y se han establecido convenciones) donde no se utilizan las excepciones
  • Las excepciones tienen un costo, y puede ser de hasta el 10-15% de su tiempo total de ejecución (también se pueden implementar para que prácticamente no requiera tiempo, pero en cambio use bastante memoria, lo que probablemente no sea muy conveniente) en sistemas integrados tampoco)
  • Los programadores integrados tienden a ser un poco paranoicos con respecto al tamaño del código, el rendimiento y, no menos importante, la complejidad del código. A menudo les preocupa que las características "avanzadas" no funcionen correctamente con su compilador (y, a menudo, también tienen razón)

Solo mis 2 centavos ...

Yo consulto exclusivamente en sistemas integrados, la mayoría de ellos difíciles en tiempo real y / o seguridad / vida crítica. La mayoría de ellos se ejecutan en 256K de flash / ROM o menos; en otras palabras, estos no son sistemas de bus VME "similares a PC" con 1GB + de RAM / flash y una CPU de 1GHz +. Están profundamente arraigados, son sistemas de recursos limitados.

Diría que al menos el 75% de los productos que usan C ++ deshabilitan las excepciones en el compilador (es decir, el código compilado con los modificadores del compilador que desactivan las excepciones). Siempre pregunto por qué. Lo creas o no, la respuesta más común NO es la sobrecarga / costo del tiempo de ejecución o la memoria.

Las respuestas suelen ser una mezcla de:

  • "No estamos seguros de saber cómo escribir el código de excepción de seguridad". Para ellos, verificar los valores de retorno es más familiar, menos complejo, más seguro.
  • "Suponiendo que solo lanza una excepción en casos excepcionales, estas son situaciones en las que reiniciamos de todos modos [a través de su propia rutina de manejo de error crítico]"
  • Problemas con el código heredado (como había mencionado jalf): están trabajando con un código que comenzó hace muchos años cuando su compilador no admitía excepciones, o no las implementaba correctamente o de manera eficiente.

Además, a menudo hay un poco de incertidumbre / temor nebuloso sobre los gastos generales, pero casi siempre no está cuantificado / no está perfilado, es simplemente arrojado por ahí y tomado a valor nominal. Puedo mostrarle informes / artículos que indiquen que la sobrecarga de las excepciones es del 3%, 10% -15%, o ~ 30% - haga su elección. La gente tiende a citar la figura que remite su propio punto de vista. Casi siempre, el artículo está desactualizado, la plataforma / conjunto de herramientas es completamente diferente, etc., por lo que, como dice Roddy, debe medirse en su plataforma.

No necesariamente estoy defendiendo ninguna de estas posiciones, solo le estoy dando retroalimentación / explicaciones del mundo real que he escuchado de muchas empresas que trabajan con C ++ en sistemas integrados, ya que su pregunta es "¿por qué tantos desarrolladores integrados evitan las excepciones?" ? "

Una opinión en contra de los "gotos son malvados", expuesta en las otras respuestas. Estoy haciendo esta wiki de la comunidad porque sé que esta opinión contraria será inflamada.

Cualquier programador en tiempo real que valga la pena, sabe este uso de goto . Es un mecanismo ampliamente utilizado y ampliamente aceptado para el manejo de errores. Muchos entornos de programación en tiempo real no implementan <setjmp.h>. Las excepciones son conceptualmente versiones limitadas de setjmp y longjmp . Entonces, ¿por qué proporcionar excepciones cuando el mecanismo subyacente está prohibido?

Un entorno puede permitir excepciones si se puede garantizar que todas las excepciones lanzadas se manejen localmente. La pregunta es, ¿por qué hacer esto? La única justificación es que los gotos son siempre malos. Bueno, no siempre son malvados.