ventajas que español desventajas caracteristicas c linux embedded systems-programming

c - que - mongodb español



Tenemos que usar C "por razones de rendimiento" (19)

En esta era de muchos idiomas, parece que hay un gran lenguaje para cada tarea y me encuentro profesionalmente luchando contra un mantra de " nada más que C es rápido ", donde rápido realmente pretende significar "lo suficientemente rápido". Trabajo con personas de mente abierta muy racionales, a quienes les gusta comparar números, y todo lo que tengo son pensamientos y opiniones. ¿Podría ayudarme a encontrar mi camino a través de opiniones subjetivas y al "mundo real"?

¿Me ayudaría a encontrar información sobre qué pasaría si se utilizaran otros lenguajes para la programación de sistemas embebidos y (Linux)? Podría muy bien estar presionando una hipótesis falsa y agradecería enormemente la investigación para mostrarme esto. ¿Podría, por favor, vincular o incluir buenos números para ayudar a mantener al mínimo los comentarios de "esa es solo su opinión"?

Así que 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

"Nada más que C es rápido [suficiente]" es una optimización temprana y errónea por todas las razones por las que las optimizaciones iniciales son erróneas. Si su sistema tiene la complejidad suficiente para que sea deseable algo más que C, habrá partes del sistema que deben ser "lo suficientemente rápidas" y partes con restricciones más ligeras. Si al escribir su código, por ejemplo, en Python el proyecto se terminará más rápido y con menos errores, entonces puede seguir con C o código de ensamblaje para acelerar las partes críticas.

Incluso si resulta que todo el código debe escribirse en C o en un ensamblaje 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 Python de trabajo y reemplazar gradualmente las piezas con código C hasta que alcance el rendimiento necesario.

Por lo tanto, 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. Puede ser que C sea la herramienta más apropiada para comenzar, pero ciertamente no siempre, incluso en sistemas integrados.

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

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

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

Aparte del rendimiento, hay otra consideración: lo más probable es que esté tratando con API de bajo nivel que fueron diseñadas para ser utilizadas en C o C ++ .

Si no puede usar algún SDK, solo tendrá problemas en lugar de ahorrar tiempo con el desarrollo utilizando un lenguaje de nivel superior. Como mínimo, terminará rehaciendo un montón de declaraciones de funciones y definiciones constantes.

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 pidió, ya que no tiene un enfoque en la programación de C embebida. Pero es interesante sin embargo. El primero demuestra el rendimiento de C ++ y los beneficios de usar el código "inseguro" para tareas intensivas en el procesador. El segundo, de alguna manera, desacredita al primero y muestra que si escribes el código C # de manera un poco diferente, el rendimiento es casi el mismo.

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

C es ubicuo, disponible para casi cualquier arquitectura, generalmente desde el primer día de la 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 algunas razones para no usarlo.

C ++ es un lenguaje más amplio, y existen 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 cómo usarlo adecuadamente.

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

C realmente es tu mejor opción.

Hay una diferencia para escribir código C portátil y profundizar en las características del gen ghee de un compilador específico o casos de esquina del lenguaje (todo lo cual debe evitarse). Pero la portabilidad a través de compiladores y versiones de compilador. La cantidad de empleados que serán capaces de desarrollar o mantener el código. Los compiladores tendrán un tiempo más fácil con él y producirán un código mejor, más limpio y más confiable.

C no va a ninguna parte, con todos los nuevos idiomas diseñados para corregir las fallas en todos los idiomas anteriores. C, con todas las fallas que estos nuevos idiomas están tratando de solucionar, sigue siendo fuerte.

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

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.

El uso de C para sistemas integrados tiene algunas muy buenas razones, de las cuales el "rendimiento" es solo uno de los menores. Embedded está muy cerca del hardware, necesita dirección de memoria manual para comunicarse con el hardware. Todas las API y SDK están disponibles para C en su mayoría.

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

En mi experiencia, usar 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 con mejor soporte en casi todas las plataformas, especialmente en las plataformas de sistemas integrados.

Si desea utilizar otra cosa en un sistema integrado, a menudo se trata de averiguar qué opciones están disponibles, y luego determinar si el rendimiento, el consumo de memoria, el soporte de biblioteca, etc., son "lo suficientemente buenos" para su situación.

Es difícil argumentar en contra de C (u otros lenguajes de procedimiento como Pascal, Modula-2, Ada) y el ensamblaje para incrustados. 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 algo 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 o Lua o JavaScript como lenguaje de scripting.

Lo que quieres es la capacidad de ir rápida y fácilmente a C cuando tienes que hacerlo.

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

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

Probablemente también querrás mirar estas hermosas preguntas:

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

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

Echa un vistazo a los siguientes artículos

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 estás fuera de 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 los sistemas de escritorio, debido a la poca cantidad de funciones de langage que se comparan con C ++, por lo que me imagino que la diferencia es no trivial en los sistemas integrados. Esto se traduce en tiempos de iteración más rápidos, aunque OTOH no tiene las ventajas de C ++ (como las colecciones) que pueden ralentizarlo a largo plazo.

Para C:

  • C es a menudo el único idioma que admiten los compiladores para un procesador.
  • La mayoría de las bibliotecas y el código de ejemplo son probables también 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 memoria.
  • Fácil integración con lenguaje ensamblador.

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

Realmente no soy un programador integrado / de sistemas, pero me parece que los programas integrados generalmente necesitan un rendimiento determinista, que de inmediato descarta muchos lenguajes recolectados en la basura, porque en general no son deterministas. 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 uno de los límites: los idiomas / tiempos de ejecución cumplen con los requisitos determinísticos, el uso de la memoria, etc.

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, sino más bien una biblioteca que puede integrarse en C. Está orientada al uso en sistemas integrados y, en general, querrá para llamar al código Lua desde C. Pero pure C hace que el mantenimiento sea más simple (aunque no necesariamente más fácil), ya que todos lo saben.

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 apropiadamente, Pobre razón para rechazar C ++ .