¿Cuánto más rápido es C ++ que C #?

¿O es ahora al revés?

Por lo que he escuchado, hay algunas áreas en las que C # demuestra ser más rápido que C ++, pero nunca he tenido las agallas para probarlo por mí mismo.

Pensé que alguno de ustedes podría explicar estas diferencias en detalle o señalarme el lugar correcto para obtener información al respecto.

No hay una razón estricta por la cual un lenguaje basado en bytecode como C # o Java que tiene un JIT no pueda ser tan rápido como el código C ++. Sin embargo, el código C ++ solía ser significativamente más rápido durante mucho tiempo, y hoy en día todavía lo es en muchos casos. Esto se debe principalmente a que las optimizaciones JIT más avanzadas son complicadas de implementar, y las realmente geniales solo están llegando en este momento.

Entonces C ++ es más rápido, en muchos casos. Pero esto es solo una parte de la respuesta. Los casos en que C ++ es en realidad más rápido son programas altamente optimizados, donde los programadores expertos optimizan a fondo el código. Esto no solo consume mucho tiempo (y, por lo tanto, es costoso), sino que también conduce a errores debido a una optimización excesiva.

Por otro lado, el código en lenguajes interpretados se acelera en versiones posteriores del tiempo de ejecución (.NET CLR o Java VM), sin que usted haga nada. Y hay muchas optimizaciones útiles que los compiladores JIT pueden hacer que son simplemente imposibles en idiomas con punteros. Además, algunos argumentan que la recolección de basura generalmente debe ser tan rápida o más rápida como la administración manual de memoria, y en muchos casos lo es. En general, puede implementar y lograr todo esto en C ++ o C, pero será mucho más complicado y propenso a errores.

Como dijo Donald Knuth, "la optimización prematura es la raíz de todo mal". Si realmente sabe con certeza que su aplicación consistirá principalmente en aritmética muy crítica de rendimiento, y que será el cuello de botella, y ciertamente será más rápido en C ++, y está seguro de que C ++ no entrará en conflicto con su otro requisitos, vaya para C ++. En cualquier otro caso, concéntrese primero en implementar su aplicación correctamente en el idioma que más le convenga, luego encuentre cuellos de botella de rendimiento si funciona demasiado lento y luego piense en cómo optimizar el código. En el peor de los casos, es posible que deba llamar al código C a través de una interfaz de función externa, por lo que aún tendrá la capacidad de escribir partes críticas en un lenguaje de nivel inferior.

Tenga en cuenta que es relativamente fácil optimizar un programa correcto, pero mucho más difícil corregir un programa optimizado.

Es imposible dar porcentajes reales de ventajas de velocidad, depende en gran medida de su código. En muchos casos, la implementación del lenguaje de programación ni siquiera es el cuello de botella. Tome los puntos de referencia en http://benchmarksgame.alioth.debian.org/ con mucho escepticismo, ya que estos prueban en gran medida el código aritmético, que probablemente no sea similar a su código.

C # puede no ser más rápido, pero te hace a TI / ME más rápido. Esa es la medida más importante para lo que hago. :)

Son cinco naranjas más rápido. O más bien: no puede haber una respuesta general (correcta). C ++ es un lenguaje compilado estáticamente (pero también hay una optimización guiada por perfil), C # se ejecuta con la ayuda de un compilador JIT. Hay tantas diferencias que preguntas como "cuánto más rápido" no se pueden responder, ni siquiera dando órdenes de magnitud.

Comenzaré por estar en desacuerdo con parte de la respuesta aceptada (y bien votada) a esta pregunta al afirmar:

En realidad, hay muchas razones por las cuales el código JITted se ejecutará más lentamente que un programa C ++ (u otro lenguaje sin sobrecarga de tiempo de ejecución) correctamente optimizado, incluyendo:

• los ciclos de cálculo gastados en el código JITting en tiempo de ejecución no están, por definición, disponibles para su uso en la ejecución del programa.

• cualquier ruta activa en el JITter estará compitiendo con su código por instrucciones y caché de datos en la CPU. Sabemos que el caché domina cuando se trata de rendimiento y los lenguajes nativos como C ++ no tienen este tipo de contención, por definición.

