Gran diferencia (x9) en el tiempo de ejecución entre código casi idéntico en C y C ++

Estaba intentando resolver este ejercicio de www.spoj.com: FCTRL - Factorial

Realmente no tienes que leerlo, solo hazlo si tienes curiosidad :)

Primero lo implementé en C ++ (aquí está mi solución):

#include <iostream>
using namespace std;

int main() {
    unsigned int num_of_inputs;
    unsigned int fact_num;
    unsigned int num_of_trailing_zeros;

    std::ios_base::sync_with_stdio(false); // turn off synchronization with the C library’s stdio buffers (from https://stackoverflow.com/a/22225421/5218277)

    cin >> num_of_inputs;

    while (num_of_inputs--)
    {
        cin >> fact_num;

        num_of_trailing_zeros = 0;

        for (unsigned int fives = 5; fives <= fact_num; fives *= 5)
            num_of_trailing_zeros += fact_num/fives;

        cout << num_of_trailing_zeros << "\n";
    }

    return 0;
}

Lo cargué como la solución para g ++ 5.1

El resultado fue: Tiempo 0,18 Mem 3,3 M

Pero luego vi algunos comentarios que afirmaban que su tiempo de ejecución era inferior a 0,1. Como no podía pensar en un algoritmo más rápido, intenté implementar el mismo código en C :

#include <stdio.h>

int main() {
    unsigned int num_of_inputs;
    unsigned int fact_num;
    unsigned int num_of_trailing_zeros;

    scanf("%d", &num_of_inputs);

    while (num_of_inputs--)
    {
        scanf("%d", &fact_num);

        num_of_trailing_zeros = 0;

        for (unsigned int fives = 5; fives <= fact_num; fives *= 5)
            num_of_trailing_zeros += fact_num/fives;

        printf("%d", num_of_trailing_zeros);
        printf("%s","\n");
    }

    return 0;
}

Lo cargué como solución para gcc 5.1

Esta vez el resultado fue: Tiempo 0.02 Mem 2.1M

Ahora el código es casi el mismo , agregué std::ios_base::sync_with_stdio(false);al código C ++ como se sugirió aquí para desactivar la sincronización con los búferes stdio de la biblioteca C. También he dividido la printf("%d\n", num_of_trailing_zeros);que printf("%d", num_of_trailing_zeros); printf("%s","\n");para compensar doble llamada de operator<<en cout << num_of_trailing_zeros << "\n";.

Pero todavía vi un mejor rendimiento x9 y un menor uso de memoria en el código C frente a C ++.

¿Porqué es eso?

EDITAR

Me fijo unsigned longa unsigned inten el código C. Debería haber sido así unsigned inty los resultados que se muestran arriba están relacionados con la unsigned intversión new ( ).

Ambos programas hacen exactamente lo mismo. Utilizan exactamente el mismo algoritmo y, dada su baja complejidad, su rendimiento está vinculado principalmente a la eficiencia del manejo de entrada y salida.

escanear la entrada con scanf("%d", &fact_num);un lado y cin >> fact_num;el otro no parece muy costoso de ninguna manera. De hecho, debería ser menos costoso en C ++, ya que el tipo de conversión se conoce en tiempo de compilación y el compilador de C ++ puede invocar directamente el analizador correcto. Lo mismo ocurre con la salida. Incluso se asegura de escribir una llamada separada para printf("%s","\n");, pero el compilador de C es lo suficientemente bueno como para compilar esto como una llamada a putchar('\n');.

Entonces, considerando la complejidad tanto de la E / S como del cálculo, la versión C ++ debería ser más rápida que la versión C.

La desactivación completa del almacenamiento en búfer stdoutralentiza la implementación de C a algo incluso más lento que la versión de C ++. Otra prueba de AlexLop con un fflush(stdout);después de la última printfarroja un rendimiento similar al de la versión C ++. No es tan lento como deshabilitar completamente el almacenamiento en búfer porque la salida se escribe en el sistema en pequeños fragmentos en lugar de un byte a la vez.

Esto parece apuntar a un comportamiento específico en su biblioteca C ++: sospecho que la implementación de su sistema de ciny coutdescarga la salida coutcuando se solicita la entrada cin. Algunas bibliotecas de C también hacen esto, pero generalmente solo cuando se lee / escribe desde y hacia la terminal. La evaluación comparativa realizada por el sitio www.spoj.com probablemente redirige la entrada y salida hacia y desde archivos.

AlexLop hizo otra prueba: leer todas las entradas a la vez en un vector y luego calcular y escribir toda la salida ayuda a comprender por qué la versión C ++ es mucho más lenta. Aumenta el rendimiento al de la versión C, esto prueba mi punto y elimina las sospechas sobre el código de formato C ++.

