Comment faire pour passer une énumération de manière cohérente ? - page 3

 
Alexey Navoykov:

Les exemples montrés ici (cas 1 : valeur de retour1 ; cas 2 : valeur de retour2 ; cas 3 : valeur de retour3... Une personne compétente mettrait toutes les valeurs dans un tableau et obtiendrait simplement la valeur requise par son index. Et pour la tâche inverse, elle utiliserait la recherche binaire.

Je suis à deux mains en faveur d'un code agréable avec des tableaux. Mais en écrivant un NormalizeDouble plus rapide que le normal, j'ai rencontré un effet d'optimiseur - la solution agréable via const-array était beaucoup plus lente que la solution encombrante du switch-case. J'ai laissé la deuxième variante car NormalizeDouble est beaucoup utilisé dans le testeur. Je le mets dans l'indicateur et ne regarde pas ce monstre. Mais les backtests sont plus rapides.
 
fxsaber:
Je suis à deux mains en faveur d'un code agréable avec des tableaux. Mais en écrivant un NormalizeDouble plus rapide que le normal, j'ai rencontré un effet d'optimiseur - une bonne solution via const-array était beaucoup plus lente qu'une solution encombrante via switch-case. J'ai laissé la deuxième variante car NormalizeDouble est beaucoup utilisé dans le testeur. Je le mets dans l'indicateur et ne regarde pas ce monstre. Mais les backtests sont plus rapides.

Je me souviens d'un fil de discussion sur le switch, où les développeurs ne parlaient que de l'implémentation sous forme de recherche binaire, ce qui est bien sûr beaucoup plus lent qu'un simple accès par index calculé.Mais maintenant ils semblent l'avoir fait plus judicieusement : si une étape est constante, l'index est calculé, sinon une recherche binaire est effectuée. Bien sûr, une implémentation native est toujours plus rapide qu'une implémentation wrapper.

Bien sûr, cela dépend de vos priorités. Mais je pense que si la vitesse est si cruciale que vous êtes prêt à inventer des béquilles, alors vous devriez abandonner la POO et MQL également ;) Bien que je sois sûr qu'avec un codage correct, cette différence de vitesse ne sera pas si importante. Dans les mesures de test, vous faites simplement passer la fonction dans la boucle des millions de fois. Et vous l'utilisez plus rationnellement dans le code réel, n'est-ce pas ?

 
Alexey Navoykov:

Je me souviens d'un fil de discussion sur le switch, où les développeurs ne parlaient que de l'implémentation sous forme de recherche binaire, qui est bien sûr beaucoup plus lente qu'un simple accès par index calculé.Mais maintenant ils semblent l'avoir fait plus judicieusement : si le pas est constant, alors l'index est calculé, sinon c'est une recherche binaire. Bien sûr, une implémentation native est toujours plus rapide qu'une implémentation wrapper.

Le compilateur, s'il n'est pas idiot, devrait transformer le const-array et la seule référence de type à celui-ci par l'index en code switch.

Bien sûr, vous devrez peut-être le faire en fonction de vos priorités. Mais je pense que si la vitesse est si cruciale que vous êtes prêt à inventer des béquilles, alors vous devriez abandonner la POO et MQL en général ;) Bien que je sois sûr qu'avec un codage correct, la différence de vitesse ne sera pas si importante. Dans les mesures de test, vous faites simplement passer une fonction dans une boucle des millions de fois. Et dans le code réel, vous l'utilisez de manière plus rationnelle, n'est-ce pas ?

La vitesse n'est pas cruciale, mais lorsque j'écris de manière irrationnelle, je me sens assez mal à l'aise. Ne pas utiliser la POO du tout n'est pas rationnel, bien sûr. Quoi qu'il en soit, regardez les modestes efforts en matière de kodobase que vous avez déployés et qui n'ont pas compté depuis de nombreux jours. Vous comprendrez alors où sont apparues les béquilles sous la forme du même NormalizeDouble. C'est le résultat d'un fait aléatoire issu des mises en œuvre parfois irrationnelles des développeurs.
 
fxsaber:
Le compilateur, s'il n'est pas idiot, aurait été obligé de transformer le const-array et la seule référence de type à celui-ci par index en code switch.

Donc le tableau est juste un const ? Et les statiques ? Il s'agit d'une opération simple : comparer la valeur de l'index avec la taille du tableau/enum, et si elle est inférieure, obtenir l'adresse de l'élément requis comme adresse du tableau + index, puis lire la valeur à partir de là. Je pensais qu'une telle absurdité devait se compiler également.

