Porque é que o JavaScript parece ser 4 vezes mais rápido que o C++?

Fazendo um teste rápido com a ativação da otimização, obtive resultados de cerca de 150 ms para um antigo processador AMD 64 X2, e cerca de 90 ms para um processador Intel i7 razoavelmente recente.

Então eu fiz um pouco mais para dar uma ideia de uma razão para você querer usar C++. Eu desenrolei quatro iterações do loop, para conseguir isto:

#include <stdio.h>
#include <ctime>

int main() {
    double a = 3.1415926, b = 2.718;
    double c = 0.0, d=0.0, e=0.0;
    int i, j;
    clock_t start, end;
    for(j=0; j<10; j++) {
        start = clock();
        for(i=0; i<100000000; i+=4) {
            a += b;
            c += b;
            d += b;
            e += b;
        }
        a += c + d + e;
        end = clock();
        printf("Time Cost: %fms\n", (1000.0 * (end - start))/CLOCKS_PER_SEC);
    }
    printf("a = %lf\n", a);
    return 0;
}

Isto permite que o código C++ corra em cerca de 44ms no AMD (esqueceu-se de executar esta versão no Intel). Depois liguei o auto-vectorizador do compilador. (- Qpar com VC++). Isso reduziu o tempo um pouco mais ainda, para cerca de 40 ms no AMD, e 30 ms no Intel.

Conclusão: se quiser usar o C++, tem de aprender a usar o compilador. Se você quer obter realmente bons resultados, você provavelmente também quer aprender a escrever um código melhor.

Devo acrescentar que não tentei testar uma versão em Javascript com o loop desenrolado. Fazê-lo pode proporcionar uma melhoria similar (ou pelo menos alguma) da velocidade em JS também. Pessoalmente, acho que fazer o código rápido é muito mais interessante do que comparar Javascript com C++.

Se quiser que um código como este corra rápido, desenrole o loop (pelo menos em C++).

Uma vez que o assunto da computação paralela surgiu, pensei em Adicionar outra versão usando OpenMP. Enquanto estava lá, limpei um pouco o código, para poder acompanhar o que se estava a passar. Eu também alterei o código de tempo um pouco, para exibir o tempo total em vez do tempo para cada execução do laço interior. O código resultante era assim:

#include <stdio.h>
#include <ctime>

int main() {
    double total = 0.0;
    double inc = 2.718;
    int i, j;
    clock_t start, end;
    start = clock();

    #pragma omp parallel for reduction(+:total) firstprivate(inc)
    for(j=0; j<10; j++) {
        double a=0.0, b=0.0, c=0.0, d=0.0;
        for(i=0; i<100000000; i+=4) {
            a += inc;
            b += inc;
            c += inc;
            d += inc;
        }
        total += a + b + c + d;
    }
    end = clock();
    printf("Time Cost: %fms\n", (1000.0 * (end - start))/CLOCKS_PER_SEC);

    printf("a = %lf\n", total);
    return 0;
}

A adição primária aqui é a seguinte linha (reconhecidamente algo Arcana):

#pragma omp parallel for reduction(+:total) firstprivate(inc)

Isto diz ao compilador para executar o laço exterior em vários tópicos, com uma cópia separada de inc para cada tópico, e adicionando os valores individuais de total Após a secção paralela.

O resultado é o que se espera. Se não ativarmos o OpenMP com a bandeira do compilador -openmp, O Relatório o tempo é cerca de 10 vezes o que vimos anteriormente para execuções individuais (409 ms para a AMD, 323 MS para a Intel). Com o OpenMP ligado, o tempo passa para 217 ms para o AMD, e 100 ms para as informações. Então, segundo as informações, a versão original levou 90m por uma iteração do laço exterior. Com esta versão estamos ficando apenas um pouco mais longo (100 ms) para todas as 10 iterações do laço exterior -- uma melhoria na velocidade de cerca de 9:1. Numa máquina com mais núcleos, poderíamos esperar ainda mais melhoria (o OpenMP normalmente tirará vantagem de todos os núcleos disponíveis automaticamente, embora você possa afinar manualmente o número de threads se quiser).

Este é um tópico polarizante, por isso pode - se ver:

Https://benchmarksgame-team.pages.debian.net/benchmarksgame/

([1]) aferir todos os tipos de línguas.

Javascript V8 e tal estão certamente fazendo um bom trabalho para loops simples como no exemplo, provavelmente gerando código de máquina muito semelhante. Para a maioria das aplicações" perto do Usuário " Javscript certamente é a melhor escolha, mas tenha em mente o desperdício de memória e as muitas vezes inevitáveis performance hit (and lack of control) for more complicated algorithms/applications.