Otra prueba de Blastfurnace, que almacena todas las salidas en una std::ostringstreamy la descarga de una sola vez al final, mejora el rendimiento de C ++ al de la versión básica de C. QED.

El entrelazado de entrada ciny salida coutparece causar un manejo de E / S muy ineficiente, anulando el esquema de almacenamiento en búfer de flujo. reduciendo el rendimiento por un factor de 10.

PD: su algoritmo es incorrecto fact_num >= UINT_MAX / 5porque fives *= 5se desbordará y se ajustará antes de que se convierta > fact_num. Puede corregir esto haciendo fivesun unsigned longo un unsigned long longsi uno de estos tipos es mayor que unsigned int. También se usa %ucomo scanfformato. Tienes suerte de que los chicos de www.spoj.com no sean demasiado estrictos en sus puntos de referencia.

EDITAR: Como se explica más adelante por vitaux, este comportamiento es de hecho obligatorio por el estándar C ++. cinestá vinculado coutde forma predeterminada. Una operación de entrada cinpara la que el búfer de entrada necesita rellenarse hará coutque se vacíe la salida pendiente. En la implementación del OP, cinparece vaciar coutsistemáticamente, lo cual es un poco excesivo y visiblemente ineficiente.

Ilya Popov proporcionó una solución simple para esto: cinse puede desatar coutlanzando otro hechizo mágico además de std::ios_base::sync_with_stdio(false);:

cin.tie(nullptr);

También tenga en cuenta que tal descarga forzada también ocurre cuando se usa en std::endllugar de '\n'producir un final de línea encendido cout. Cambiar la línea de salida a una apariencia cout << num_of_trailing_zeros << endl;más idiomática e inocente de C ++ degradaría el rendimiento de la misma manera.

Otro truco para hacer iostreams más rápido cuando usas ambos ciny coutes llamar

cin.tie(nullptr);

De forma predeterminada, cuando ingresa algo de cin, se vacía cout. Puede dañar significativamente el rendimiento si realiza entradas y salidas intercaladas. Esto se hace para los usos de la interfaz de línea de comandos, donde muestra un mensaje y luego espera los datos:

std::string name;
cout << "Enter your name:";
cin >> name;

En este caso, desea asegurarse de que el mensaje se muestre realmente antes de comenzar a esperar la entrada. Con la línea de arriba rompes ese lazo ciny te vuelves coutindependiente.

Desde C ++ 11, una forma más de lograr un mejor rendimiento con iostreams es usar std::getlinejunto con std::stoi, así:

std::string line;
for (int i = 0; i < n && std::getline(std::cin, line); ++i)
{
    int x = std::stoi(line);
}

De esta manera puede acercarse al estilo C en rendimiento, o incluso superarlo scanf. El uso de getchary especialmente getchar_unlockedjunto con el análisis escrito a mano todavía proporciona un mejor rendimiento.

PD. He escrito una publicación comparando varias formas de ingresar números en C ++, útil para jueces en línea, pero solo está en ruso, lo siento. Sin embargo, las muestras de código y la mesa final deberían ser comprensibles.

El problema es que, citando cppreference :

cualquier entrada desde std :: cin, salida a std :: cerr o la terminación del programa fuerza una llamada a std :: cout.flush ()

Esto es fácil de probar: si reemplaza

cin >> fact_num;

con

scanf("%d", &fact_num);

y lo mismo para, cin >> num_of_inputspero mantenga cout, obtendrá prácticamente el mismo rendimiento en su versión C ++ (o, mejor dicho, versión IOStream) que en C uno:

Lo mismo sucede si mantiene cinpero reemplaza

cout << num_of_trailing_zeros << "\n";

con

printf("%d", num_of_trailing_zeros);
printf("%s","\n");

Una solución simple es desatar couty cincomo lo menciona Ilya Popov:

cin.tie(nullptr);

Las implementaciones de bibliotecas estándar pueden omitir la llamada a flush en ciertos casos, pero no siempre. Aquí hay una cita de C ++ 14 27.7.2.1.3 (gracias a chqrlie):

Clase basic_istream :: sentry: Primero, si is.tie () no es un puntero nulo, la función llama a is.tie () -> flush () para sincronizar la secuencia de salida con cualquier flujo C externo asociado. Excepto que esta llamada se puede suprimir si el área de colocación de is.tie () está vacía. Además, se permite una implementación para diferir la llamada a flush hasta que se produzca una llamada a is.rdbuf () -> underflow (). Si no se produce dicha llamada antes de que se destruya el objeto centinela, la llamada a flush puede eliminarse por completo.