Tenemos que usar C & # 8220; por razones de rendimiento & # 8221; [cerrado]

StackOverflow https://stackoverflow.com/questions/1223710

Pregunta

En esta era de muchos idiomas, parece haber un gran lenguaje para casi todas las tareas y me encuentro luchando profesionalmente contra un mantra de " nada más que C es rápido " ;, donde rápido realmente significa "lo suficientemente rápido". Trabajo con personas muy racionales de mente abierta, a quienes les gusta comparar números, y todo lo que tengo son pensamientos y opiniones. ¿Podrías ayudarme a encontrar mi camino más allá de las opiniones subjetivas y entrar en el "mundo real"?

¿Me ayudaría a encontrar información sobre qué pasaría si se pudieran usar otros lenguajes para la programación de sistemas integrados y (Linux)? Muy bien podría estar impulsando una hipótesis falsa y agradecería mucho la investigación para mostrarme esto. ¿Podría por favor vincular o incluir buenos números para ayudar a mantener el " esa es solo su opinión " comentarios al mínimo.

Entonces, estos son mis requisitos particulares

  • la memoria no es una restricción seria
  • la portabilidad no es una preocupación seria
  • este no es un sistema en tiempo real
¿Fue útil?

Solución

" Nada más que C es rápido [suficiente] " es una optimización temprana e incorrecta por todas las razones por las cuales las optimizaciones tempranas son incorrectas. Si su sistema tiene suficiente complejidad como para que sea deseable algo distinto de C, entonces habrá partes del sistema que deberán ser "suficientemente rápidas". y partes con restricciones más ligeras. Si escribe su código, por ejemplo, en Python, el proyecto se terminará más rápido, con menos errores, entonces puede seguir con un código C o de ensamblaje para acelerar las partes críticas.

Incluso si resulta que todo el código debe estar escrito en C o ensamblado para cumplir con los requisitos de rendimiento, la creación de prototipos en un lenguaje como Python puede tener beneficios reales. Puede tomar su prototipo de Python en funcionamiento y reemplazar gradualmente las piezas con código C hasta alcanzar el rendimiento necesario.

Entonces, use las herramientas que le permiten realizar el trabajo de desarrollo de la manera más correcta y rápida, luego use datos reales para determinar dónde necesita optimizar. Podría ser que C es la herramienta más apropiada para comenzar a veces, pero ciertamente no siempre, incluso en sistemas integrados.

Otros consejos

En mi experiencia, el uso de C para la programación integrada y de sistemas no es necesariamente un problema de rendimiento, a menudo es un problema de portabilidad. C tiende a ser el lenguaje más portátil y mejor soportado en casi todas las plataformas, especialmente en plataformas de sistemas integrados.

Si desea utilizar algo más en un sistema integrado, a menudo es cuestión de averiguar qué opciones están disponibles, luego determinar si el rendimiento, el consumo de memoria, el soporte de la biblioteca, etc., son "suficientemente buenos". para su situación.

El uso de C para sistemas embebidos tiene algunas muy buenas razones, de las cuales "rendimiento" Es solo uno de los menores. Embedded está muy cerca del hardware, necesita direccionamiento manual de memoria para comunicarse con el hardware. Todas las API y SDK están disponibles para C principalmente.

Solo hay unas pocas plataformas que pueden ejecutar una VM para Java o Mono, lo que se debe en parte a las implicaciones de rendimiento, pero también a los costos de implementación costosos.

Además del rendimiento, hay otra consideración: lo más probable es que se trate de API de bajo nivel que fueron diseñadas para usarse en C o C ++ .

Si no puede usar un SDK, solo se meterá en problemas en lugar de ahorrar tiempo desarrollando con un lenguaje de nivel superior. Como mínimo, terminarás rehaciendo un montón de declaraciones de funciones y definiciones constantes.

Para C:

  • C es a menudo el único lenguaje compatible con los compiladores para procesadores.
  • La mayoría de las bibliotecas y el código de ejemplo también es probable en C.
  • La mayoría de los desarrolladores integrados tienen años de experiencia en C pero muy poca experiencia en cualquier otra cosa.
  • Permite la interfaz directa de hardware y la gestión manual de la memoria.
  • Fácil integración con lenguaje ensamblador.

C va a estar presente por muchos años más. En el desarrollo integrado es un monopolio que sofoca cualquier intento de cambio. Un lenguaje que necesita una máquina virtual como Java o Lua nunca se generalizará en el entorno integrado. Un lenguaje compilado podría tener una oportunidad si proporciona nuevas características atractivas sobre C.

Hay varios puntos de referencia en la web entre diferentes idiomas. La mayoría de ellos encontrará una implementación C o C ++ en la parte superior, ya que le dan más control para optimizar realmente las cosas.

Ejemplo: El juego de pruebas de lenguaje de computadora .

Es difícil argumentar en contra de C (u otros lenguajes de procedimiento como Pascal, Modula-2, Ada) y el ensamblaje para embebido. Hay una gran historia de éxito con esos idiomas. En general, desea eliminar el riesgo de lo desconocido. Intentar usar algo que no sea C o ensamblaje, en mi opinión, es un desconocido. Dicho esto, no hay nada de malo en un modelo mixto en el que usas uno de los esquemas que van a C, Python, Lua o JavaScript como lenguaje de script.

Lo que desea es la capacidad de ir rápida y fácilmente a C cuando sea necesario.

Si convence al equipo para que vaya con algo que no está probado para ellos, el proyecto es su cookie. Si se desmorona, probablemente será visto como tu culpa.