• El presupuesto de tiempo de un optimizador de tiempo de ejecución está necesariamente mucho más limitado que el de un optimizador de tiempo de compilación (como señaló otro comentarista)

En pocas palabras: En última instancia, será casi seguro que será capaz de crear una implementación más rápida en C ++ de lo que podía en C # .

Ahora, dicho esto, cuánto más rápido realmente no es cuantificable, ya que hay demasiadas variables: la tarea, el dominio del problema, el hardware, la calidad de las implementaciones y muchos otros factores. Deberá realizar pruebas en su escenario para determinar la diferencia en el rendimiento y luego decidir si vale la pena el esfuerzo y la complejidad adicionales.

Este es un tema muy largo y complejo, pero creo que vale la pena mencionar, en aras de la exhaustividad, que el optimizador de tiempo de ejecución de C # es excelente y es capaz de realizar ciertas optimizaciones dinámicas en tiempo de ejecución que simplemente no están disponibles para C ++ con su tiempo de compilación ( estático) optimizador. Incluso con esto, la ventaja sigue siendo típicamente profunda en la corte de la aplicación nativa, pero el optimizador dinámico es la razón del calificador " casi seguro" dado anteriormente.

-

En términos de rendimiento relativo, también me perturbaron las cifras y las discusiones que vi en algunas otras respuestas, así que pensé en intervenir y, al mismo tiempo, brindar algo de apoyo para las declaraciones que hice anteriormente.

Una gran parte del problema con esos puntos de referencia es que no puede escribir código C ++ como si estuviera escribiendo C # y esperar obtener resultados representativos (por ejemplo, realizar miles de asignaciones de memoria en C ++ le dará números terribles).

En cambio, escribí un código C ++ un poco más idiomático y lo comparé con el código C # que @Wiory proporcionó. Los dos cambios principales que hice al código C ++ fueron:

1) vector usado :: reserve ()

2) aplanó la matriz 2d a 1d para lograr una mejor ubicación de caché (bloque contiguo)

C # (.NET 4.6.1)

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);
}

Tiempo de ejecución (lanzamiento): Init: 124ms, Fill: 165ms

C ++ 14 (Clang v3.8 / C2)

#include <iostream>
#include <vector>

auto TestSuite::ColMajorArray()
{
    constexpr size_t ROWS = 5000;
    constexpr size_t COLS = 9000;

    auto initStart = std::chrono::steady_clock::now();

    auto arr = std::vector<double>();
    arr.reserve(ROWS * COLS);

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);

    auto fillStart = std::chrono::steady_clock::now();

    for(auto i = 0, r = 0; r < ROWS; ++r)
    {
        for (auto c = 0; c < COLS; ++c)
        {
            arr[i++] = static_cast<double>(r * c);
        }
    }

    auto fillFinish = std::chrono::steady_clock::now();
    auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);

    return std::make_pair(initTime, fillTime);
}

Tiempo de ejecución (Release): Init: 398µs (sí, eso es microsegundos), Fill: 152ms

Tiempo total de ejecución: C #: 289 ms, C ++ 152 ms (aproximadamente 90% más rápido)

Observaciones

• Cambiar la implementación de C # a la misma implementación de matriz 1d produjo Init: 40ms, Fill: 171ms, Total: 211ms ( C ++ todavía era casi un 40% más rápido ).

• Es mucho más difícil diseñar y escribir código "rápido" en C ++ que escribir código "regular" en cualquier idioma.

• Es (quizás) asombrosamente fácil obtener un bajo rendimiento en C ++; vimos eso con el rendimiento de vectores sin reservas. Y hay muchas trampas como esta.

• El rendimiento de C # es bastante sorprendente si se considera todo lo que sucede en tiempo de ejecución. Y ese rendimiento es relativamente fácil de acceder.

• Más datos anecdóticos que comparan el rendimiento de C ++ y C #: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore

