Quanto mais rápido é C ++ de C #?

https://stackoverflow.com/questions/138361

02-07-2019
|

Pergunta

Ou é agora o contrário?

Pelo que tenho ouvido há algumas áreas em que C # prova ser mais rápido do que C ++, mas eu nunca tive a coragem de testá-lo por mim mesmo.

O pensamento algum de vocês poderia explicar essas diferenças de pormenor ou apontar-me para o lugar certo para obter informações sobre isso.

Solução

Não há nenhuma razão estrita por uma linguagem baseada bytecode como C # ou Java que tem um JIT não pode ser tão rápido como o código C ++. No entanto código C ++ usado para ser significativamente mais rápido por um longo tempo, e também hoje ainda é em muitos casos. Isto é principalmente devido às otimizações JIT mais avançadas que estão sendo complicado de implementar, e o muito legal queridos estão apenas chegando agora.

Assim, C ++ é mais rápido, em muitos casos. Mas esta é apenas parte da resposta. Os casos em C ++ é realmente mais rápido, são programas, onde programadores especializados otimizados completamente o inferno fora do código altamente otimizado. Isto não só é muito demorado (e, portanto, caro), mas também comumente leva a erros devido ao excesso de otimizações.

Por outro lado, o código em linguagens interpretadas fica mais rápido em versões posteriores do tempo de execução (CLR do .NET ou Java VM), sem ter que fazer qualquer coisa. E há uma série de otimizações úteis compiladores JIT pode fazer que são simplesmente impossível em línguas com ponteiros. Além disso, alguns argumentam que a coleta de lixo deve ser geralmente tão ou mais rápido como gerenciamento de memória manual, e em muitos casos é. Geralmente você pode implementar e alcançar tudo isso em C ++ ou C, mas vai ser muito mais complicado e propenso a erros.

Como disse Donald Knuth, "otimização prematura é a raiz de todo mal". Se você realmente sabe com certeza que sua aplicação vai consistem principalmente em aritmética crítica desempenho muito, e que vai ser o gargalo, e é certamente vai ser mais rápido em C ++, e você está certo de que C ++ não entrarão em conflito com a outra requisitos, ir para C ++. Em qualquer outro caso, concentrado na primeira implementação do seu aplicativo corretamente em qualquer ternos idioma que melhor, em seguida, encontrar gargalos de desempenho, se ele é executado muito lento, e depois pensar sobre como otimizar o código. No pior dos casos, pode ser necessário para chamar o código C através de uma interface de função externa, assim você ainda vai ter a capacidade de escrever peças críticas na linguagem de nível mais baixo.

Tenha em mente que é relativamente fácil para otimizar um programa correto, mas muito mais difícil de corrigir um programa otimizado.

Dar percentagens reais de vantagens de velocidade é impossível, em grande parte depende do seu código. Em muitos casos, a implementação da linguagem de programação não é ainda o gargalo. Pegue os benchmarks em http://benchmarksgame.alioth.debian.org/ com uma grande dose de ceticismo , como estes em grande parte testar o código aritmético, o que é mais provável não é semelhante ao seu código em tudo.

Outras dicas

C # pode não ser mais rápida, mas faz YOU / ME mais rápido. Essa é a medida mais importante para o que eu faço. :)

É cinco laranjas mais rápido. Ou melhor: não pode haver nenhuma resposta geral (correto). C ++ é uma linguagem estaticamente compilado (mas, em seguida, há perfil de otimização guiada, também), C # é executado com o auxílio de um compilador JIT. Há tantas diferenças que perguntas como “quanto mais rápido” não pode ser respondida, nem mesmo dando ordens de magnitude.

Vou começar por discordar de parte da resposta aceita (e bem-upvoted) a esta questão, afirmando:

Na verdade, existem muitas razões pelas quais o código JITted vai ficar mais lento do que um devidamente otimizado C ++ (ou outro idioma sem a sobrecarga de tempo de execução) programa incluindo:

ciclos de computação gastos em código JITting em tempo de execução são, por definição indisponíveis para uso na execução do programa.
quaisquer caminhos quentes no jitter estará competindo com o seu código para instrução e cache de dados na CPU. Sabemos que domina de cache quando se trata de desempenho e nativos linguagens como C ++ não tem esse tipo de disputa, por definição.
orçamento vez que um de tempo de execução do otimizador é necessariamente muito mais restrita do que a de um tempo de compilação do otimizador (como outro comentarista apontou)

A linha inferior :. Em última análise, você irá quase certamente ser capaz de criar uma implementação mais rápida em C ++ do que você poderia, em C #

Agora, com o que disse, o quanto mais rápido realmente não é quantificável, pois há muitas variáveis: a tarefa, domínio do problema, hardware, qualidade das implementações, e muitos outros fatores. Você vai ter executar testes em seu cenário para determinar a diferença no desempenho, e então decidir se vale a pena o esforço e complexidade adicional.

Este é um tópico muito longo e complexo, mas eu sinto que vale a pena mencionar para a questão de exaustividade que 's C # runtime otimizador é excelente, e é capaz de executar determinadas otimizações dinâmicas em tempo de execução que simplesmente não estão disponíveis para C ++ com a sua compilação -time (estático) otimizador. Mesmo com isso, a vantagem ainda é tipicamente profundamente na corte do aplicativo nativo, mas o otimizador dinâmico é a razão para o " quase certamente" qualificador dado acima.

Em termos de desempenho relativo, eu também estava perturbado pelas figuras e discussões que vi em algumas outras respostas, então eu pensei que eu gritei e, ao mesmo tempo, fornecer algum apoio para as declarações que fiz acima .

Uma grande parte do problema com esses benchmarks é que você não pode escrever código C ++ como se você estivesse escrevendo C # e espera obter resultados representativos (ex. Realização de milhares de alocações de memória em C ++ vai lhe dar números terríveis. )

Em vez disso, eu escrevi um pouco mais idiomática código C ++ e comparado com o código C # @Wiory fornecido. As duas principais alterações que fiz ao código C ++ foram:

1) vector utilizado :: reserva ()

2) achatada da matriz 2d para 1d para conseguir uma melhor localização do cache (bloco contíguo)

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

Run Time (Release): Init: 124ms, preencha: 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);
}

Run Time (Release): Init: 398µs (sim, isso é microssegundos), Fill: 152ms

total de funcionamento vezes: C #: 289ms, 152ms C ++ (cerca de 90% mais rápido)

Observações

Alterar a implementação C # para a mesma implementação variedade 1d renderam INIT: 40ms, preencha: 171ms, Total: 211ms ( C ++ ainda era quase 40% mais rápido ).
É muito mais difícil de projetar e escrever "rápido" de código em C ++ do que está a escrever o código "regular" em qualquer idioma.
É (talvez) surpreendentemente fácil de obter um desempenho ruim em C ++; vimos que com desempenho vetores sem reservas. E há muitas armadilhas como este.
C # 's desempenho é bastante surpreendente quando você considerar tudo o que está acontecendo em tempo de execução. E que o desempenho é relativamente fácil acesso.
Dados mais anedóticos comparando o desempenho de C ++ e C #: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore

A linha inferior é que C ++ lhe dá muito mais controle sobre o desempenho. Você quer usar um ponteiro? Uma referência? memória de pilha? Heap? polimorfismo dinâmico ou eliminar a sobrecarga de tempo de execução de uma vtable com polimorfismo estático (via templates / CRTP)? Em C ++ você tem que ... er, chegar fazer todas estas escolhas (e mais)-se, de preferência de modo a que a sua solução melhores endereços do problema que você está combate.

Pergunte a si mesmo se você realmente quer ou precisa que o controle, porque mesmo para o exemplo trivial acima, você pode ver que embora haja uma melhoria significativa no desempenho, que exige um investimento mais profundo para acesso.

Na minha experiência (e eu tenho trabalhado muito com ambos os idiomas), o principal problema com C # comparação com C ++ é alto consumo de memória, e eu ainda não encontrei uma boa maneira de controlá-lo. Era o consumo de memória que acabaria por abrandar .NET software.