Quoi qu'il en soit, regardez les modestes efforts de kodobase, que j'ai exposés et que je n'ai pas comptés depuis de nombreux jours. Vous comprendrez alors où sont apparues les béquilles sous la forme de ce même NormalizeDouble. C'est le résultat d'un fait accidentel provenant des mises en œuvre parfois irrationnelles des développeurs.
Et d'ailleurs, il y a combien de temps que vous avez effectué ces comparaisons ? Peut-être que le compilateur était encore "débile" à l'époque ?
 
Alexey Navoykov:

Donc le tableau est juste un const ? Et les statiques ? Il s'agit d'une opération simple : comparer la valeur de l'index avec la taille du tableau/enum, et si elle est inférieure, obtenir l'adresse de l'élément requis comme adresse du tableau + index, puis lire la valeur à partir de là. Je pensais que de telles absurdités devaient se compiler de la même manière.

Je ne me souviens pas avec certitude si vous pouvez créer des tableaux statiques en utilisant des méthodes const - vous ne le pouvez certainement pas. Par principe, je faisais des constantes et non des statiques. Compter sur l'intelligence du compilateur. Après la compilation, il n'y aurait pas dû y avoir le moindre indice d'un tableau dans les boyaux. Un statik est une structure beaucoup plus compliquée qu'un const, j'étais donc sûr que le compilateur ne parviendrait pas à gérer le statik. Mais je devrais essayer.

Je ne comprends pas très bien ce que vous entendez par "efforts". Et d'ailleurs, il y a combien de temps que vous avez effectué ces comparaisons ? Peut-être que le compilateur était encore "débile" à l'époque ?
L'effort sera visible dès qu'un des modérateurs appuiera sur quelques boutons et donnera le feu vert pour publier le code dans kodobase. J'ai créé une solution pratique pour moi, sans penser aux performances, et elle s'est avérée être presque un ordre de grandeur meilleure dans la version 1383 32-bit.
 
fxsaber:

Je ne me souviens pas exactement si les tableaux statiques peuvent être transformés en const. méthodes - certainement pas. Par principe, je faisais des constantes, pas des statiques. Compter sur l'intelligence du compilateur. Après la compilation, il n'y aurait pas dû y avoir le moindre indice d'un tableau dans les boyaux. Un statik est une structure beaucoup plus compliquée qu'un const, donc j'étais sûr que le compilateur ne parviendrait pas à gérer le statik. Mais je devrais essayer.

Oh, bien, ça explique tout. Vous ne devriez pas vous fier à l'intelligence excessive du compilateur, qui optimise davantage une solution mal conçue pour vous. Si vous êtes vous-même trop paresseux pour le faire correctement, en disant que "la statique est beaucoup plus compliquée" (bien que ce qui est compliqué là, je ne comprends pas), alors pourquoi accuser le compilateur ?

 
Alexey Navoykov:

Oh, bien, ça explique tout. Il ne faut pas compter sur l'intelligence excessive du compilateur, car il optimisera pour vous une solution mal conçue. Si vous étiez vous-même trop paresseux / n'avez pas pensé à le faire correctement, en disant "la statique est beaucoup plus compliquée" (bien que ce qui est compliqué là, je ne comprends pas), alors pourquoi accuser le compilateur ?

J'ai ajouté static au tableau. Il a fonctionné presque trois fois plus vite que l'interrupteur ! Jetez cet interrupteur. Merci pour le conseil !
 
fxsaber:
J'ai ajouté static au tableau. Il a fonctionné presque trois fois plus vite que l'interrupteur ! Mettez ce commutateur à la poubelle. Merci pour le conseil !

De rien. Ça me servira de leçon pour l'avenir, que je devrais réfléchir 7 fois, avant de courir partout en inventant des béquilles).

Il s'avère maintenant que j'ai fait l'éloge de l'interrupteur, ou plutôt de ses développeurs, trop tôt. Ainsi, tout est implémenté par recherche binaire uniquement, même lorsque l'énumération est multiple. Pas bon.

 
Alexey Navoykov:

De rien. Ce sera une leçon pour l'avenir, de réfléchir 7 fois avant de courir et d'inventer des béquilles).

Presque quatre fois plus rapide que NormalizeDouble standard (build 1395)... est une béquille des développeurs.

 
fxsaber:
Presque quatre fois plus rapide que NormalizeDouble standard (build 1395)... est une béquille des développeurs.

Tout le monde n'est pas sans péché )