La conclusión es que C ++ le brinda mucho más control sobre el rendimiento. ¿Quieres usar un puntero? ¿Una referencia? ¿Pila de memoria? ¿Montón? ¿Polimorfismo dinámico o eliminar la sobrecarga de tiempo de ejecución de una tabla virtual con polimorfismo estático (a través de plantillas / CRTP)? En C ++ que tiene que ... er, llegar a realizar todas estas opciones (y más) a sí mismo, a ser posible para que sus soluciones mejores direcciones el problema que está abordaje.

Pregúntese si realmente desea o necesita ese control, porque incluso para el ejemplo trivial anterior, puede ver que aunque hay una mejora significativa en el rendimiento, requiere una inversión más profunda para acceder.

En mi experiencia (y he trabajado mucho con ambos lenguajes), el principal problema con C # en comparación con C ++ es el alto consumo de memoria, y no he encontrado una buena manera de controlarlo. Fue el consumo de memoria lo que eventualmente ralentizaría el software .NET.

Otro factor es que el compilador JIT no puede permitirse demasiado tiempo para realizar optimizaciones avanzadas, ya que se ejecuta en tiempo de ejecución, y el usuario final lo notaría si lleva demasiado tiempo. Por otro lado, un compilador de C ++ tiene todo el tiempo que necesita para hacer optimizaciones en tiempo de compilación. Este factor es mucho menos significativo que el consumo de memoria, en mi humilde opinión.

Un escenario particular donde C ++ todavía tiene la ventaja (y lo hará, en los próximos años) ocurre cuando las decisiones polimórficas pueden predeterminarse en el momento de la compilación.

En general, la encapsulación y la toma de decisiones diferidas es algo bueno porque hace que el código sea más dinámico, más fácil de adaptar a los requisitos cambiantes y más fácil de usar como marco. Es por eso que la programación orientada a objetos en C # es muy productiva y puede generalizarse bajo el término "generalización". Desafortunadamente, este tipo particular de generalización tiene un costo en tiempo de ejecución.

Por lo general, este costo no es sustancial, pero hay aplicaciones en las que la sobrecarga de las llamadas a métodos virtuales y la creación de objetos pueden marcar la diferencia (especialmente porque los métodos virtuales impiden otras optimizaciones, como la inserción de llamadas a métodos). Aquí es donde C ++ tiene una gran ventaja porque puede usar plantillas para lograr un tipo diferente de generalización que no tiene impacto en el tiempo de ejecución pero no es necesariamente menos polimórfico que OOP. De hecho, todos los mecanismos que constituyen la OOP se pueden modelar utilizando solo técnicas de plantilla y resolución en tiempo de compilación.

En tales casos (y es cierto que a menudo están restringidos a dominios con problemas especiales), C ++ gana contra C # y lenguajes comparables.

C ++ (o C para el caso) le brinda un control detallado sobre sus estructuras de datos. Si quieres jugar un poco, tienes esa opción. Las grandes aplicaciones Java o .NET administradas (OWB, Visual Studio 2005 ) que usan las estructuras de datos internas de las bibliotecas Java / .NET llevan el equipaje con ellas. He visto que las sesiones de diseño de OWB usan más de 400 MB de RAM y BIDS para el diseño de cubos o ETL llegando también a los cientos de MB.

En una carga de trabajo predecible (como la mayoría de los puntos de referencia que repiten un proceso muchas veces), un JIT puede obtener un código que esté optimizado lo suficientemente bien como para que no haya una diferencia práctica.

OMI en aplicaciones grandes, la diferencia no es tanto el JIT como las estructuras de datos que el código en sí está utilizando. Cuando una aplicación tiene mucha memoria, obtendrá un uso de caché menos eficiente. Los errores de caché en las CPU modernas son bastante caros. Donde C o C ++ realmente ganan es donde puede optimizar su uso de estructuras de datos para jugar bien con el caché de la CPU.

Para los gráficos, la clase de gráficos estándar de C # es mucho más lenta que GDI al que se accede a través de C / C ++. Sé que esto no tiene nada que ver con el lenguaje per se, más con la plataforma .NET total, pero Graphics es lo que se ofrece al desarrollador como reemplazo de GDI, y su rendimiento es tan malo que ni siquiera me atrevería a hacer gráficos. con eso.

