Erros, bugs, perguntas - página 2315
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
Porque é o by_ref mais lento que o by_val?
De onde se segue?
Se o código for o mesmo
o resultado também o faz (diferença de tempo de execução):
+12.221:0
+5.099:0
+0.149:0
-13.729:0
+14.531:0
-27.429:0
+26.405:0
-0.839:0
+5.400:0
-4.882:0
alternando (+\-) dentro de limites insignificantes
De onde é que vem?
Queria pôr uma nota no KB e não funcionou. E a julgar pelo facto de as publicações recentes não terem quaisquer notas, parece que não sou o único com este problema.
Sim, não está a funcionar.
Nos meus loops ref e val têm o mesmo código (a comparação é mais ou menos correcta), enquanto que o seu é diferente
Sim, diferente. Mas a questão permanece válida. Por que é que a val-variante é visivelmente mais rápida do que a ref?
Sim, diferente. Mas a questão permanece válida. Porque é que a variante val-variante é visivelmente mais rápida do que a ref?
Talvez a variante ref seja menos optimizada pelo compilador - quem sabe.
Na minha opinião, ambas as variantes devem compilar quase o mesmo código ou mesmo completamente o mesmo código, mas o compilador trata as coisas de forma diferente
Talvez a variante ref seja pior optimizada pelo compilador - quem sabe.
Parece-me que ambos deveriam compilar aproximadamente o mesmo código ou mesmo exactamente o mesmo, mas o compilador pensa de forma diferente
A questão foi na realidade dirigida aos promotores, de modo que existe uma base para discrepâncias nas razões das discrepâncias.
Normalmente tento passar tudo por referência de velocidade. E isto foi justificado em algumas construções. Mas parece-me que agora.
+1. Algo parece estar partido. Bild 1881 x64. Ganhar 10. Em cargas de arranque de CPU por 20+% (i5 8600k) e RAM por 650-700mb (sem aumento).
O gestor de tarefas mostra o estado de "Não responder".
E o outro terminal 1881 (não Abertura) funciona bem.
Adicionado:
Acabou por arrancar. Contudo, demorou muito tempo a arrancar - isso não é normal. Depois fechei o terminal e abri-o novamente. Aberto instantaneamente. Aparentemente, houve algum problema com o carregamento de dados.
A solução foi a de reinstalar o terminal. Também apaguei acidentalmente a pasta com todas as definições e gráficos) desenhei tudo novamente, mas agora funciona como um relógio.
Isto não foi necessário. Poderia simplesmente ter apagado o ficheiro news.dat.
Talvez a variante ref seja pior optimizada pelo compilador - quem sabe?
Na minha opinião, ambas as opções devem compilar aproximadamente o mesmo código ou mesmo completamente o mesmo código, mas o compilador conta de uma forma diferente
Qual é a ligação entre o código final e o seu tempo de execução?
Por exemplo, vamos mudar . .. para que os loops se tornem absolutamente idênticos
O resultado..:
by_ref levou 18354.547 milissegundos: soma=1865600ll
por_val levou 18318,319 milissegundos: soma=1861628ll
by_ref levou 18416,747 milissegundos: soma=1904488ll
by_val levou 18221.978 milissegundos: soma=1907860ll
by_ref levou 18301.009 milissegundos: soma=1757988ll
por_val levou 18545,258 milissegundos: soma=1949720ll
by_ref levou 18373,648 milissegundos: soma=1867160ll
by_val levou 17972.432 milissegundos: soma=1760308ll
by_ref levou 19426.076 milissegundos: soma=1795564ll
by_val levou 19177,485 milissegundos: soma=1826360ll
é mais ou menos o mesmo... Ou pensa que o compilador criou códigos diferentes nos mesmos loops?
Deixem-me lembrar-vos - havia algo parecido com isto
by_ref levou 13889,424 milissegundos: soma=-1000000ll
by_val levou 14135,603 milissegundos: soma=-1000000ll
e código diferente... e há aproximadamente a mesma diferença no tempo, mas o código e as próprias funções são exactamente as mesmas