La splendeur et la pauvreté de l'OLP - page 7

[Dmitry Fedoseev]

Je l'ai trouvé ! J'ai réussi à obtenir une vitesse plus élevée avec le PLO après tout. Oui ! Les avantages sont indéniables.

[Dmitry Fedoseev]

dimeon:

Écrivons tout en langage assembleur alors. Ce serait plus rapide de toute façon.

Je ne comprends pas le problème. Je n'ai jamais vu un conseiller expert ou un indicateur avec 1 MB de code.

L'appel d'une fonction prend également un certain temps. Renonçons aussi aux fonctions !

Le contrôle des grands projets est beaucoup plus aisé avec la POO.

En outre, la vitesse d'exécution du code n'est souvent pas aussi importante que le temps de transmission au courtier et la réponse de ce dernier à un ordre.

Regardez les algorithmes HFT. Ils exigent une vitesse maximale, mais vous n'y trouverez pas de calculs complexes.

PS. En général, on n'a pas besoin d'une supercar ou d'une motoneige pour se rendre d'un point A à un point B. Un cyclomoteur suffit ! Un cyclomoteur suffit !

Il y a une personne ici qui, au lieu d'écrire une fonction, écrit du code dans le fichier et l'inclut.

[Alexey Navoykov]

Integer:

Je l'ai trouvé ! J'ai réussi à obtenir une vitesse plus élevée avec le PLO après tout. Oui ! Les avantages sont indéniables.

Alors quel était le code ?

[Dmitry Fedoseev]

meat:
Alors, quel était le code ?

Appeler iCustom() avec un nombre différent de paramètres, un cas différent pour chaque nombre de paramètres, ou une classe différente pour chaque nombre de paramètres dans la variante OOP.

[Renat Fatkhullin]

Dans la nouvelle version du compilateur MQL, nous avons déjà inclus l'optimisation consistant à remplacer une méthode virtuelle par un appel direct si elle est la dernière méthode d'une chaîne de méthodes virtuelles et qu'il n'y a pas de liens vers des bibliothèques externes.

Cette méthode simplifiera et accélérera les appels virtuels à de nombreux programmes qui travaillent avec des classes.

Les résultats de l'exemple test.mq4 du premier post dans le build 670 :

switch: 172
OOP:    312

La boucle a dû être augmentée de 10 000 000 à 50 000 000 afin de ne pas travailler avec des mesures de temps minuscules de 32-64 ms. Le temps en ms est indiqué, plus le chiffre est petit, plus le code est rapide.

Voici ce que j'ai obtenu avec le nouveau compilateur sur le même code :

switch: 157
OOP:     93

OOP a gagné avec un bang. Mais pourquoi ?

Tout d'abord, la méthode virtuelle a été transformée en méthode régulière, puis elle a été inline et optimisée à zéro. En fait, l'appel et le corps de la fonction ont complètement disparu, laissant une pure boucle :

  mov     int[i] <- int[0]

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

Les fichiers sont joints, y compris la nouvelle version bêta du compilateur de la console. Vous pouvez comparer tous les exemples en utilisant la version normale 670 de MetaEditor (le compilateur y est intégré) et le compilateur de la console.

Ce que cela prouve :

1. C'est la qualité de l'optimiseur du compilateur qui est testée.
2. Les tests devraient en fait être écrits en comprenant parfaitement comment tout est optimisé.
3. Comme je l'ai dit - j'ai montré sur un exemple existant comment il est possible de se tromper (la POO a soudainement gagné), si vous ne connaissez pas les particularités de l'optimisation du code.