Tenemos un punto de referencia simple que usamos para ver qué tan rápida es una biblioteca de gráficos, y eso es simplemente dibujar líneas aleatorias en una ventana. C ++ / GDI sigue siendo ágil con 10000 líneas, mientras que C # / Graphics tiene dificultades para hacer 1000 en tiempo real.

La recolección de basura es la razón principal por la que Java # NO PUEDE usarse para sistemas en tiempo real.

1. ¿Cuándo ocurrirá el GC?

2. ¿Cuánto tiempo tardará?

Esto no es determinista.

Hemos tenido que determinar si C # era comparable a C ++ en rendimiento y escribí algunos programas de prueba para eso (usando Visual Studio 2005 para ambos idiomas). Resultó que sin recolección de basura y solo considerando el lenguaje (no el marco) C # tiene básicamente el mismo rendimiento que C ++. La asignación de memoria es mucho más rápida en C # que en C ++ y C # tiene una ligera ventaja en el determinismo cuando los tamaños de datos aumentan más allá de los límites de la línea de caché. Sin embargo, todo esto finalmente tuvo que pagarse y hay un costo enorme en forma de resultados de rendimiento no deterministas para C # debido a la recolección de basura.

Como de costumbre, depende de la aplicación. Hay casos en los que C # es probablemente mucho más lento, y otros casos en los que C ++ es 5 o 10 veces más rápido, especialmente en los casos en que las operaciones se pueden SIMD'd fácilmente.

Sé que no es lo que estabas preguntando, pero C # a menudo es más rápido de escribir que C ++, lo cual es una gran ventaja en un entorno comercial.