Este artículo (por Michael Barr) habla sobre el uso de C, C ++, ensamblador y otros lenguajes en sistemas integrados, e incluye un gráfico que muestra el uso relativo de cada uno.

Y aquí hay otro artículo, titulado, Pobres razones para rechazar C ++ .

Hay situaciones en las que necesita un rendimiento en tiempo real, especialmente en sistemas integrados. También tiene graves limitaciones de memoria. Un lenguaje como C le brinda un mayor control sobre el tiempo de ejecución y el espacio de ejecución.

Entonces, dependiendo de lo que esté haciendo, C puede muy bien ser "mejor" o más apropiado.

Consulte los siguientes artículos

Ada es un lenguaje de programación de alto nivel diseñado para sistemas integrados y sistemas de misión crítica.

Es un lenguaje rápido y seguro que tiene verificación de datos integrada en todas partes. Es en lo que están programados los pilotos automáticos en los aviones.

En este enlace usted tiene una comparación entre Ada y C.

Es posible que desee consultar el D lenguaje de programación. Podría usar algunos ajustes de rendimiento, ya que hay algunas áreas en las que Python puede superarlo. Realmente no puedo señalarle comparaciones de referencia ya que no he estado manteniendo una lista, pero como lo señaló Peter Olsson, Benchmarks & amp; Implementaciones de lenguaje tiene D Digital Mars.

Probablemente también desee ver estas encantadoras preguntas:

C es omnipresente, disponible para casi cualquier arquitectura, generalmente desde el primer día de disponibilidad de un procesador. C ++ es un segundo cercano. Si su sistema puede admitir C ++ y tiene la experiencia necesaria, úselo con preferencia a C: es todo lo que C es, y más, por lo que hay pocas razones para no usarlo.

C ++ es un lenguaje más amplio, y hay construcciones y técnicas compatibles que pueden consumir recursos o comportarse de manera inaceptable en un sistema integrado, pero esa no es una razón para no usar el lenguaje, sino más bien cómo usarlo de manera apropiada.

Java y C # (en Micro.Net o WinCE) pueden ser alternativas viables para tiempo no real.

No soy realmente un programador de sistemas / incrustados, pero me parece que los programas incrustados generalmente necesitan un rendimiento determinista, que inmediatamente descarta muchos lenguajes recolectados de basura, porque son no deterministas en general . Sin embargo, se ha trabajado en la recolección de basura determinista (por ejemplo, Metronome para Java: http://www.ibm.com/developerworks/java/library/j-rtj4/index.html )

El problema es una de las restricciones: ¿cumplen los idiomas / tiempos de ejecución los requisitos deterministas, de uso de memoria, etc.?

C realmente es tu mejor opción.

Hay una diferencia para escribir código C portátil y profundizar demasiado en las características de ghee whiz de un compilador específico o casos de esquina del lenguaje (todo lo cual debe evitarse). Pero portabilidad entre compiladores y versiones de compiladores. El número de empleados que serán capaces de desarrollar o mantener el código. Los compiladores lo tendrán más fácil y producirán un código mejor, más limpio y más confiable.

C no va a ninguna parte, con todos los nuevos lenguajes diseñados para corregir las fallas en todos los idiomas anteriores. C, con todos los defectos que estos nuevos lenguajes están tratando de solucionar, aún se mantiene firme.

Aquí hay un par de artículos que comparan C # con C ++:

http://systematicgaming.wordpress.com/ 2009/01/03 / performance-c-vs-c /

http: //journal.stuffwithstuff. com / 2009/01/03 / debunking-c-vs-c-performance /

No es exactamente lo que solicitó, ya que no se enfoca en la programación C integrada. Pero no obstante es interesante. El primero demuestra el rendimiento de C ++ y los beneficios de usar "inseguro". código para tareas intensivas del procesador. El segundo desacredita un poco al primero y muestra que si escribe el código C # de manera un poco diferente, el rendimiento es casi el mismo.

Entonces diré que C o C ++ pueden ser el claro ganador en términos de rendimiento en muchos casos. Pero muchas veces el margen es delgado. Si usar C o no es otro tema completamente diferente. En mi opinión, realmente debería depender de la tarea en cuestión. Pero en los sistemas integrados a menudo no tienes muchas opciones.

Un par de personas han mencionado a Lua. Las personas que conozco que han trabajado con sistemas integrados han dicho que Lua es útil, pero en realidad no es su propio lenguaje en sí, sino más bien una biblioteca que puede integrarse en C. Está dirigido al uso en sistemas integrados y, en general, querrá llamar al código Lua desde C. Pero C puro facilita el mantenimiento (aunque no necesariamente más fácil), ya que todos lo saben.

Dependiendo de la plataforma incorporada, si las restricciones de memoria son un problema, lo más probable es que necesite usar un lenguaje de programación no recolectado.

C a este respecto es probablemente el más conocido por el equipo y el más ampliamente compatible con las bibliotecas y herramientas disponibles.

La verdad es que no siempre.

Parece que el tiempo de ejecución de .NET (pero cualquier otro tiempo de ejecución se puede tomar como ejemplo) impone varios MB de sobrecarga de tiempo de ejecución. Si esto es todo lo que tienes (en RAM), entonces no tienes suerte. JavaME parece ser más compacto, pero aún depende de los recursos que tenga a su disposición.

Los compiladores de C son mucho más rápidos incluso en sistemas de escritorio, debido a la poca cantidad de características de lenguaje que hay en comparación con C ++, por lo que me imagino que la diferencia no es trivial en los sistemas integrados. Esto se traduce en tiempos de iteración más rápidos, aunque OTOH no tiene las comodidades de C ++ (como las colecciones) que pueden ralentizarlo a largo plazo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top