Théorie de l'accélération de l'EA lors de l'utilisation d'un indicateur personnalisé (fonction - iCustom)
Le compilateur peut faire beaucoup de choses, mais pas cela :-)
Et ce cas peut être optimisé. Premièrement, l'indicateur lui-même devrait être écrit intelligemment (ne pas recalculer toutes les barres à chaque tick), deuxièmement, l'indicateur devrait être super lourd, pour en quelque sorte ralentir l'EA... Pour faire une longue histoire courte...
Et voici un article intéressant sur la "Réduction de la consommation de mémoire des indicateurs auxiliaires".
J'avais un conseiller expert multidevises qui recevait des relevés d'indicateurs pour 28 symboles sur 8 périodes.
C'était 28*8=224 copies d'indicateurs... Je me suis demandé comment optimiser le processus. L'opération multidevise a consommé près de 700 Mo de RAM... J'ai résolu le problème facilement - j'ai simplement fixé une petite valeur pour le champ "Max bars in window" dans les paramètres du terminal sur l'onglet "Charts"... Autant que je me souvienne, le minimum pour ce domaine est de 5 mille bars...
- 2011.03.18
- Andrew
- www.mql5.com
J'ai mesuré l'augmentation du temps de test par un facteur de 1,2 à 1,3, ce qui est tout à fait insignifiant par rapport aux avantages donnés par les indicateurs personnalisés.
La conclusion sur les 5 tampons est fausse. Si les paramètres sont les mêmes, un seul indicateur sera chargé.
Integer:
La conclusion concernant les 5 tampons est incorrecte. Si les paramètres sont les mêmes, un seul indicateur sera chargé.
Oui, je suis d'accord.
Il y aura 5 appels de la fonction CopyBuffer() avec différents arguments (numéro de tampon). Et la copie de l'indicateur - poignée - sera la même.
L'auteur a donné un titre tapageur au sujet "Théorie de l'accélération..." mais il ne sait rien des trucs de base.
-Aleks, il y a beaucoup d'articles sur ce sujet !
Oui, je suis d'accord.
Il y aura 5 appels à la fonction CopyBuffer() avec différents arguments (numéro de tampon). Et il n'y aura qu'une seule copie de l'indicateur - poignée.
L'auteur a donné un titre tapageur au sujet "Théorie de l'accélération..." mais il ne sait rien des trucs de base.
-Aleks-, il y a beaucoup d'articles sur le thème de l'indicateur !
Denkir, je parle du travail de l'EA pendant l'optimisation, est-ce que le nombre de chandeliers sur le graphique affecte la quantité de calculs ? J'ai étudié l'article, je sais qu'il existe des variantes d'optimisation des indicateurs. Cependant, dans ce cas, je veux croire que l'indicateur est parfait et examiner la méthode de transmission des données de l'indicateur à l'EA. Je ne suis pas programmeur et j'ai du mal à vérifier l'optimalité du code de l'indicateur - tout au plus puis-je prescrire dans TOR - un décalage d'une barre et une limitation de l'historique pour les calculs.
J'ai mesuré, l'augmentation du temps de test en 1,2 - 1,3 fois, ce qui est absolument insignifiant par rapport aux avantages fournis par les indicateurs personnalisés.
Ma conclusion sur les 5 tampons n'est pas correcte. Si les paramètres sont les mêmes, un seul indicateur sera chargé.
Qu'est-ce que vous mesuriez ? Et 30%, ce n'est pas si peu pour moi.
A propos des 5 tampons, si je vous ai bien compris, alors avec les mêmes paramètres d'entrée de l'indicateur, le calcul est effectué pour un seul indicateur alors que le Conseiller Expert appelle le dernier plusieurs fois et obtient des informations de différents tampons ?
Si c'est le cas, alors la combinaison d'indicateurs personnalisés devrait accélérer le travail du conseiller expert ? Par exemple, il est possible d'implémenter dans un indicateur la logique de différents indicateurs avec des paramètres indépendants, lorsque l'un d'entre eux est appelé, les informations de tous les tampons sont reçues en même temps et utilisées en cas de demande d'informations d'un autre tampon avec les mêmes paramètres ?
VDev:
J'ai essayé de mesurer la vitesse d'appel des indices embarqués et de leurs analogues à travers iCustom. Ceux qui sont intégrés sont environ 20 à 50 % plus rapides. Très probablement parce qu'ils sont écrits en C++ et non en MQL.
Article extrêmement intéressant "Price series averaging without additional buffers for intermediate calculations " par GODZILLA.
Il a été écrit en 2010.
Il y a une section 3. Comparaison de l'indicateur obtenu en utilisant des classes avec ses analogues avec des appels d'indicateurs techniques et personnalisés dans le code.
- 2010.10.25
- Nikolay Kositsin
- www.mql5.com
Oui, je suis d'accord.
Il y aura 5 appels à la fonction CopyBuffer() avec différents arguments (numéro de tampon). Et il n'y aura qu'une seule copie de l'indicateur - poignée.
L'auteur a bruyamment appelé le sujet "Théorie de l'accélération..." et il n'a pas la moindre idée de ce qui est fondamental.
-Aleks-, il y a beaucoup d'articles sur le thème de l'indicateur !
Et vous pouvez simplement réfuter mon hypothèse (sur 4, de préférence), en confirmant mes propos par des chiffres ?
Le sujet porte sur ma théorie - le titre est correct :)
Denkir, je parle de la performance de l'EA pendant l'optimisation, est-ce que le nombre de bougies sur le graphique affecte la quantité de calculs ?
-Aleks-, à propos du testeur Vous devez demander au développeur ...
Mais je pense qu'il y a un problème avec les termes utilisés dans la discussion. Que voulez-vous, réduire la vitesse des calculs ou économiser de la RAM pour travailler avec l'indicateur ?
-Aleks-, à propos du testeur. Vous devez demander aux développeurs...
Mais à mon avis, il y a un problème avec les termes utilisés dans la discussion. Que voulez-vous, réduire la vitesse des calculs ou économiser de la RAM pour travailler avec l'indicateur ?
Il me semble que ma méthode permettra de résoudre ces deux problèmes. Je peux me tromper.
Lors de l'optimisation, la vitesse est importante, mais une fois que la RAM est encombrée, là encore, d'après mes observations, la vitesse de traitement par passage diminue.
Quelqu'un peut-il comparer la vitesse de cette approche, y a-t-il un raisonnement derrière ?
Cette approche réduira la consommation de mémoire de l'indicateur (environ un multiple de la différence entre le nombre de tampons avant et après), mais augmentera la charge sur le processeur (l'"assemblage" et la "décomposition" doivent être effectués constamment).
Et si l'indicateur a 5 tampons, alors le premier appel de iCustom calculera tous les tampons, les appels suivants et les demandes d'autres tampons ne liront que les informations prêtes (jusqu'à l'apparition de nouvelles données pour le calcul).
Si vous avez un indicateur vraiment lourd, pensez à votre propre système de cache, de sorte qu'au premier appel, les données sont calculées et écrites dans le fichier, et aux appels suivants, elles sont en lecture seule. Je l'ai fait de cette façon, c'est beaucoup plus rapide.
Mais dans 95% des cas, tout cela n'est pas nécessaire, le testeur est assez rapide comme ça, et dans 5 cas, vous pouvez également connecter le cloud.
Bonne chance !
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Je commencerai par dire que je ne suis pas un programmeur et que je peux me tromper, mais j'aimerais avoir l'avis d'un professionnel sur l'idée proposée ci-dessous, basée sur des calculs.
L'utilisation d'indicateurs personnalisés est une question d'actualité lors du développement d'un Expert Advisor en plusieurs étapes. C'est particulièrement important lorsque les programmeurs se remplacent les uns les autres, et il est alors préférable de coller une partie de la logique du conseiller expert dans l'indicateur - de tester la logique (pour vérifier les calculs et leur pertinence), puis de travailler sur une nouvelle partie de l'idée. En conséquence, nous obtenons un conseiller expert pas très complexe qui demande réellement des informations à l'indicateur et prend une décision en comparant les données attendues et réelles.
Mais cette approche présente un inconvénient de taille : la vitesse d'un tel conseiller expert. Le fait est que plus les données sont demandées aux indicateurs personnalisés, plus le calcul est lent et plus l'optimisation nécessite de ressources (mémoire).
Pour l'instant, je travaille en MT4, mais le principe, tel que je le comprends, est le même.
Et le problème n'est pas dans la vitesse de calcul de l'indicateur iCustom lui-même, mais dans sa connexion avec le Conseiller Expert.
Supposons que l'indicateur utilise 5 tampons de graphique et que l'EA a besoin d'informations provenant de ces tampons, alors il doit utiliser 5 fonctions iCustom dans son code et placer réellement 5 indicateurs sur le graphique au lieu d'un seul, ce qui nécessite 5 fois plus de ressources. Peut-être que je me trompe, et que le compilateur analyse cette circonstance - il calcule pour un indicateur et donne à toutes les fonctions les données pour les tampons requis en une seule fois ? Dans ce cas, mes autres spéculations sont vaines.
Mais, si ce n'est pas le cas, pourquoi ne pas fusionner les informations de l'indicateur en un seul pack ?
Je propose de faire une expérience sur ce sujet en mesurant la performance du Conseiller Expert.
Pour cela, il faut prendre un indicateur personnalisé avec plus d'un tampon et ajouter un tampon supplémentaire.
L'algorithme est logique (pas mathématique) :
1. Convertir les tampons de l'indicateur en nombres entiers, en fonction des chiffres par numéro, un total de 3 tampons, était : 1,21101 ; 1,13 ; 5, est devenu : 121101;113;5
2. On compte combien de chiffres il faut mettre après le premier chiffre - dans notre cas 4, puis dans le chiffre suivant le chiffre suivant est 1, ces valeurs sont le degré du multiplicateur :
1,21101*10^4=1211010000
1.13*10^1=113
5*10^0=5 (vérifier pour 0)
3. Additionnez les chiffres et obtenez 1211011135.
4. Ecriture de la valeur dans le tampon 4.
5. Nous demandons les 4 indicateurs tampons dans l'Expert Advisor et décomposons la valeur en composants dans l'ordre inverse et obtenons 3 chiffres qui peuvent être utilisés ultérieurement pour le travail de l'Expert Advisor.
Quelqu'un peut-il comparer la vitesse de cette approche, y a-t-il un raisonnement derrière ?