C / C ++ puede funcionar mucho mejor en programas en los que hay matrices grandes o bucles / iteraciones pesadas sobre matrices (de cualquier tamaño). Esta es la razón por la que los gráficos son generalmente mucho más rápidos en C / C ++, porque las operaciones de matriz pesadas subyacen en casi todas las operaciones de gráficos. .NET es notoriamente lento en las operaciones de indexación de matrices debido a todas las comprobaciones de seguridad, y esto es especialmente cierto para las matrices multidimensionales (y, sí, las matrices rectangulares C # son incluso más lentas que las matrices irregulares C #).

Las bonificaciones de C / C ++ son más pronunciadas si se adhiere directamente a los punteros y evita Boost std::vectory otros contenedores de alto nivel, así como inlinetodas las funciones pequeñas posibles. Use matrices de la vieja escuela siempre que sea posible. Sí, necesitará más líneas de código para lograr lo mismo que hizo en Java o C # ya que evita los contenedores de alto nivel. Si necesita una matriz de tamaño dinámico, solo tendrá que recordar emparejarla new T[]con una delete[]instrucción correspondiente (o usarstd::unique_ptr): El precio de la velocidad adicional es que debe codificar con más cuidado. Pero a cambio, puede deshacerse de la sobrecarga de la memoria administrada / recolector de basura, que puede ser fácilmente el 20% o más del tiempo de ejecución de programas orientados a objetos en Java y .NET, así como aquellos administrados masivamente costos de indexación de matriz de memoria. Las aplicaciones de C ++ también pueden beneficiarse de algunos cambios ingeniosos del compilador en ciertos casos específicos.

Soy un programador experto en C, C ++, Java y C #. Recientemente tuve la rara ocasión de implementar exactamente el mismo programa algorítmico en los últimos 3 idiomas. El programa tenía muchas operaciones matemáticas y de matriz multidimensional. Lo optimicé mucho en los 3 idiomas. Los resultados fueron típicos de lo que normalmente veo en comparaciones menos rigurosas: Java fue aproximadamente 1.3 veces más rápido que C # (la mayoría de las JVM están más optimizadas que el CLR), y la versión de puntero sin formato de C ++ llegó aproximadamente 2.1 veces más rápido que C #. Tenga en cuenta que el programa C # solo usó código seguro; en mi opinión, también podría codificarlo en C ++ antes de usar la unsafepalabra clave.

Para que nadie piense que tengo algo en contra de C #, terminaré diciendo que C # es probablemente mi lenguaje favorito. Es el lenguaje de desarrollo más lógico, intuitivo y rápido que he encontrado hasta ahora. Hago todos mis prototipos en C #. El lenguaje C # tiene muchas ventajas pequeñas y sutiles sobre Java (sí, sé que Microsoft tuvo la oportunidad de corregir muchas de las deficiencias de Java entrando tarde al juego y posiblemente copiando Java). Brindis por la Calendarclase de Java a alguien? Si Microsoft alguna vez gasta un esfuerzo real para optimizar el CLR y el .NET JITter, C # podría hacerse cargo en serio. Estoy sinceramente sorprendido de que aún no lo hayan hecho: hicieron tantas cosas bien en el lenguaje C #, ¿por qué no seguir con optimizaciones de compilación impactantes? Quizás si todos suplicamos.

> Por lo que he escuchado ...

Su dificultad parece ser decidir si lo que ha escuchado es creíble, y esa dificultad solo se repetirá cuando intente evaluar las respuestas en este sitio.

¿Cómo va a decidir si las cosas que la gente dice aquí son más o menos creíbles de lo que escuchó originalmente?

Una forma sería pedir evidencia .

Cuando alguien dice "hay algunas áreas en las que C # demuestra ser más rápido que C ++", pregúnteles por qué dicen eso , pídales que le muestren medidas, pídales que le muestren programas. A veces simplemente habrán cometido un error. A veces descubrirás que solo están expresando una opinión en lugar de compartir algo que pueden demostrar que es verdad.

A menudo, la información y la opinión se mezclarán en lo que la gente dice, y tendrá que intentar resolver cuál es cuál. Por ejemplo, de las respuestas en este foro:

• "Tome los puntos de referencia en http://shootout.alioth.debian.org/ con mucho escepticismo, ya que estos prueban en gran medida el código aritmético, que probablemente no sea similar a su código".

  Pregúntese si realmente comprende lo que significa "estos códigos aritméticos en gran medida de prueba" , y luego pregúntese si el autor realmente le ha demostrado que su afirmación es cierta.

• "Esa es una prueba bastante inútil, ya que realmente depende de qué tan bien se hayan optimizado los programas individuales; he logrado acelerar algunos de ellos de 4 a 6 veces o más, dejando en claro que la comparación entre programas no optimizados es bastante tonto."

  Pregúntese si el autor realmente le ha demostrado que ha logrado "acelerar algunos de ellos de 4 a 6 veces o más". ¡Es un reclamo fácil de hacer!

Para problemas 'vergonzosamente paralelos', cuando utilizo Intel TBB y OpenMP en C ++, he observado un aumento de rendimiento de aproximadamente 10 veces en comparación con problemas similares (matemáticos puros) realizados con C # y TPL. SIMD es un área donde C # no puede competir, pero también tuve la impresión de que TPL tiene una sobrecarga considerable.

Dicho esto, solo uso C ++ para tareas críticas de rendimiento en las que sé que podré realizar múltiples subprocesos y obtener resultados rápidamente. Para todo lo demás, C # (y ocasionalmente F #) está bien.

Es una pregunta extremadamente vaga sin respuestas definitivas reales.

Por ejemplo; Prefiero jugar juegos en 3D creados en C ++ que en C #, porque el rendimiento es mucho mejor. (Y sé XNA, etc., pero no se acerca de verdad).

Por otro lado, como se mencionó anteriormente; debe desarrollarse en un lenguaje que le permita hacer lo que quiera rápidamente y, si es necesario, optimizarlo.

Los lenguajes .NET pueden ser tan rápidos como el código C ++, o incluso más rápido, pero el código C ++ tendrá un rendimiento más constante ya que el tiempo de ejecución .NET tiene que pausar para GC , incluso si es muy inteligente sobre sus pausas.

Entonces, si tiene algún código que debe ejecutarse constantemente de manera rápida y sin pausa, .NET introducirá latencia en algún momento , incluso si tiene mucho cuidado con el tiempo de ejecución GC.

En teoría, para una aplicación de tipo servidor de larga ejecución, un lenguaje compilado JIT puede ser mucho más rápido que una contraparte compilada de forma nativa. Dado que el lenguaje compilado JIT generalmente se compila primero en un lenguaje intermedio de nivel bastante bajo, de todos modos puede hacer muchas optimizaciones de alto nivel en el momento de la compilación. La gran ventaja es que el JIT puede continuar compilando secciones de código sobre la marcha a medida que obtiene más y más datos sobre cómo se usa la aplicación. Puede organizar las rutas de código más comunes para permitir que la predicción de bifurcación tenga éxito con la mayor frecuencia posible. Puede reorganizar bloques de código separados que a menudo se unen para mantenerlos a ambos en la memoria caché. Puede gastar más esfuerzo optimizando los bucles internos.

Dudo que esto sea hecho por .NET o cualquiera de los JRE, pero estaba siendo investigado cuando estaba en la universidad, por lo que no es irrazonable pensar que este tipo de cosas puedan llegar al mundo real en algún momento pronto .

Aplicaciones que requieren acceso intensivo a la memoria, por ejemplo. la manipulación de imágenes suele estar mejor escrita en un entorno no administrado (C ++) que administrada (C #). Los lazos internos optimizados con aritmética de puntero son mucho más fáciles de controlar en C ++. En C #, es posible que deba recurrir a un código inseguro para incluso acercarse al mismo rendimiento.

Lo probé vectoren C ++ y C # equivalente, Listy en matrices 2d simples.

Estoy usando las ediciones Express de Visual C # / C ++ 2010. Ambos proyectos son simples aplicaciones de consola, las he probado en versión estándar (sin configuraciones personalizadas) y modo de depuración. Las listas de C # se ejecutan más rápido en mi PC, la inicialización de la matriz también es más rápida en C #, las operaciones matemáticas son más lentas.

Estoy usando Intel Core2Duo [email protected], C # - .NET 4.0.

Sé que la implementación de vectores es diferente de la lista C #, pero solo quería probar las colecciones que usaría para almacenar mis objetos (y poder usar el descriptor de acceso).

Por supuesto, necesita borrar la memoria (digamos para cada uso de new), pero quería mantener el código simple.

Prueba de vectores C ++ :

static void TestVector()
{
    clock_t start,finish;
    start=clock();
    vector<vector<double>> myList=vector<vector<double>>();
    int i=0;
    for( i=0; i<500; i++)
    {
        myList.push_back(vector<double>());
        for(int j=0;j<50000;j++)
            myList[i].push_back(j+i);
    }
    finish=clock();
    cout<<(finish-start)<<endl;
    cout<<(double(finish - start)/CLOCKS_PER_SEC);
}

Prueba de lista de C #:

private static void TestVector()
{

    DateTime t1 = System.DateTime.Now;
    List<List<double>> myList = new List<List<double>>();
    int i = 0;
    for (i = 0; i < 500; i++)
    {
        myList.Add(new List<double>());
        for (int j = 0; j < 50000; j++)
            myList[i].Add(j *i);
    }
    DateTime t2 = System.DateTime.Now;
    Console.WriteLine(t2 - t1);
}

C ++ - matriz:

static void TestArray()
{
    cout << "Normal array test:" << endl;
    const int rows = 5000;
    const int columns = 9000;
    clock_t start, finish;

    start = clock();
    double** arr = new double*[rows];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    finish = clock();

    cout << (finish - start) << endl;

    start = clock();
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    finish = clock();

    cout << (finish - start) << endl;
}

C # - matriz:

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

}

Hora: (lanzamiento / depuración)

C ++

• 600/606 ms de inicio de matriz,
• 200/270 ms relleno de matriz,
• 1sec / 13sec vector init & fill.

(Sí, 13 segundos, siempre tengo problemas con las listas / vectores en modo de depuración).

C#:

• 20/20 ms de inicio de matriz,
• Relleno de matriz de 403/440 ms,
• 710/742 ms lista de inicio y relleno.

Bueno, eso depende. Si el código de bytes se traduce en código de máquina (y no solo JIT) (quiero decir, si ejecuta el programa) y si su programa usa muchas asignaciones / desasignaciones, podría ser más rápido porque el algoritmo GC solo necesita una pasada (en teoría) a través de toda la memoria una vez, pero las llamadas normales de malloc / realloc / free C / C ++ provocan una sobrecarga en cada llamada (sobrecarga de llamada, sobrecarga de estructura de datos, errores de caché;)).