Outro fator é que o compilador JIT não podem pagar muito tempo para fazer otimizações avançadas, porque ele é executado em tempo de execução, eo usuário final notaria que se leva muito tempo. Por outro lado, compilador C ++ tem todo o tempo que ele precisa para fazer otimizações em tempo de compilação. Este fator é muito menos significativo do que o consumo de memória, IMHO.

Um cenário específico onde C ++ ainda tem a mão superior (e, para os próximos anos) ocorre quando as decisões polimórficos pode ser pré-determinado em tempo de compilação.

Geralmente, encapsulamento e adiou a tomada de decisões é uma coisa boa, porque torna o código mais dinâmico, mais fácil de se adaptar às mudanças de requisitos e mais fácil de usar como um quadro. É por isso que programação orientada a objeto em C # é muito produtivo e pode ser generalizada sob o termo “generalização”. Infelizmente, este tipo particular de generalização tem um custo em tempo de execução.

Normalmente, este custo não é substancial, mas existem aplicações onde a sobrecarga de chamadas de métodos virtuais e criação do objeto podem fazer a diferença (especialmente desde métodos virtuais impedir que outras otimizações, como a chamada de método inlining). Isto é onde C ++ tem uma enorme vantagem porque você pode usar modelos para conseguir um tipo diferente de generalização que tem não impacto no tempo de execução, mas não é necessariamente menos polimórfica do que OOP. Na verdade, todos os mecanismos que constituem OOP podem ser modelados usando técnicas só modelo e resolução de tempo de compilação.

Em tais casos (e reconhecidamente, eles são muitas vezes restrito aos domínios especiais problema), vitórias C ++ contra C # e linguagens comparáveis.

C ++ (ou C para que o assunto) lhe dá o controle refinado sobre suas estruturas de dados. Se você quiser bit-twiddle você tem essa opção. Grande conseguiu Java ou .NET aplicativos (OWB, Visual Studio 2005 ) que usam os dados internos estruturas das bibliotecas Java / .NET transportar a bagagem com eles. Eu vi sessões de designer OWB usando mais de 400 MB de RAM e propostas para cubo ou ETL projetar metendo os 100 dos MB também.

Em uma carga de trabalho previsível (como a maioria dos benchmarks que se repetem um processo muitas vezes) um JIT você pode obter o código que é otimizado muito bem que não há nenhuma diferença prática.

IMO em grandes aplicações a diferença não é tanto o JIT como as estruturas de dados que o próprio código está usando. Quando um pedido é memória-pesado você terá uso de cache menos eficiente. erros de cache em processadores modernos são bastante caros. Onde C ou C ++ realmente ganhar é onde você pode otimizar o uso de estruturas de dados para jogar bem com o cache da CPU.

Para gráficos da classe C # Gráficos padrão é maneira mais lenta do que GDI acessada via C / C ++. Eu sei que isto não tem nada a ver com a linguagem por si só, mais com a plataforma total de .NET, mas Graphics é o que é oferecido para o desenvolvedor como um substituto GDI, e seu desempenho é tão ruim que eu nem sequer se atrevem a fazer gráficos com ele.

Nós temos uma referência simples que usamos para ver o quão rápido uma biblioteca gráfica é, e isso é simplesmente desenhar linhas aleatórias em uma janela. C ++ / GDI ainda é snappy com 10000 linhas, enquanto C # / Graphics tem dificuldade em fazer 1000 em tempo real.

A coleta de lixo é a principal razão Java # não pode ser usado para sistemas de tempo real.

Quando o GC acontecer?
Quanto tempo vai demorar?

Esta é não-determinista.

