Lo splendore e la povertà dell'OLP - pagina 7

[Dmitry Fedoseev]

Trovato! Alla fine sono riuscito a ottenere una velocità maggiore con l'OLP. Sì, i benefici sono innegabili.

[Dmitry Fedoseev]

dimeon:

Allora scriviamo tutto in linguaggio assembly. Sarebbe comunque più veloce.

Non capisco il problema. Non ho mai visto un Expert Advisor o un indicatore con 1 MB di codice.

Anche la chiamata di qualsiasi funzione richiede del tempo. Rinunciamo anche alle funzioni!

Il controllo di grandi progetti è molto più conveniente con OOP.

Inoltre, la velocità di esecuzione del codice spesso non è così critica come il tempo di ping al broker e la risposta del broker su un ordine.

Controlla gli algoritmi HFT. Richiedono la massima velocità, ma non vi troverete calcoli complessi.

PS. Di solito non hai bisogno di una supercar o di una motoslitta per andare dal punto A al punto B. Un motorino è sufficiente! Un motorino è sufficiente!

C'è una persona qui che, invece di scrivere una funzione, scrive codice nel file e lo include.

[Alexey Navoykov]

Integer:

Trovato! Alla fine sono riuscito a ottenere una velocità maggiore con l'OLP. Sì, i benefici sono innegabili.

Quindi qual era il codice?

[Dmitry Fedoseev]

meat:
Allora, qual era il codice?

Chiamare iCustom() con un numero diverso di parametri, un caso diverso per ogni numero di parametri, o una classe diversa per ogni numero di parametri nella variante OOP.

[Renat Fatkhullin]

Nella nuova build del compilatore MQL, abbiamo già incluso l'ottimizzazione di sostituire un metodo virtuale con una chiamata diretta se è il metodo finale in una catena di metodi virtuali e non ci sono collegamenti a librerie esterne.

Questo metodo semplifica e velocizza le chiamate virtuali a molti programmi che lavorano con le classi.

I risultati dell'esempio test.mq4 dal primo post nella build 670:

switch: 172
OOP:    312

Il ciclo ha dovuto essere aumentato da 10.000.000 a 50.000.000 per evitare di lavorare con misure di tempo minuscole di 32-64 ms. Viene mostrato il tempo in ms, più piccolo è il numero, più veloce è il codice.

Questo è ciò che ho ottenuto con il nuovo compilatore sullo stesso codice:

switch: 157
OOP:     93

OOP ha vinto con un botto. Ma perché?

In primo luogo, il metodo virtuale è stato trasformato in un metodo regolare, e poi è stato delineato e ottimizzato a zero. Infatti, la chiamata di funzione e il corpo sono scomparsi completamente, lasciando un ciclo puro:

  mov     int[i] <- int[0]

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

I file sono allegati, compresa la nuova beta del compilatore per console. Puoi confrontare qualsiasi esempio usando la normale build 670 di MetaEditor (compilatore incorporato) e il compilatore della console.

Cosa dimostra questo:

1. È la qualità dell'ottimizzatore del compilatore che viene testata.
2. I test dovrebbero effettivamente essere scritti con una piena comprensione di come tutto è ottimizzato
3. Come ho detto - ha mostrato su un esempio esistente come è possibile ingannare (OOP improvvisamente vinto), se non si conoscono le peculiarità di ottimizzazione del codice