Por lo tanto, es teóricamente posible (también para otros lenguajes GC).

Realmente no veo la desventaja extrema de no poder usar la metaprogramación con C # para la mayoría de las aplicaciones, porque la mayoría de los programadores no la usan de todos modos.

Otra gran ventaja es que el SQL, como la "extensión" LINQ , brinda oportunidades para que el compilador optimice las llamadas a las bases de datos (en otras palabras, el compilador podría compilar todo el LINQ en un binario "blob" donde las funciones llamadas están en línea o para su uso optimizado, pero estoy especulando aquí).

Supongo que hay aplicaciones escritas en C # que se ejecutan rápidamente, así como también hay más aplicaciones escritas en C ++ que se ejecutan rápidamente (bueno, C ++ es más antiguo ... y también toman UNIX ...)
. La pregunta es: ¿qué es esa cosa, usuarios? y los desarrolladores se quejan de ...
Bueno, en mi humilde opinión, en el caso de C # tenemos una interfaz de usuario muy cómoda, una jerarquía de bibliotecas muy agradable y un sistema de interfaz completo de CLI. En el caso de C ++, tenemos plantillas, ATL, COM, MFC y todo el código de código escrito y en ejecución como OpenGL, DirectX, etc. en un segundo: ¡bang !, está atascado).
Escribir código en C # muy simple y rápido (sin olvidar que también aumenta la posibilidad de errores. En el caso de C ++, los desarrolladores se quejan de pérdidas de memoria, - significa aplastamientos, llamadas entre archivos DLL, así como de "infierno de DLL" - problema con soporte y bibliotecas de reemplazo por las más nuevas ...
Creo que cuanta más habilidad tenga en el lenguaje de programación, más calidad (y velocidad) caracterizará su software.

