Erreurs, bugs, questions - page 2285
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Eh bien, regardez. Je viens de mesurer la vitesse de lecture et d'écriture de mon SDD. Il s'est avéré que le temps d'écriture et de lecture de 8 octets (1 type de valeur double ou datetime ou long) ~ 48 ns. Et selon mes calculs, le temps de lecture de 8 octets d'information à partir d'un tableau emballé est de 1-2 ns. Ainsi, alors que nous perdons 1-2 ns sur l'accès à un élément de structure, nous gagnons 48*0,8 = 38 ns pour l'écriture et la lecture du disque. De plus, nous avons multiplié par 5 la mémoire et l'espace disque, sans parler du disque dur.
Je ne le conteste pas. Il y a 4 ans, nous avons eu une discussion avec Renat sur ce sujet, à l'époque où les disques SSD étaient encore peu répandus et où la grande majorité des utilisateurs utilisaient des disques durs lents.J'ai donc essayé (avec l'exemple de mon SSD) de le convaincre que le fonctionnement du disque dur est le maillon le plus lent du système et que nous devrions essayer de minimiser la quantité de données qu'il consomme, et non l'inverse. Mais il avait des arguments tels que : pas besoin de surcharger le CPU avec du travail supplémentaire, et vous êtes tous des idiots, vous ne comprenez rien, etc. En général, tout est comme d'habitude)
C'est vrai, la SSD s'est considérablement accélérée de nos jours.
Il s'avère quele temps d'écriture et de lecture est de 8 octets .
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
Bugs, bugs, questions
fxsaber, 2018.09.10 21:28
D'abord, le journal d'optimisation.
Tester optimization finished, total passes 714240 Statistics optimization done in 7 hours 31 minutes 06 seconds Statistics local 714240 tasks (100%), remote 0 tasks (0%), cloud 0 tasks (0%) Core 1 connection closed Core 2 connection closed Core 3 connection closed Core 4 connection closed Core 5 connection closed Core 6 connection closed Core 7 connection closed Core 8 connection closed Tester 714240 new records saved to cache file 'tester\cache\Test.FILTER_EURUSD.rann_RannForex.M1.20180226.20180909.40.2D734373DF0CAD251E2BD6535A4C6C84.opt'Pendant ces 7,5 heures, le SSD a été consulté avec une fréquence énorme. Si les tics ont été lus à chaque passage, cela revient à une moyenne de 26 fois par seconde pendant 7,5 heures. D'où un clignement d'œil aussi sauvage - plus de 700 000 lectures.
Journal d'une seule exécution
Comme on le voit, ~130K ticks et 60K barres sont utilisés (le mode "Historique complet" est sélectionné dans le Testeur). C'est-à-dire une très petite quantité d'histoire.
L'historique des symboles personnalisés dans le terminal contient la quantité suivante de données historiques
C'est-à-dire que dans l'histoire du symbole est très peu plus que le Testeur utilise.
ZS C'est une honte de regarder la DSS... Combien plus rapide pourrait être l'Optimise ? Il est étrange que le système d'exploitation ne mette pas ces données en cache, car elles représentent moins de 7 Mo de ticks sous forme non compressée.
Quel dossier de Terminal via mklink vers le disque RAM, pour que les données ne soient pas lues/écrites depuis le SSD, mais depuis la mémoire ? Je suis prêt à fournir les données, quel genre d'accélération cela donnerait dans l'optimisation.
Oui, c'est de l'archivage. Si je comprends bien, maintenant les ticks et les barres de minutes sont stockés sans emballage, c'est-à-dire que pour une barre(structure MqlRates) il s'agit de 60 octets, et pour un tick(structure MqlTick) de 52 octets.
C'est horrible ! Il y a longtemps que quelque chose doit être fait à ce sujet.
Je comprends que le principal problème des tableaux compressés est l'organisation d'un accès rapide à chaque élément du tableau.
Mais même si nous ne stockons que chaque 256ème élément d'un tableau non emballé et que nous ne stockons dans les autres éléments que des incréments par rapport aux éléments non emballés, nous pouvons constater que la taille du tableau sera 4 à 5 fois plus petite et que le temps d'accès à chaque élément n'augmentera pas trop (peut-être 1 à 2 nanosecondes), mais nous gagnerons un temps énorme sur la sauvegarde et la lecture du tableau depuis le disque et vers le disque.
"Tout a déjà été volé avant vous" (cz)
Au début de la journée, c'est une coche complète. Ensuite, l'offre et/ou la demande et/ou l'offre complète, tout le reste en incréments si disponible. Une moyenne de 10 octets par tic.
Puisque l'accès aux ticks est strictement séquentiel, il n'y a aucun problème pour organiser un accès rapide à chaque élément du tableau.
Une grosse demande pour afficher la source de l'enregistrement "Tester\cache\*.opt". Vous pouvez constater, à la lecture du contenu, que le format est très simple.
Le travail avec les résultats de l'optimisation est très nécessaire. Merci !
Pour une raison quelconque, les performances du testeur diminuent lorsque le nombre de transactions augmente. Il n'y a aucune référence à l'historique des transactions de la part du conseiller expert.
Cela ne semble pas être le cas.
Dans le Testeur, l'intervalle correspondant au mode "Tout l'historique" est mémorisé. J'ajoute l'historique au symbole personnalisé, je recharge le terminal, et l'intervalle correspondant à "Historique complet" reste inchangé.
Je ne peux pas modifier le mode par défaut, mais si je sélectionne l'historique complet, je le règle manuellement. Veuillez corriger.
Il manque une croix à l'endroit marqué - suppression de la ligne correspondante de l'entrée du cache.
Je fais beaucoup d'optimisations. Certaines sont périmées depuis longtemps. Et il n'existe aucun mécanisme permettant de supprimer ces options. Parfois, vous obtenez une liste énorme et vous commencez à chercher parmi des variantes inutiles.
Veuillez donc envisager de supprimer les données inutiles en faisant une croix à l'endroit indiqué dans l'image.
Erreur pendant l'exécution
Résultat : vrai:faux:7:4
Comment se fait-il que des cordes de longueurs différentes soient soudainement égales ? Alors que la comparaison utilisant StringCompare donne le résultat opposé ==.
Merci pour ce message, nous avons modifié le comportement de la comparaison des chaînes de caractères caractère par caractère.
Auparavant, les chaînes de caractères étaient comparées comme des chaînes de caractères Z (jusqu'au caractère nul), maintenant elles sont comparées comme des chaînes de caractères PASCAL (en tenant compte de la longueur).
Les codes existants avec des chaînes "normales" (sans caractère Z à l'intérieur) ne seront pas affectés par ce changement.
Merci pour le message,
Que dois-je en faire ?
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Erreurs, bugs, questions
A100, 2018.09.01 15:25
Erreur d'exécution : Impossible de trouver 'g' dans 'Test2.ex5'.
Et si vous supprimez la ligne avec (*) dans Test1.mq5, c'est OK. Comment cela l'affecte-t-il ? Construire 1881\32
Ce n'est pas l'erreur de compilation habituelle - le programme ne démarre pas (et ArrayPrint n'est là qu'à titre d'exemple - vous pouvez le remplacer par une autre fonction appropriée).
Après tout, cette erreur a déjà été découverte il y a un an... Il a été réparé plusieurs fois, mais il réapparaissait toujours. Et ça ne marche pas ici non plushttps://www.mql5.com/ru/forum/1111/page2131#comment_6575893