O esplendor e a pobreza da OLP - página 6
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
Mostrou que a chamada directa ou a chamada virtual não têm qualquer efeito em projectos reais.
A grande maioria dos custos são incorridos nas funções do sistema de chamadas em que os programas MQL passam quase todo o seu tempo. Os custos de organização das chamadas são insignificantes em comparação com a carga útil.
Onde é que ele mostrou? Uma tabela com alguns nomes de funções e medidas é um argumento? Não somos especialistas telepáticos aqui. É preciso ver o código de funções, e depois pode dizer alguma coisa.
Onde o mostrou? Uma tabela com alguns nomes de funções e medidas - isso é um argumento? Não somos especialistas telepáticos aqui. É preciso ver o código de funções, depois podemos falar de outra coisa.
Ele mostrou que em projectos reais, a chamada directa ou a chamada virtual não têm qualquer impacto.
A grande maioria dos custos são incorridos por chamadas de funções do sistema, onde os programas de MQL passam a maior parte do seu tempo. O custo de organizar as chamadas é insignificante em comparação com a carga útil.
+100 Sim, é verdade!
Além disso, reparei que quando tive de reescrever as classes dispersas para que algumas das suas funções fossem executadas por outras classes (inclusão/decomposição), o desempenho global aumentou e o controlo sobre o código aumentou. Por outras palavras, na prática, vemos o oposto do que os fãs do Integer e da velha escola C nos tentam provar: o número de aulas cresce, o número de métodos cresce, e o desempenho, pelo contrário, cresce.
Onde o mostrou? Uma tabela com alguns nomes de funções e medidas - isso é um argumento? Não somos especialistas telepáticos aqui. É preciso ver o código de funções, depois podemos falar de outra coisa.
+100 Sim, é isso mesmo!
Além disso, reparei que quando tive de reescrever classes dispersas para que algumas das suas funções fossem desempenhadas por outras classes (inclusão/decomposição), o desempenho global aumentou, e o controlo sobre o código aumentou. Por outras palavras, na prática, vemos o oposto do que os fãs do Integer e da velha escola C nos tentam provar: o número de aulas cresce, o número de métodos cresce, e o desempenho, pelo contrário, cresce.
Uma nova forma de auto-indulgência? Vá lá, vá lá.
Vasily, devias ter lido o que eu estava a tentar provar aqui, no entanto (e o que quer que penses sobre isso, eu provei-o).
Note, contudo, que ter o código fonte não lhe dirá nada. A complexidade acumulada não é a mesma. Mesmo depois de analisar as fontes, diria "bem, algo lá é chamado, algo é contado, algo é retirado de algum lugar, mas o que não é exactamente claro, por isso mais uma vez nada é provado".
Em geral, sim, provavelmente tem razão, as funções individuais provavelmente não lhe dirão muito. De que serve falar mesmo do seu software se é um porco no espeto para todos os outros.
De facto, o que nos interessa principalmente é o número total de passagens através de métodos virtuais, e o tempo total despendido neles. Aqui na sua mesa há alguma função sombreada executada 5 milhões de vezes. Não sei o que é, talvez seja apenas um método virtual com a acção mais simples. No entanto, 5 milhões é uma bagatela. Suponho que não tem cálculos pesados no seu programa, por isso não há muito a discutir. Suponha que estava a calcular um sistema de equações lineares 30000x300000 e a aceder aos elementos da matriz através de métodos virtuais, haveria algo de que falar.
Uma nova forma de auto-influência? Vá lá, vá lá.
Vasily, devias, afinal de contas, ler o que eu estava a tentar provar aqui (e o que quer que penses sobre isso, prova-o).
Dimitri, eu não sou nem a seu favor nem contra si. Para o compreender, é necessário conhecer o funcionamento interno do compilador em linha, mas abrir esta informação para MQ é o mesmo que ajudar a escrever um descompilador.
Dos que discutem aqui, só Renat tem tal informação, por isso temos de confiar na sua palavra. Não vejo outra forma.
Se ele disser que não está a definir o teste correctamente, provavelmente está.
A questão é diferente, só a MQ pode definir correctamente o teste em tal caso, que é o que tem de ser feito.
Como se costuma dizer teste para teste, a minha palavra contra a tua. E está a tentar provar o que não pode ser provado. É impossível provar ou refutar as suas alegações sem ter algo com que as comparar.
O descompilador está aqui fora de questão.
Basta compreender e conhecer as técnicas de optimização dos compiladores para não testar casos degenerados simplificados que são brutalmente optimizados e degenerados em código linear. Lançámos a quarta geração de compiladores por nada.
É exactamente disto que estamos a falar.
Por exemplo, se estivéssemos a calcular um sistema de equações lineares 30000x300000 e o acesso aos elementos da matriz fosse através de métodos virtuais, já há algo de que falar.
Nesses casos, a primeira refactoring dar-lhe-ia um ganho de velocidade cem vezes superior. E a chamada virtual seria classificada em décimo lugar em termos de custos.
Ou seja, o exemplo é irrealista.
Vamos então escrever tudo em linguagem de montagem. Seria mais rápido de qualquer forma.
Não compreendo o problema. Nunca vi um Expert Advisor ou indicador com 1 MB de código.
A chamada de qualquer função também leva algum tempo. Vamos também desistir de funções!
O controlo sobre grandes projectos é muito mais conveniente com o OOP.
Além disso, a velocidade de execução do código não é muitas vezes tão crítica como o tempo de pinging para o corretor e a resposta à ordem do corretor.
Verifique os algoritmos HFT. Requerem velocidade máxima, mas não encontrará aí quaisquer cálculos complexos.
PS. Normalmente não é necessário um supercarro ou uma moto de neve para passar do ponto A ao ponto B. Uma motocicleta é suficiente! Uma motocicleta é suficiente!