Lo diría de esta manera: los programadores que escriben código más rápido, son los que están más informados sobre lo que hace que las máquinas actuales funcionen rápido, y por cierto, también son los que usan una herramienta adecuada que permite un nivel bajo y determinista preciso Técnicas de optimización. Por estas razones, estas personas son las que usan C / C ++ en lugar de C #. Yo iría tan lejos como afirmar esto como un hecho.

Si no me equivoco, las plantillas de C # se determinan en tiempo de ejecución. Esto debe ser más lento que las plantillas de tiempo de compilación de C ++.

Y cuando toma todas las otras optimizaciones en tiempo de compilación mencionadas por muchos otros, así como la falta de seguridad que, de hecho, significa más velocidad ...

Yo diría que C ++ es la opción obvia en términos de velocidad bruta y consumo mínimo de memoria. Pero esto también se traduce en más tiempo desarrollando el código y asegurando que no está perdiendo memoria o causando excepciones de puntero nulo.

Veredicto:

• C #: desarrollo más rápido, ejecución más lenta

• C ++: desarrollo lento, ejecución más rápida.

Realmente depende de lo que intente lograr en su código. He oído que es solo una leyenda urbana que hay alguna diferencia de rendimiento entre VB.NET, C # y C ++ administrado. Sin embargo, he encontrado, al menos en las comparaciones de cadenas, que C ++ superó los pantalones de C #, que a su vez supera los pantalones de VB.NET.

De ninguna manera he hecho ninguna comparación exhaustiva en la complejidad algorítmica entre los idiomas. También estoy usando la configuración predeterminada en cada uno de los idiomas. En VB.NET estoy usando configuraciones para requerir la declaración de variables, etc. Aquí está el código que estoy usando para C ++ administrado: (Como puede ver, este código es bastante simple). Estoy ejecutando lo mismo en los otros idiomas en Visual Studio 2013 con .NET 4.6.2.