Temos tido para determinar se C # foi comparável ao C ++ no desempenho e eu escrevi alguns programas de teste para que (usando Visual Studio 2005 para ambos os idiomas). Descobriu-se que, sem coleta de lixo e considerando apenas a língua (não o quadro) C # tem basicamente o mesmo desempenho como C ++. alocação de memória é muito mais rápido em C # que em C ++ e C # tem uma ligeira vantagem no determinismo quando os tamanhos de dados são aumentadas além das fronteiras linha de cache. No entanto, tudo isso teve, eventualmente, a ser pago e há um custo enorme na forma de visitas de desempenho não-determinísticos para C #, devido à coleta de lixo.

Como de costume, ele depende da aplicação. Há casos em que C # é provavelmente insignificante mais lento, e outros casos em C ++ é 5 ou 10 vezes mais rápido, especialmente nos casos em que as operações podem ser facilmente SIMD'd.

Eu sei que não é o que você estava perguntando, mas C # é muitas vezes mais rápido para write do que C ++, que é um grande bônus em um estabelecimento comercial.

C / C ++ pode executar muito melhor em programas onde existem tanto grandes arrays ou looping heavy / iteração sobre matrizes (de qualquer tamanho). Esta é a razão que os gráficos são geralmente muito mais rápido em C / C ++, porque as operações de matriz pesado subjacentes quase todas as operações gráficas. NET é notoriamente lento em operações de indexação de matriz devido a todas as verificações de segurança, e isso é especialmente verdadeiro para arrays multidimensionais (e, sim, rectangular C # matrizes são ainda mais lento do que C # arrays irregulares).

Os bônus de C / C ++ são mais pronunciados se ater diretamente com ponteiros e impulsionar evitar, std::vector e outros recipientes de alto nível, bem como inline cada pequena função possível. Use matrizes velha escola sempre que possível. Sim, você vai precisar de mais linhas de código para realizar a mesma coisa que você fez em Java ou C # que você evite recipientes de alto nível. Se precisar de uma matriz de tamanho dinamicamente, você só precisa se lembrar de emparelhar o new T[] com um correspondente declaração delete[] (ou std::unique_ptr uso) -o preço para a velocidade extra é que você deve codificar com mais cuidado. Mas em troca, você começa a livrar-se da sobrecarga de coletor de memória / lixo gerenciado, que pode facilmente ser 20% ou mais do tempo de execução de programas fortemente orientadas a objetos em Java e .NET, bem como aqueles massiva conseguiu memória custos de indexação de matriz. Aplicativos C ++ também podem se beneficiar de algum compilador bacana muda em certos casos específicos.

Eu sou um programador especialista em C, C ++, Java e C #. Recentemente, tive a ocasião rara para implementar o exato mesmo programa algorítmico nos últimos 3 idiomas. O programa tinha um monte de matemática e operações de matriz multi-dimensional. I altamente otimizado isso em todos os 3 idiomas. Os resultados foram típico do que eu normalmente ver em comparações menos rigorosos: Java foi de cerca de 1,3x mais rápido do que C # (a maioria das JVMs são mais otimizada do que a CLR), ea versão ponteiro C ++ matéria veio em cerca de 2,1x mais rápido do que C # . Note que o programa C # usado somente seguro código é minha opinião que você poderia muito bem código-lo em C ++ antes de usar a palavra-chave unsafe.

Para que ninguém pense que eu tenho alguma coisa contra C #, eu por perto vai dizendo que C # é provavelmente a minha linguagem favorita. É a linguagem de desenvolvimento mais lógico, intuitivo e rápido que eu encontrei até agora. Eu faço todos meus protótipos em C #. A linguagem C # tem muitas vantagens pequenas, sutis sobre Java (sim, eu sei que a Microsoft teve a chance de corrigir muitas das deficiências do Java inserindo o jogo final e, possivelmente, copiando Java). Brinde a classe Calendar qualquer um de Java? Se a Microsoft já gasta esforço real para otimizar o CLR e .NET jitter, C # pode levar a sério de novo. Sinceramente estou surpreso que não tenha já fizeram tantas coisas direito na linguagem C #, por que não segui-lo com otimizações de compilador de bater pesados? Talvez se todos nós beg.

> Pelo que tenho ouvido ...

A sua dificuldade parece ser para decidir se o que você ouviu é credível, e que dificuldades só vai ser repetido quando você tenta avaliar as respostas neste site.

Como é que vai decidir se as coisas que as pessoas dizem aqui são mais ou menos credível do que aquilo que inicialmente ouviu?

Uma forma seria a de pedir evidências .

Quando alguém afirma "há algumas áreas em que C # prova ser mais rápido do que C ++" pedir-lhes por , eles dizem que , pedir-lhes para mostrar-lhe as medições, pergunte -los para mostrar-lhe programas. Às vezes, eles vão simplesmente ter cometido um erro. Às vezes, você vai descobrir que eles estão apenas expressando uma opinião ao invés de compartilhar algo que eles podem mostrar para ser verdade.

Muitas vezes, informação e opinião serão misturados no que as pessoas dizem, e você tem que tentar e resolver qual é qual. Por exemplo, a partir das respostas neste fórum:

"Toma os benchmarks em http://shootout.alioth.debian.org / com uma grande dose de ceticismo, como estes, em grande parte testar o código aritmético, que é mais provável não semelhante ao seu código em tudo. "

Pergunte a si mesmo se você realmente entender o que "estes em grande parte teste código de aritmética " meios, e, em seguida, pergunte-se se o autor tem realmente mostrado que sua reivindicação é verdade.
"Isto é um teste bastante inútil, uma vez que realmente depende de quão bem os programas individuais foram optimizado; Eu consegui acelerar alguns deles por 4-6 vezes ou mais, deixando claro que a comparação entre os programas não otimizados é bastante tolo. "

Pergunte-se se o autor tem realmente mostrado que ele conseguiu a "velocidade de alguns deles por 4-6 vezes ou mais!" - é uma reivindicação fácil de fazer

.NET línguas pode ser tão rápido como o código C ++, ou mesmo mais rápido, , mas C ++ código terá uma mais constante rendimento como o tempo de execução .NET tem que fazer uma pausa para GC , mesmo que seja muito inteligente sobre suas pausas.

Então, se você tem algum código que tem que consistentemente correr rápido sem qualquer pausa, .NET irá introduzir latência em algum ponto , mesmo se você tiver muito cuidado com o GC tempo de execução.

Para os problemas dos embarassingly paralelas ", quando se utiliza Intel TBB e OpenMP em C ++ Eu tenho observado um aumento de cerca de 10x o desempenho em comparação com (matemática pura) problemas semelhantes feitos com C # e TPL. SIMD é uma área onde C # não pode competir, mas eu também tenho a impressão de que TPL tem uma sobrecarga considerável.

Dito isso, eu só uso C ++ para tarefas de desempenho crítico em que eu sei que vai ser capaz de multithread e obter resultados rapidamente. Para tudo o resto, C # (e, ocasionalmente, F #) é apenas multa.

É uma questão extremamente vaga sem respostas definitivas reais.

Por exemplo; Eu prefiro jogar 3D-jogos que são criados em C ++ do que em C #, porque o desempenho é certamente muito melhor. (E eu sei XNA, etc., mas se trata de modo algum perto da coisa real).

Por outro lado, como mencionado anteriormente; você deve desenvolver em uma linguagem que permite que você faça o que você quer rapidamente, e, em seguida, se otimizar necessário.

Em teoria, por muito tempo em execução aplicativo do tipo servidor, uma linguagem compilada-JIT pode se tornar muito mais rápido do que uma contrapartida compilado nativamente. Desde que a língua JIT compilado é geralmente compilados pela primeira vez a uma linguagem intermediária bastante baixo nível, você pode fazer um monte de otimizações de alto nível direito em tempo de compilação de qualquer maneira. A grande vantagem vem em que o JIT pode continuar a recompilar seções de código em tempo real quanto ele ganha mais e mais dados sobre como o aplicativo está sendo usado. Ele pode providenciar a maioria de código-caminhos comuns para permitir a previsão de desvios para ter sucesso mais rápido possível. Ele pode re-organizar blocos de código separados que são muitas vezes chamados juntos para mantê-los tanto no cache. Ele pode gastar mais esforço otimizar laços internos.

Eu duvido que isso seja feito pelo .NET ou qualquer um dos JREs, mas estava sendo pesquisada para trás quando eu estava na universidade, por isso não é razoável pensar que este tipo de coisas pode encontrar o seu caminho para o mundo real em algum momento em breve.

Os aplicativos que requerem intensivo de acesso à memória, por exemplo. manipulação de imagem são geralmente melhor fora escrito em ambiente não gerenciado (C ++) que conseguiu (C #). Optimized espiras internas com aritmética de ponteiro são muito mais fáceis para o controle de em C ++. Em C # pode ser necessário recorrer ao código inseguro até mesmo chegar perto o mesmo desempenho.

Eu testei vector em C ++ e C # equivalente -. List e simples matrizes 2d

Eu estou usando / C ++ 2010 edições do Visual C # Express. Ambos os projetos são aplicativos de console simples, eu testei-los em (sem configurações personalizadas) versão padrão e modo de depuração. # listas C correr mais rápido no meu pc, inicialização de matriz também é mais rápido em C #, operações matemáticas são mais lentos.

Eu estou usando Intel Core2Duo P8600@2.4GHz, C # -. .NET 4.0

Eu sei que a implementação vector é diferente do C # lista, mas eu só queria coleções de teste que eu iria usar para armazenar meus objetos (e ser capaz de usar o índice acessor).

É claro que você precisa para limpar memória (digamos que para cada uso de new), mas eu queria manter o simples código.

C ++ teste de vector de :

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

C # teste lista:

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 # - array:

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);

}

