Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
tempo = 1018
soma = 894782460
tempo = 371
soma = 894782460
Não sei por que, mas µl o ultrapassa (e também variantes rand() mais intrincadas).
E para mim é óbvio - tire-o do laço.
Sim, você está certo, eu também experimentei em VS e por alguma razão não otimizou em nada, embora uma variante tão simples pareça... Na verdade, se resume a isto:
Sim, você está certo, eu também já tentei em VS - por alguma razão não está otimizado no mínimo, embora uma opção tão simples, parece... Em essência, tudo se resume a isto:
Você tem certeza de ter ativado toda a otimização em configurações do projeto? Em casos estranhos, eu ligo a geração de listagem de montagem e olho através dela, é muito instrutiva.
Decidi testá-lo em C# também por curiosidade. Não só os resultados são quase os mesmos em velocidade, mas também funcionam muito mais rápido que C++.
Resultados:
Soma: 894782460, Tempo: 69 ms.
Soma: 894782460, Tempo: 56 ms
E aqui está um análogo em C++:
Soma: 894782460, Tempo: 2947 ms
Soma: 894782460, Tempo: 684 ms
Testei-o no VS 2019.Toda otimização está habilitada .
Parafusar um C++).
p.s. Os resultados em C# variam agradavelmente de teste para teste, mas na média, ambas as variantes são igualmente rápidas.
Você precisa entender primeiro as razões para os freios. Fiz uma pequena escavação, e tudo está em linha, exceto a chamada
que se encontra na libstdc+++. Ou seja, no fundo do loop quase nu, o gargalo é a função chamada a si mesmo (e há um par de chamadas de ...substituirEmmPKcm também). O compilador pode otimizar dentro de uma única unidade de tradução. Você pode tentar usar o LTO (link time optimization), ou seja, isto permite otimizar na etapa de ligação. Mas eu não o usei, não o farei agora. Bem, não há nada particularmente complicado - passe para a opção compiler/linker -flto (mas falta algum plugin), preguiçoso demais para perceber + pode ter que reconstruir a libstdc++.
Como será com a otimização do código em conexão com os próximos módulos de aparafusamento (desde C++20) ? Eu não sei, você pode tentar em vs, embora tudo esteja cru e experimentalhttps://habr.com/en/company/pvs-studio/blog/328482/
c++'u não será atendido )).
Por interesse, decidi testar também em C#. Não só os resultados são quase os mesmos em termos de velocidade, mas também trabalham uma ordem de grandeza mais rápida do que C++.
Resultados:
Soma: 894782460, Tempo: 69 ms
Soma: 894782460, Tempo: 56 ms
E aqui está um análogo em C++:
Soma: 894782460, Tempo: 2947 ms.
Soma: 894782460, Tempo: 684 ms
Testei-o no VS 2019.Toda otimização está habilitada .
Parafusar um C++).
p.s. Os resultados em C# flutuam significativamente de teste para teste, mas na média ambas as variantes são iguais em velocidade.
Br-r-r-r-r, nem pensar! O Sharp sempre venceu os profissionais puros por um fator de dois, você coloca o projeto para fora do plz.
Crianças pequenas :)
Eles esticaram o brinquedo para 10 páginas...
Aqui devemos entender as razões da lentidão no início. Eu fiz uma pequena escavação e tudo está em linha, exceto a chamada
que se encontra na libstdc+++.
Portanto, parece ter descoberto que ele aloca e elimina a memória toda vez que mesmo neste caso:
A propósito, posso ter dado resultados errados da última vez. O mais provável foi no modo x86. Agora estou testando no modo x64 e os resultados por C++ são muito melhores:
1) ~ 2000 msec
2) ~ 200 ms (é 3 vezes mais rápido).
Embora eu também tenha atualizado o Studio para a versão mais recente, ele também deve ter influenciado, já que até o x86 é mais rápido agora do que os testes anteriores.
Bem, agora o C++ não está tão vergonhosamente atrasado em Sharp. Apenas por 3 vezes aproximadamente )
Portanto, parece ter descoberto que ele aloca e elimina a memória toda vez que mesmo neste caso:
A propósito, posso ter dado resultados errados da última vez. O mais provável foi no modo x86. Agora estou testando no modo x64 e os resultados por C++ são muito melhores:
1) ~ 2000 msec
2) ~ 200 ms (é 3 vezes mais rápido).
Embora eu também tenha atualizado o Studio para a versão mais recente, ele também deve ter influenciado, já que até o x86 é mais rápido agora do que os testes anteriores.
Bem, agora C++ não está perdendo tão vergonhosamente para Sharp. Apenas por 3 vezes aproximadamente )
Brrr-r-rr, de jeito nenhum! Sharp sempre foi duas vezes melhor do que plz limpo, você coloca o projeto para fora do plz.
Melhor testar os módulos plus, os resultados são mais interessantes lá, embora eles ainda possam estar indocumentados.
Eu procurei, e descobri que nenhum compilador https://en.cppreference.com/w/cpp/compiler_support terminou os módulos, então não há nada para ver.