O esplendor e a pobreza da OLP - página 7

[Dmitry Fedoseev]

Encontrei-a! Afinal de contas, foi gerido para obter uma maior velocidade com a OLP. Sim! os benefícios são inegáveis.

[Dmitry Fedoseev]

dimeon:

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.

Dê uma vista de olhos nos 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!

Há aqui uma pessoa que escreve o código num ficheiro e o inclui em vez de uma função.

[Alexey Navoykov]

Integer:

Encontrei-a! Ainda conseguiu obter uma maior velocidade com a OLP. Sim! os benefícios são inegáveis.

Então, qual era o código?

[Dmitry Fedoseev]

meat:
Então, qual era o código?

Chamando iCustom() com diferente número de parâmetros, um caso diferente para cada número de parâmetros, ou uma classe diferente para cada número de parâmetros na variante OOP.

[Renat Fatkhullin]

Na nova construção do compilador MQL, já incluímos a optimização da substituição de um método virtual por uma chamada directa, se for o método final numa cadeia de métodos virtuais e não houver ligações a bibliotecas externas.

Este método irá simplificar e acelerar as chamadas virtuais para muitos programas que funcionam com aulas.

Os resultados do exemplo test.mq4 do primeiro posto na construção 670:

switch: 172
OOP:    312

O laço teve de ser aumentado de 10.000.000 para 50.000.000 a fim de não trabalhar com medidas de tempo minúsculas de 32-64 ms. O tempo em ms é mostrado, o menor número é, o código é mais rápido.

Foi isto que obtive com o novo compilador no mesmo código:

switch: 157
OOP:     93

OOP ganhou com um estrondo. Mas porquê?

Primeiro, o método virtual foi transformado num método regular, e depois foi zinlined e optimizado para zero. De facto, a chamada de função e o corpo desapareceram completamente, deixando um laço puro:

  mov     int[i] <- int[0]

$label:
                                        <- тут когда-то было тело, но оно оптимизировалось в ноль
  add     int[i] <- int[i], int[1]
  jlt     int[i], int[50000000] --> $label

Os ficheiros são anexados, incluindo o novo beta do compilador da consola. Pode comparar quaisquer exemplos usando a construção regular 670 do MetaEditor (o compilador está incorporado nele) e o compilador da consola.

O que isto prova:

1. É a qualidade do optimizador do compilador que está a ser testada.
2. Os testes devem ser realmente escritos com uma compreensão completa de como tudo é optimizado
3. Como eu disse - mostrou num exemplo existente como é possível enganar (OOP ganhou de repente), se não se conhecem as peculiaridades da optimização do código