Time: (LANÇAMENTO / Debug)

C ++

600/606 ms matriz de inicialização,
200/270 ms matriz de enchimento,
1seg / 13sec vector de inicialização e de preenchimento.

(Sim, 13 segundos, eu sempre tenho problemas com as listas / vetores em modo de depuração.)

C #:

20/20 ms variedade de inicialização,
403/440 ms variedade de preenchimento,
710/742 ms lista de inicialização e de preenchimento.

Bem, depende. Se o código-byte é traduzida em código de máquina (e não apenas JIT) (quero dizer, se você executar o programa) e se seu programa usa muitas alocações / deallocations poderia ser mais rápido porque o GC algoritmo só precisa de uma passagem (teoricamente) através de toda a memória uma vez, mas malloc normais / realocar / C livre / C ++ chamadas provoca uma sobrecarga em cada chamada (call-sobrecarga, de dados de estrutura superior, erros de cache;).)

Por isso, é teoricamente possível (também para outras línguas GC).

Eu não realmente ver a extrema desvantagem de não ser capaz de usar metaprogramming com C # para a maioria das aplicações, porque a maioria dos programadores não usá-lo de qualquer maneira.

Outra grande vantagem é que o SQL, como o LINQ "extensão", oferece oportunidades para o compilador para chamadas otimizar a bases de dados (em outras palavras, o compilador poderia compilar todo o LINQ para um binário "blob", onde as chamadas funções são inlined ou para seu uso otimizado, mas estou especulando aqui).

