Grande diferença (x9) no tempo de execução entre código quase idêntico em C e C ++

Estava a tentar resolver este exercício em www.spoj.com: FCTRL - Factorial

Você realmente não precisa ler, apenas faça se estiver curioso :)

Primeiro eu implementei em C ++ (aqui está minha solução):

#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;
}

Eu carreguei como a solução para g ++ 5.1

O resultado foi: Tempo 0,18 Mem 3,3M

Mas então eu vi alguns comentários que afirmavam que seu tempo de execução era inferior a 0,1. Como não conseguia pensar em um algoritmo mais rápido, tentei implementar o mesmo código em 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;
}

Eu carreguei como a solução para gcc 5.1

Desta vez, o resultado foi: Tempo 0,02 Mem 2,1M

Agora o código é quase o mesmo , adicionei std::ios_base::sync_with_stdio(false);ao código C ++ como foi sugerido aqui para desligar a sincronização com os buffers stdio da biblioteca C. Também divido o printf("%d\n", num_of_trailing_zeros);para printf("%d", num_of_trailing_zeros); printf("%s","\n");para compensar a dupla chamada de operator<<em cout << num_of_trailing_zeros << "\n";.

Mas eu ainda vi x9 melhor desempenho e menor uso de memória no código C vs. C ++.

Por que é que?

EDITAR

I fixo unsigned longpara unsigned into código C. Deveria ter sido unsigned inte os resultados mostrados acima estão relacionados à nova unsigned intversão ( ).

Ambos os programas fazem exatamente a mesma coisa. Eles usam o mesmo algoritmo exato e, devido à sua baixa complexidade, seu desempenho está principalmente vinculado à eficiência do tratamento de entrada e saída.

digitalizar a entrada scanf("%d", &fact_num);de um lado e cin >> fact_num;do outro não parece muito caro de qualquer maneira. Na verdade, deve ser menos caro em C ++, pois o tipo de conversão é conhecido no momento da compilação e o analisador correto pode ser chamado diretamente pelo compilador C ++. O mesmo vale para a saída. Você até faz questão de escrever uma chamada separada para printf("%s","\n");, mas o compilador C é bom o suficiente para compilar isso como uma chamada para putchar('\n');.

Portanto, olhando para a complexidade de E / S e computação, a versão C ++ deve ser mais rápida que a versão C.

Desativar completamente o buffer de stdoutretarda a implementação C para algo ainda mais lento do que a versão C ++. Outro teste por AlexLop com um fflush(stdout);após o último printfproduz um desempenho semelhante ao da versão C ++. Não é tão lento quanto desabilitar completamente o buffer porque a saída é gravada no sistema em pequenos pedaços, em vez de um byte por vez.

Isso parece apontar para um comportamento específico em sua biblioteca C ++: eu suspeito da implementação de seu sistema cine coutlibera a saída para coutquando a entrada é solicitada de cin. Algumas bibliotecas C também fazem isso, mas geralmente apenas ao ler / gravar de e para o terminal. O benchmarking feito pelo site www.spoj.com provavelmente redireciona a entrada e a saída de e para os arquivos.

AlexLop fez outro teste: ler todas as entradas de uma vez em um vetor e, subsequentemente, computar e escrever todas as saídas ajuda a entender por que a versão C ++ é tão mais lenta. Ele aumenta o desempenho em relação à versão C, o que prova meu ponto e remove a suspeita sobre o código de formatação C ++.

Outro teste da Blastfurnace, armazenando todas as saídas em um std::ostringstreame liberando-as de uma vez no final, melhora o desempenho do C ++ em relação à versão C básica. QED.

Entrelaçar a entrada cine a saída coutparece causar um tratamento de E / S muito ineficiente, anulando o esquema de buffer de fluxo. reduzindo o desempenho por um fator de 10.

PS: seu algoritmo está incorreto fact_num >= UINT_MAX / 5porque fives *= 5irá estourar e quebrar antes de se tornar > fact_num. Você pode corrigir isso criando fivesum unsigned longou um unsigned long longse um desses tipos for maior que unsigned int. Use também %ucomo scanfformato. Você tem sorte de que os caras do www.spoj.com não sejam muito rígidos em seus benchmarks.

EDITAR: Como explicado posteriormente por vitaux, esse comportamento é realmente exigido pelo padrão C ++. cinestá vinculado coutpor padrão. Uma operação de entrada cinpara a qual o buffer de entrada precisa ser recarregado causará o coutesvaziamento da saída pendente. Na implementação do OP, cinparece fluir coutsistematicamente, o que é um pouco exagero e visivelmente ineficiente.

Ilya Popov forneceu uma solução simples para isso: cinpode ser desamarrado coutlançando outro feitiço mágico além de std::ios_base::sync_with_stdio(false);:

cin.tie(nullptr);

Observe também que tal descarga forçada também ocorre ao usar em std::endlvez de '\n'para produzir um fim de linha cout. Alterar a linha de saída para uma aparência mais idiomática e inocente do C ++ cout << num_of_trailing_zeros << endl;degradaria o desempenho da mesma forma.

Outro truque para tornar iostreams mais rápido quando você usa ambos cine couté chamar

cin.tie(nullptr);

Por padrão, quando você insere qualquer coisa de cin, ele esvazia cout. Isso pode prejudicar significativamente o desempenho se você fizer entradas e saídas intercaladas. Isso é feito para os usos da interface de linha de comando, onde você mostra algum prompt e espera pelos dados:

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

Neste caso, você deseja ter certeza de que o prompt é realmente mostrado antes de começar a esperar pela entrada. Com a linha acima, você quebra esse laço cine coutse torna independente.

Desde C ++ 11, mais uma maneira de obter melhor desempenho com iostreams é usar std::getlinejunto com std::stoi, desta forma:

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

Dessa forma, pode chegar perto do estilo C em desempenho, ou até mesmo superar scanf. Usar getchare especialmente getchar_unlockedjunto com a análise manuscrita ainda fornece um melhor desempenho.

PS. Eu escrevi um post comparando várias maneiras de inserir números em C ++, útil para juízes online, mas é apenas em russo, desculpe. Os exemplos de código e a tabela final, no entanto, devem ser compreensíveis.

O problema é que, citando cppreference :

qualquer entrada de std :: cin, saída para std :: cerr ou encerramento do programa força uma chamada para std :: cout.flush ()

Isso é fácil de testar: se você substituir

cin >> fact_num;

com

scanf("%d", &fact_num);

e o mesmo para, cin >> num_of_inputsmas manter, coutvocê obterá praticamente o mesmo desempenho em sua versão C ++ (ou melhor, versão IOStream) como em C um:

O mesmo acontece se você mantiver, cinmas substituir

cout << num_of_trailing_zeros << "\n";

com

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

Uma solução simples é desamarrar coute cinconforme mencionado por Ilya Popov:

cin.tie(nullptr);

As implementações da biblioteca padrão podem omitir a chamada para flush em certos casos, mas nem sempre. Aqui está uma citação de C ++ 14 27.7.2.1.3 (graças a chqrlie):

Classe basic_istream :: sentry: Primeiro, se is.tie () não for um ponteiro nulo, a função chama is.tie () -> flush () para sincronizar a sequência de saída com qualquer fluxo C externo associado. Exceto que essa chamada pode ser suprimida se a área put de is.tie () estiver vazia. Além disso, uma implementação é permitida para adiar a chamada para flush até que uma chamada de is.rdbuf () -> underflow () ocorra. Se nenhuma chamada ocorrer antes que o objeto sentinela seja destruído, a chamada para flush pode ser totalmente eliminada.