c# - example - ¿C realmente es más lento que decir C++?

summary example c# (12)

Me he estado preguntando sobre este tema desde hace un tiempo.

Por supuesto, hay cosas en C # que no están optimizadas para la velocidad, por lo que usar esos objetos o ajustes de idioma (como LinQ) puede hacer que el código sea más lento.

Pero si no usa ninguno de esos ajustes, simplemente compare los mismos fragmentos de código en C # y C ++ (es fácil traducir uno a otro). ¿Será realmente mucho más lento?

He visto comparaciones que muestran que C # podría ser aún más rápido en algunos casos, porque en teoría el compilador JIT debería optimizar el código en tiempo real y obtener mejores resultados:

Administrado o no administrado?

Debemos recordar que el compilador JIT compila el código en tiempo real, pero eso es una sobrecarga de 1 vez, el mismo código (una vez alcanzado y compilado) no necesita ser compilado nuevamente en tiempo de ejecución.

El GC tampoco agrega mucha sobrecarga, a menos que crees y destruyas miles de objetos (como usar String en lugar de StringBuilder). Y hacer eso en C ++ también sería costoso.

Otro punto que quiero mencionar es la mejor comunicación entre las DLL introducidas en .Net. La plataforma .Net se comunica mucho mejor que las DLL administradas basadas en COM.

No veo ninguna razón inherente por la que el lenguaje deba ser más lento, y realmente no creo que C # sea más lento que C ++ (tanto por la experiencia como por la falta de una buena explicación).

Entonces, ¿una parte del mismo código escrito en C # será más lento que el mismo código en C ++?
En caso afirmativo, ¿POR QUÉ?

Alguna otra referencia (que habla un poco de eso, pero sin explicación acerca de POR QUÉ):

¿Por qué querrías usar C # si es más lento que C ++?