Eu suponho que há aplicações escritas em C # correndo rápido, assim como há mais de C ++ aplicativos escritos em execução rápida (bem C ++ apenas mais velho ... e tomar UNIX também ...)
- a questão de fato é - o que é aquela coisa, usuários e desenvolvedores estão reclamando ...
Bem, IMHO, em caso de C # temos muito conforto UI, muito agradável hierarquia de bibliotecas e sistema de interface toda a CLI. Em caso de C ++ temos modelos, ATL, COM, MFC e todo shebang de alreadyc escrita e código correndo como OpenGL, DirectX e assim por diante ... Os desenvolvedores se queixa de chamadas GC indeterminably Ressuscitado em caso de programa C # (meio corre rápido, e em um segundo - estrondo é preso)
. Para escrever código em C # muito simples e rápido (não esquecer que também aumentar a chance de erros. Em caso de C ++, os desenvolvedores se queixa de vazamentos de memória, - meios esmaga, chamadas entre DLLs, bem como de "inferno DLL" - problema com bibliotecas de apoio e substituição por outros mais recentes ...
Eu acho que mais habilidade que você terá na linguagem de programação, o mais qualidade (e velocidade) irá caracterizar o seu software.

eu iria colocá-lo desta maneira: programadores que escrevem código mais rápido, são os que estão mais informados do que faz máquinas atuais ir mais rápido, e, incidentalmente, eles também são os que usam uma ferramenta adequada que permite a baixa precisão nível e técnicas de otimização determinísticos. Por estas razões, essas pessoas são os que usam C / C ++ em vez de C #. Eu iria tão longe como dizendo isso como um fato.