#include "stdafx.h"

using namespace System;
using namespace System::Diagnostics;

bool EqualMe(String^ first, String^ second)
{
    return first->Equals(second);
}
int main(array<String ^> ^args)
{
    Stopwatch^ sw = gcnew Stopwatch();
    sw->Start();
    for (int i = 0; i < 100000; i++)
    {
        EqualMe(L"one", L"two");
    }
    sw->Stop();
    Console::WriteLine(sw->ElapsedTicks);
    return 0;
}

Existen algunas diferencias importantes entre C # y C ++ en el aspecto del rendimiento:

• C # está basado en GC / montón. La asignación y el GC en sí son generales como la no localidad del acceso a la memoria
• Los optimizadores de C ++ se han vuelto muy buenos a lo largo de los años. Los compiladores JIT no pueden alcanzar el mismo nivel ya que solo tienen un tiempo de compilación limitado y no ven el alcance global

Además de eso, la competencia del programador también juega un papel. He visto un código C ++ incorrecto donde las clases se pasan por valor como argumento en todo el lugar. En realidad, puede empeorar el rendimiento en C ++ si no sabe lo que está haciendo.

> Después de todo, las respuestas tienen que estar en algún lado, ¿no? :)

Umm no.

Como se observó en varias respuestas, la pregunta está subespecificada en formas que invitan preguntas en respuesta, no respuestas. Para tomar solo un camino:

• la pregunta combina el lenguaje con la implementación del lenguaje: este programa C es 2.194 veces más lento y 1.17 veces más rápido que este programa C # . Tendríamos que preguntarle: ¿Qué implementaciones de lenguaje?

¿Y luego qué programas? Cual maquina Que sistema operativo ¿Qué conjunto de datos?

Inspirado por esto, hice una prueba rápida con el 60 por ciento de la instrucción común necesaria en la mayoría de los programas.

Aquí está el código C #:

for (int i=0; i<1000; i++)
{
    StreamReader str = new StreamReader("file.csv");
    StreamWriter stw = new StreamWriter("examp.csv");
    string strL = "";
    while((strL = str.ReadLine()) != null)
    {
        ArrayList al = new ArrayList();
        string[] strline = strL.Split(',');
        al.AddRange(strline);
        foreach(string str1 in strline)
        {
            stw.Write(str1 + ",");
        }
        stw.Write("\n");
    }
    str.Close();
    stw.Close();
}

La matriz de cadenas y la lista de matrices se usan a propósito para incluir esas instrucciones.

Aquí está el código c ++:

for (int i = 0; i<1000; i++)
{
    std::fstream file("file.csv", ios::in);
    if (!file.is_open())
    {
        std::cout << "File not found!\n";
        return 1;
    }

    ofstream myfile;
    myfile.open ("example.txt");
    std::string csvLine;

    while (std::getline(file, csvLine))
    {
        std::istringstream csvStream(csvLine);
        std::vector csvColumn;
        std::string csvElement;

        while( std::getline(csvStream, csvElement, ‘,’) )
        {
            csvColumn.push_back(csvElement);
        }

        for (std::vector::iterator j = csvColumn.begin(); j != csvColumn.end(); ++j)
        {
            myfile << *j << ", ";
        }

        csvColumn.clear();
        csvElement.clear();
        csvLine.clear();
        myfile << "\n";
    }
    myfile.close();
    file.close();
}

El tamaño del archivo de entrada que utilicé fue de 40 KB.

Y aquí está el resultado:

• El código C ++ se ejecutó en 9 segundos.
• Código C #: ¡4 segundos!

Oh, pero esto estaba en Linux ... Con C # ejecutándose Mono ... Y C ++ con g ++.

OK, esto es lo que obtuve en Windows - Visual Studio 2003 :

• El código C # se ejecutó en 9 segundos.
• Código C ++: ¡horrible 370 segundos!