¿Por qué escribiría una pequeña aplicación que no requiere mucho en la optimización en C ++, si hay una ruta más rápida (C #)?

¿Porque no siempre necesitas usar el (y yo uso este) el lenguaje "más rápido"? No conduzco para trabajar en un Ferrari solo porque es más rápido ...

Advertencia: la pregunta que ha hecho es realmente bastante compleja, probablemente mucho más de lo que cree. Como resultado, esta es una respuesta realmente larga.

Desde un punto de vista puramente teórico, probablemente exista una respuesta simple a esto: no hay (probablemente) nada sobre C # que realmente impida que sea tan rápido como C ++. A pesar de la teoría, sin embargo, hay algunas razones prácticas por las cuales es más lento en algunas cosas bajo ciertas circunstancias.

Consideraré tres áreas básicas de diferencias: características del lenguaje, ejecución de máquina virtual y recolección de basura. Los últimos dos a menudo van juntos, pero pueden ser independientes, así que los veré por separado.

Características del lenguaje

C ++ pone mucho énfasis en las plantillas y las características en el sistema de plantillas que, en gran medida, pretenden permitir que se haga todo lo posible en tiempo de compilación, por lo que desde el punto de vista del programa, son "estáticas". La metaprogramación de plantillas permite realizar cálculos completamente arbitrarios en tiempo de compilación (es decir, el sistema de plantillas está completo). Como tal, esencialmente cualquier cosa que no dependa de la entrada del usuario puede computarse en tiempo de compilación, por lo que en tiempo de ejecución es simplemente una constante. Sin embargo, la entrada a esto puede incluir cosas como la información de tipo, por lo que una gran parte de lo que harías mediante reflexión en tiempo de ejecución en C # normalmente se hace en tiempo de compilación mediante la metaprogramación de plantillas en C ++. Sin embargo, definitivamente hay una compensación entre la velocidad del tiempo de ejecución y la versatilidad: lo que las plantillas pueden hacer, lo hacen estáticamente, pero simplemente no pueden hacer todo lo que puede hacer la reflexión.

Las diferencias en las características del lenguaje significan que casi cualquier intento de comparar los dos idiomas simplemente transliterando C # en C ++ (o viceversa) es probable que produzca resultados en algún lugar entre sin sentido y engañoso (y lo mismo sería cierto para la mayoría de los otros pares de idiomas también). El simple hecho es que para algo más que un par de líneas de código, casi nadie es probable que use los idiomas de la misma manera (o lo suficientemente cerca de la misma manera) que tal comparación le dice algo acerca de cómo esos idiomas trabajar en la vida real.

Máquina virtual

Al igual que casi cualquier máquina virtual razonablemente moderna, Microsoft para .NET puede y hará la compilación JIT (también conocida como "dinámica"). Sin embargo, esto representa una serie de concesiones.

En primer lugar, la optimización del código (como la mayoría de los demás problemas de optimización) es en gran parte un problema NP-completo. Para cualquier cosa que no sea un programa verdaderamente trivial / de juguete, está casi garantizado que no "optimizará" verdaderamente el resultado (es decir, no encontrará el verdadero óptimo): el optimizador simplemente hará que el código sea mejor que este fue previamente Sin embargo, bastantes optimizaciones que son bien conocidas tardan una cantidad sustancial de tiempo (y, a menudo, memoria) en ejecutarse. Con un compilador JIT, el usuario está esperando mientras se ejecuta el compilador. La mayoría de las técnicas de optimización más costosas están descartadas. La compilación estática tiene dos ventajas: en primer lugar, si es lenta (por ejemplo, construir un sistema grande) normalmente se lleva a cabo en un servidor, y nadie pasa tiempo esperándola. En segundo lugar, un ejecutable se puede generar una vez , y muchas personas lo usan muchas veces. El primero minimiza el costo de optimización; el segundo amortiza el costo mucho más bajo sobre un número mucho mayor de ejecuciones.

Como se mencionó en la pregunta original (y muchos otros sitios web), la compilación de JIT tiene la posibilidad de una mayor conciencia del entorno objetivo, que debería (al menos teóricamente) compensar esta ventaja. No hay duda de que este factor puede compensar al menos parte de la desventaja de la compilación estática. Para algunos tipos bastante específicos de código y entornos de destino, puede incluso superar las ventajas de la compilación estática, a veces bastante dramáticamente. Al menos en mi prueba y experiencia, sin embargo, esto es bastante inusual. Las optimizaciones dependientes del objetivo parecen hacer diferencias bastante pequeñas o solo se pueden aplicar (de forma automática, de todos modos) a tipos de problemas bastante específicos. Los tiempos obvios que esto sucedería serían si estuviera ejecutando un programa relativamente antiguo en una máquina moderna. Un antiguo programa escrito en C ++ probablemente se habría compilado con código de 32 bits y seguiría usando código de 32 bits incluso en un procesador moderno de 64 bits. Un programa escrito en C # se habría compilado a un código de bytes, que luego la VM compilaría a código de máquina de 64 bits. Si este programa obtuvo un beneficio sustancial al ejecutarse como código de 64 bits, eso podría dar una ventaja sustancial. Durante un corto período de tiempo, cuando los procesadores de 64 bits eran bastante nuevos, esto pasó bastante. Sin embargo, el código reciente que probablemente se beneficie de un procesador de 64 bits generalmente estará disponible compilado estáticamente en código de 64 bits.

Usar una máquina virtual también tiene la posibilidad de mejorar el uso de la memoria caché. Las instrucciones para una VM a menudo son más compactas que las instrucciones nativas de la máquina. Muchos de ellos pueden caber en una cantidad determinada de memoria caché, por lo que tiene más posibilidades de que un código determinado esté en caché cuando sea necesario. Esto puede ayudar a mantener la ejecución interpretada del código VM más competitiva (en términos de velocidad) de lo que la mayoría de la gente esperaría inicialmente: puede ejecutar muchas instrucciones en una CPU moderna en el tiempo que tarda una falla en la caché.

También vale la pena mencionar que este factor no es necesariamente diferente entre los dos en absoluto. No hay nada que evite (por ejemplo) que un compilador de C ++ produzca resultados destinados a ejecutarse en una máquina virtual (con o sin JIT). De hecho, la C ++ / CLI de Microsoft es casi eso, un compilador de C ++ (casi) conformes (aunque con muchas extensiones) que produce resultados destinados a ejecutarse en una máquina virtual.

Lo contrario también es cierto: Microsoft ahora tiene .NET Native, que compila el código C # (o VB.NET) en un ejecutable nativo. Esto proporciona un rendimiento que, en general, se parece mucho más a C ++, pero conserva las características de C # / VB (por ejemplo, C # compilado en código nativo aún admite la reflexión). Si tiene un código C # de uso intensivo, esto puede ser útil.

Recolección de basura

Por lo que he visto, diría que la recolección de basura es el más pobre de estos tres factores. Solo por un ejemplo obvio, la pregunta aquí menciona: "GC tampoco agrega mucho sobrecarga, a menos que crees y destruyas miles de objetos [...]". En realidad, si crea y destruye miles de objetos, los gastos generales de la recolección de basura generalmente serán bastante bajos. .NET utiliza un eliminador generacional, que es una variedad de recolector de copias. El recolector de basura funciona comenzando desde "lugares" (p. Ej., Registros y pila de ejecución) que se sabe que los punteros / referencias son accesibles. Luego "persigue" esos indicadores a objetos que han sido asignados en el montón. Examina esos objetos para obtener más punteros / referencias, hasta que los haya seguido a todos al final de cualquier cadena, y haya encontrado todos los objetos que son (al menos potencialmente) accesibles. En el paso siguiente, toma todos los objetos que están (o al menos podrían estar ) en uso, y compacta el montón copiándolos a todos en un trozo contiguo en un extremo de la memoria que se maneja en el montón. El resto de la memoria es libre (los finalizadores de módulo tienen que ejecutarse, pero al menos en un código bien escrito, son lo suficientemente raros como para ignorarlos por el momento).

Lo que esto significa es que si crea y destruye muchos objetos, la recolección de basura agrega muy poca sobrecarga. El tiempo que demora un ciclo de recolección de basura depende casi por completo de la cantidad de objetos que se crearon pero no se destruyeron. La consecuencia principal de crear y destruir objetos a toda prisa es simplemente que el GC tiene que correr más a menudo, pero cada ciclo seguirá siendo rápido. Si crea objetos y no los destruye, el GC se ejecutará con más frecuencia y cada ciclo será considerablemente más lento, ya que pasará más tiempo persiguiendo punteros a objetos potencialmente vivos, y pasará más tiempo copiando objetos que todavía están en uso.

Para combatir esto, el basurero generacional supone que los objetos que han permanecido "vivos" durante bastante tiempo probablemente continúen vivos durante bastante tiempo más. En base a esto, tiene un sistema donde los objetos que sobreviven a cierto número de ciclos de recolección de basura se "mantienen", y el recolector de basura simplemente comienza a asumir que todavía están en uso, así que en lugar de copiarlos en cada ciclo, simplemente se va ellos solos. Esta es una suposición válida con suficiente frecuencia como para que el basureo generacional típicamente tenga una sobrecarga considerablemente menor que la mayoría de las otras formas de GC.

La administración de memoria "manual" a menudo es tan poco conocida. Solo por un ejemplo, muchos intentos de comparación suponen que toda la gestión de la memoria manual sigue también un modelo específico (por ejemplo, asignación de mejor ajuste). A menudo, esto es poco (si es que hay alguno) más cercano a la realidad que las creencias de muchas personas sobre la recolección de basura (por ejemplo, la suposición generalizada de que normalmente se hace usando el recuento de referencias).

Dada la variedad de estrategias para la recolección de basura y la administración manual de la memoria, es bastante difícil comparar las dos en términos de velocidad general. Intentar comparar la velocidad de asignación y / o liberación de la memoria (por sí mismo) está casi garantizado para producir resultados que en el mejor de los casos carecen de sentido y, en el peor de los casos, son engañosos.

Tema de bonificación: puntos de referencia

Dado que bastantes blogs, sitios web, artículos de revistas, etc. afirman proporcionar evidencia "objetiva" en una dirección u otra, pondré mi valor de dos centavos en ese tema también.

La mayoría de estos puntos de referencia son un poco como los adolescentes que deciden competir con sus autos, y quien gane se quedará con los dos autos. Sin embargo, los sitios web se diferencian de una manera crucial: el tipo que publica el índice de referencia consigue conducir ambos automóviles. Por alguna extraña posibilidad, su auto siempre gana, y todos los demás tienen que conformarse con "créanme, realmente conducía su automóvil tan rápido como podría".

Es fácil escribir un punto de referencia pobre que produce resultados que significan casi nada. Casi cualquier persona con un punto cercano a la habilidad necesaria para diseñar un punto de referencia que produce algo significativo, también tiene la habilidad de producir uno que le dará los resultados que ha decidido que quiere. De hecho, probablemente sea más fácil escribir código para producir un resultado específico que un código que realmente produzca resultados significativos.

Como dijo mi amigo James Kanze, "nunca confíes en un punto de referencia que no hayas falsificado".

Conclusión

No hay una respuesta simple. Estoy razonablemente seguro de que podría lanzar una moneda para elegir al ganador, luego elegir un número entre (digamos) 1 y 20 para el porcentaje por el que ganaría, y escribir algún código que se vea como un punto de referencia razonable y justo, y produjo esa conclusión inevitable (al menos en un procesador de destino, un procesador diferente podría cambiar el porcentaje un poco).

Como otros han señalado, para la mayoría del código, la velocidad es casi irrelevante. El corolario de eso (que es mucho más a menudo ignorado) es que en el pequeño código donde la velocidad sí importa, generalmente importa mucho . Al menos en mi experiencia, para el código donde realmente importa, C ++ es casi siempre el ganador. Definitivamente hay factores que favorecen a C #, pero en la práctica parecen estar superados por factores que favorecen a C ++. Sin duda, puede encontrar puntos de referencia que indiquen el resultado que elija, pero cuando escribe código real, casi siempre puede hacerlo más rápido en C ++ que en C #. Puede (o no) requerir más habilidad y / o esfuerzo para escribir, pero es prácticamente siempre posible.

Alrededor de 2005, dos expertos en rendimiento de MS de ambos lados de la cerca nativa / administrada intentaron responder la misma pregunta. Su método y proceso siguen siendo fascinantes y las conclusiones aún se mantienen hoy en día, y no conozco ningún intento mejor por dar una respuesta informada. Señalaron que una discusión de las posibles razones de las diferencias en el rendimiento es hipotética e inútil, y una verdadera discusión debe tener alguna base empírica para el impacto real de tales diferencias en el mundo real.

Entonces, el viejo y nuevo Raymond Chen y Rico Mariani establecieron las reglas para una competencia amistosa. Se eligió un diccionario chino / inglés como contexto de aplicación de juguete: lo suficientemente simple como para ser codificado como un proyecto secundario de pasatiempos, pero lo suficientemente complejo como para demostrar patrones de uso de datos no triviales. Las reglas comenzaron de manera simple: Raymond codificó una implementación directa de C ++, Rico lo migró a C # línea por línea , sin sofisticación alguna, y ambas implementaciones funcionaron como punto de referencia. Después, se produjeron varias iteraciones de optimizaciones.

Los detalles completos están aquí: 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14 , 15 , 16 .

Este diálogo de titanes es excepcionalmente educativo y recomiendo encarecidamente sumergirme en él, pero si le falta tiempo o paciencia, Jeff Atwood compiló muy bien los resultados :

Eventualmente, C ++ fue 2 veces más rápido, pero inicialmente fue 13 veces más lento.

Como Rico lo resume :

Entonces, ¿estoy avergonzado por mi aplastante derrota? Apenas. El código administrado logró un muy buen resultado para casi ningún esfuerzo. Para vencer a la versión administrada, Raymond tuvo que:
Escribe su propio archivo / io
Escribe su propia clase de cuerda
Escribe su propio asignador
Escribe su propio mapeo internacional
Por supuesto, utilizó bibliotecas disponibles de nivel inferior para hacer esto, pero eso aún requiere mucho trabajo. ¿Puedes llamar a lo que queda de un programa STL? No lo creo.

Esa es mi experiencia aún, 11 años y quién sabe cuántas versiones C # / C ++ después.

Eso no es una coincidencia, por supuesto, ya que estos dos idiomas logran espectacularmente sus objetivos de diseño muy diferentes. C # quiere ser usado donde el costo de desarrollo es la consideración principal (sigue siendo la mayoría del software), y C ++ brilla donde no ahorraría ningún gasto para exprimir hasta el último gramo de rendimiento de su máquina: juegos, algo-trading, data- centros, etc.

C # es más rápido que C ++. Más rápido para escribir Para tiempos de ejecución, nada supera a un generador de perfiles.

Pero C # no tiene tantas bibliotecas como C ++ puede interactuar fácilmente.

Y C # depende en gran medida de Windows ...

C ++ siempre tiene una ventaja para el rendimiento. Con C #, no consigo manejar la memoria y literalmente tengo toneladas de recursos disponibles para hacer mi trabajo.

Lo que necesita para cuestionarse es más acerca de cuál le ahorra tiempo. Ahora las máquinas son increíblemente potentes y la mayoría del código debe hacerse en un lenguaje que le permita obtener el máximo valor en el menor tiempo posible.

Si hay un procesamiento central que lleva demasiado tiempo en C #, entonces podrías construir un C ++ e interoperar para llegar a él con C #.

Deja de pensar en el rendimiento de tu código. Comience a construir valor.

La principal preocupación no sería la velocidad, sino la estabilidad en las versiones de Windows y las actualizaciones. Win32 es prácticamente inmune a las versiones de Windows, lo que lo hace muy estable.

Cuando se desmantelan los servidores y se migra el software, se produce mucha ansiedad en torno a cualquier cosa que use .Net y, por lo general, muchas versiones de .net de pánico, pero una aplicación Win32 creada hace 10 años simplemente sigue funcionando como si nada hubiera pasado.

Me he especializado en optimización durante aproximadamente 15 años, y reescribo código C ++ regularmente, haciendo un uso intensivo de los intrínsecos del compilador tanto como sea posible porque el rendimiento de C ++ a menudo no es ni cerca de lo que la CPU es capaz de hacer. El rendimiento de la memoria caché a menudo debe ser considerado. Se requieren muchas instrucciones matemáticas vectoriales para reemplazar el código estándar de punto flotante C ++. Se vuelve a escribir una gran cantidad de código STL y, a menudo, se ejecuta muchas veces más rápido. Las matemáticas y el código que hacen un uso intensivo de los datos se pueden reescribir con resultados espectaculares, a medida que la CPU se aproxima a su rendimiento óptimo.

Nada de esto es posible en C #. Para comparar su rendimiento relativo de #realrealidad # es realmente una pregunta asombrosamente ignorante. La pieza más rápida de código en C ++ será cuando cada instrucción de ensamblador se optimice para la tarea en mano, sin instrucciones innecesarias, en absoluto. Donde cada pieza de memoria se usa cuando es necesaria, y no se copia n veces porque eso es lo que requiere el diseño del lenguaje. Donde cada movimiento de memoria requerido funciona en armonía con el caché. Donde el algoritmo final no se puede mejorar, según los requisitos exactos de tiempo real, teniendo en cuenta la precisión y la funcionalidad.

Entonces se acercará a una solución óptima.

Comparar el C # con esta situación ideal es asombroso. C # no puede competir. De hecho, actualmente estoy escribiendo un montón de código C # (cuando digo reescribir me refiero a quitarlo y reemplazarlo por completo) porque ni siquiera está en la misma ciudad, y mucho menos en el parque de béisbol cuando se trata de levantar objetos pesados en tiempo real. actuación.

Entonces, por favor, deja de engañarte. C # es lento. Muerte lenta. Todo el software se está desacelerando, y C # está haciendo que esta velocidad empeore. Todo el software se ejecuta utilizando el ciclo de ejecución de búsqueda en el ensamblador (ya sabes, en la CPU). Usas 10 veces más instrucciones; va a ir 10 veces más lento. Paralizas el caché; va a ir aún más lento. Agregas recolección de basura a una pieza de software en tiempo real y, a menudo, te engañan al pensar que el código funciona "bien", solo quedan esos pocos momentos de vez en cuando cuando el código "va un poco lento por un tiempo".

Intente agregar un sistema de recolección de basura para codificar donde cada ciclo cuenta. Me pregunto si el software de comercialización del mercado de valores tiene recolección de basura (¿sabe usted - en el sistema que funciona con el nuevo cable submarino que costó $ 300 millones?). ¿Podemos ahorrar 300 milisegundos cada 2 segundos? ¿Qué pasa con el software de control de vuelo en el transbordador espacial? ¿Está bien el CG? ¿Qué hay de software de gestión del motor en vehículos de rendimiento? (Donde la victoria en una temporada puede valer millones).

La recolección de basura en tiempo real es una falla completa.

Entonces, no, enfáticamente, C ++ es mucho más rápido. C # es un salto hacia atrás.

No dejes que sea confuso!

Si se escribe una aplicación C # en el mejor de los casos y se escribe una aplicación C ++ en el mejor de los casos, la C ++ es más rápida.
Aquí hay muchas razones sobre por qué C ++ es más rápido que C # inherentemente, como C # usa una máquina virtual similar a JVM en Java. Básicamente, el lenguaje de nivel superior tiene menos rendimiento (si se usa en el mejor de los casos).
Si usted es un programador de C # profesional con experiencia, al igual que un programador de C ++ profesional con experiencia, desarrollar una aplicación con C # es mucho más fácil y rápido que C ++.

Muchas otras situaciones entre estas situaciones son posibles. Por ejemplo, puede escribir una aplicación C # y una aplicación C ++ para que la aplicación C # se ejecute más rápido que C ++.

Para elegir un idioma, debe tener en cuenta las circunstancias del proyecto y su tema. Para un proyecto comercial general, debe usar C #. Para un proyecto de alto rendimiento requerido como un proyecto de conversión de video o procesamiento de imágenes, debe elegir C ++.

Actualizar:

DE ACUERDO. Vamos a comparar algunas razones prácticas sobre por qué la mayor velocidad posible de C ++ es más que C #. Considere una buena aplicación escrita de C # y la misma versión de C ++:

C # usa una VM como capa intermedia para ejecutar la aplicación. Tiene sobrecarga.
AFAIK CLR no pudo optimizar todos los códigos C # en la máquina objetivo. La aplicación C ++ podría compilarse en la máquina de destino con más optimización.
En C #, la optimización más posible para el tiempo de ejecución significa la VM más rápida posible. VM tiene sobrecarga de todos modos.
C # es un lenguaje de nivel superior por lo que genera más líneas de código de programa para el proceso final. (Tenga en cuenta la diferencia entre una aplicación de ensamblaje y Ruby one! misma condición se encuentra entre C ++ y un lenguaje de nivel superior como C # / Java)

Si prefiere obtener más información en la práctica como experto, vea esto . Se trata de Java, pero también se aplica a C #.

Obtener una respuesta exacta a su pregunta no es realmente posible a menos que realice puntos de referencia en sistemas específicos. Sin embargo, sigue siendo interesante pensar en algunas diferencias fundamentales entre lenguajes de programación como C # y C ++.

Compilacion

La ejecución del código C # requiere un paso adicional donde el código está JIT. Con respecto al rendimiento que estará a favor de C ++. Además, el compilador JIT solo puede optimizar el código generado dentro de la unidad de código que está JIT (por ejemplo, un método) mientras que un compilador de C ++ puede optimizar a través de llamadas a métodos utilizando técnicas más agresivas.

Sin embargo, el compilador JIT puede optimizar el código de la máquina generado para que coincida estrechamente con el hardware subyacente, lo que le permite aprovechar las características de hardware adicionales, si es que existen. Que yo sepa, el compilador .NET JIT no hace eso, pero concientemente podría generar código diferente para Atom en comparación con las CPU Pentium.

Acceso a la memoria

La arquitectura recolectada de basura puede en muchos casos crear patrones de acceso de memoria más óptimos que el código estándar de C ++. Si el área de memoria utilizada para la primera generación es lo suficientemente pequeña, puede permanecer dentro de la memoria caché de la CPU aumentando el rendimiento. Si crea y destruye una gran cantidad de objetos pequeños, la sobrecarga de mantener el montón administrado puede ser menor que la requerida por el tiempo de ejecución de C ++. De nuevo, esto depende en gran medida de la aplicación. Un estudio Python de rendimiento demuestra que una aplicación Python administrada específica puede escalar mucho mejor que la versión compilada como resultado de patrones de acceso de memoria más óptimos.

Por cierto, las aplicaciones de tiempo crítico no están codificadas en C # o Java, principalmente debido a la incertidumbre de cuándo se realizará la recolección de basura.

En los tiempos modernos, la velocidad de aplicación o ejecución no es tan importante como antes. Los cronogramas de desarrollo, corrección y robustez son prioridades más altas. Una versión de alta velocidad de una aplicación no es buena si tiene muchos errores, se bloquea mucho o peor, pierde la oportunidad de llegar al mercado o ser desplegada.

Dado que los cronogramas de desarrollo son una prioridad, están surgiendo nuevos lenguajes que aceleran el desarrollo. C # es uno de estos. C # también ayuda a la corrección y robustez eliminando características de C ++ que causan problemas comunes: un ejemplo son los indicadores.

Las diferencias en la velocidad de ejecución de una aplicación desarrollada con C # y una desarrollada usando C ++ son insignificantes en la mayoría de las plataformas. Esto se debe al hecho de que los cuellos de botella de ejecución no dependen del idioma sino que generalmente dependen del sistema operativo o E / S. Por ejemplo, si C ++ realiza una función en 5 ms, pero C # usa 2 ms, y esperar datos tarda 2 segundos, el tiempo empleado en la función es insignificante en comparación con el tiempo de espera de los datos.

Elija el idioma que mejor se adapte a los desarrolladores, la plataforma y los proyectos. Trabajar hacia los objetivos de corrección, robustez y despliegue. La velocidad de una aplicación debe tratarse como un error: priorícela, compárela con otros errores y corrija según sea necesario.

Una mejor manera de verlo todo es más lento que C / C ++ porque abstrae en lugar de seguir el paradigma del palo y el barro. Se llama programación de sistemas por una razón, programa contra el grano o el metal desnudo. Hacerlo también te otorga velocidad que no puedes alcanzar con otros lenguajes como C # o Java. Pero las raíces de alas C tienen que ver con hacer las cosas de la manera difícil, por lo que en su mayoría va a escribir más código y pasar más tiempo depurándolo.

C también distingue entre mayúsculas y minúsculas, también los objetos en C ++ también siguen conjuntos de reglas estrictas. Por ejemplo, un cono de helado púrpura no puede ser igual a un cono de helado azul, aunque pueden ser conos, pueden no pertenecer necesariamente a la familia del cono y si se olvida de definir qué cono se interrumpe. Por lo tanto, las propiedades del helado pueden ser clones o no. Ahora el argumento de la velocidad, C / C ++ utiliza el enfoque de pila y montón, aquí es donde el metal desnudo obtiene su metal.

Con la biblioteca de impulso, puede alcanzar velocidades increíbles, lamentablemente la mayoría de los estudios de juegos se adhieren a la biblioteca estándar. La otra razón para esto podría ser porque el software escrito en C / C ++ tiende a ser masivo en tamaño de archivo, ya que es una colección gigante de archivos en lugar de un solo archivo. También tenga en cuenta que todos los sistemas operativos están escritos en C, por lo que, en general, ¿por qué debemos preguntarnos qué podría ser más rápido?

Además, el almacenamiento en caché no es más rápido que la gestión de memoria pura, lo siento, pero esto simplemente no se despliega. La memoria es algo físico, el almacenamiento en caché es algo que hace el software para obtener una mejora en el rendimiento. También se podría razonar que sin memoria física el almacenamiento en caché simplemente no existiría. No anula el hecho de que la memoria debe ser gestionada en algún nivel, ya sea automática o manual.