> Afinal, as respostas têm que estar em algum lugar, não é? :)

Umm, não.

Como várias respostas observou, a questão está sub-especificado de forma que convidam perguntas em resposta, não respostas. Para dar apenas um caminho:

a língua de pergunta confunde com implementação da linguagem - este programa C é tanto 2.194 vezes mais lento e 1,17 vezes mais rápido do que este programa C # - teríamos que perguntar-lhe: Qual implementações de linguagem

E, em seguida, que os programas? Que máquina? Qual OS? Qual conjunto de dados?

Se não estou enganado, C # modelos são determinados em tempo de execução. Este deve ser mais lento do que modelos de tempo de compilação de C ++.

E quando você toma em todos os outras otimizações de tempo de compilação mencionado por tantos outros, bem como a falta de segurança que faz, de fato, a velocidade média mais ...

Eu diria C ++ é a escolha óbvia em termos de velocidade crua e consumo mínimo de memória. Mas isso também se traduz em mais tempo desenvolvendo o código e garantir que você não está com vazamento de memória ou causar quaisquer exceções de ponteiro nulo.

Veredicto:

C #: Desenvolvimento mais rápido, mais lento run
C ++:. Desenvolvimento lento, mais rápido executar

Ela realmente depende do que você está tentando realizar em seu código. Ouvi dizer que ele é apenas o material de lenda urbana que não há qualquer diferença de desempenho entre VB.NET, C # e C ++ gerenciado. No entanto, eu encontrei, pelo menos em comparações de strings, que conseguiu C ++ bate as calças fora de C #, que por sua vez bate as calças fora de VB.NET.

Eu tenho de maneira nenhuma feitas quaisquer comparações exaustivas em complexidade algorítmica entre as línguas. Eu também estou usando as configurações padrão em cada uma das línguas. Em VB.NET Eu estou usando configurações para exigir declaração de variáveis, etc. Aqui está o código que estou usando para gerenciado C ++: (Como você pode ver, este código é bastante simples). Estou executando o mesmo nas outras línguas em Visual Studio 2013, com .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;
}

Existem algumas diferenças importantes entre C # e C ++ no aspecto de desempenho:

C # é GC / pilha base. A alocação ea própria GC é a sobrecarga como a não localidade do acesso à memória
otimizadores C ++ se tornaram muito boa ao longo dos anos. compiladores JIT não pode atingir o mesmo nível uma vez que só têm limitado o tempo de compilação e não vê o escopo global

Além de que a competência programador desempenha também um papel. Eu vi código ruim C ++ onde as aulas onde passados ??por valor como argumento em todo o lugar. Você pode realmente piorar a situação em C ++, se você não prestar atenção.

Inspirado por isso, eu fiz um teste rápido com 60 por cento de instrução comum necessária na maioria das programas.

Aqui está o 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();
}

Cadeia matriz e matrizes são usadas propositadamente para incluir essas instruções.

Aqui está o 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();
}

O tamanho do arquivo de entrada que eu usei foi de 40 KB.

E aqui está o resultado -

C ++ correu código em 9 segundos.
C # código: 4 segundos !!!

Oh, mas esta foi no Linux ... Com C # execução no Mono ... E C ++ com g ++.

OK, é isso que eu tenho no Windows - Visual Studio 2003 :

C # código correu em 9 segundos.
código de C ++ - horríveis 370 segundos !!!

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow