Sujet intéressant pour beaucoup : les nouveautés de MetaTrader 4 et MQL4 - de grands changements en perspective - page 69
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
Avez-vous déjà analysé les codes de hrenfx(getch dans une vie antérieure) ? Je vous recommande vivement de parcourir tous ses travaux dans le 4e forum kodobase et d'en analyser soigneusement deux ou trois pour bien comprendre les algorithmes. Et je recommande vivement à toute votre brigade de "personnes du plus haut niveau de professionnalisme" de faire de même. Peut-être devriez-vous être moins illusoire sur les capacités intellectuelles d'Ivan et commencer à améliorer vos propres compétences.
Vous n'avez rien montré en chiffres, vous avez trois ticks dans les barres, alors que lui n'a qu'un tick dans chacune - seulement LoAsk et HiBid - ce qui est exactement ce qu'il a propagé ici pendant très longtemps. Donc si vous enlevez deux comparaisons inutiles de la boucle et désactivez les contrôles de plage dans le compilateur (RangeCheck), alors le chiffre indiqué semble déjà assez réaliste, même avec des calculs utiles (minimaux) à l'intérieur de la boucle.Certains des codes hrenfx que j'ai rencontrés - le code est de très haute qualité, je ne peux rien dire. J'en utilise encore certains. Mais ne mélangez pas les mouches avec les escalopes. Vous, comme Gerica, écrivez sans même comprendre le test que je propose. Soit par manque de connaissances approfondies du C, soit pour une autre raison, vous insistez sur le fait qu'une barre pour hrenfx ne représente que deux entiers longs. En réalité, nous transmettons un pointeur vers la structure décrivant la barre ; la structure elle-même n'est pas transmise par valeur, ce qui signifie que l'activation et la désactivation du nombre d'éléments dans la barre n'affectera en rien les performances. Notez que je parle du temps de performance de la strate elle-même, je ne tiens pas compte du temps de remplissage du tableau.
Voici le résultat des performances si vous ne laissez qu'une seule valeur dans la structure elle-même :
C'est-à-dire qu'en effet, le temps de déploiement d'une structure légère, constituée d'une seule valeur longue, a diminué plusieurs fois, passant de 9 secondes à 2,35, mais le temps d'exécution lui-même est resté pratiquement le même (il a même légèrement augmenté, car j'ai commencé à appeler rand() dans la vérification if). Si le moteur délègue l'exécution au stratège, ce qui se produit en réalité, le temps d'exécution devient encore plus long et la taille de la barre de description de la structure n'a absolument rien à voir avec cela.
Donc, si vous devez répéter quelque chose, étudiez d'abord C - ensuite nous aurons quelque chose à discuter.
En d'autres termes, il est vrai que le temps de déploiement d'une structure légère constituée d'une seule valeur longue a considérablement diminué, passant de 9 secondes à 2,35 secondes, mais le temps d'exécution lui-même est resté pratiquement le même.
Et si vous divisez par 8 (cœurs) ?
Et si on le divise par 8 (cœurs) ?
Certains des codes hrenfx me sont apparus - le code est de très haute qualité, je ne peux rien dire. J'en utilise encore certains. Mais ne mélangez pas les mouches avec les escalopes. Vous, comme Gerica, écrivez sans même comprendre le test que je propose. Soit par manque de connaissances approfondies du C, soit pour une autre raison, vous insistez sur le fait qu'une barre pour hrenfx ne représente que deux entiers longs. En réalité, nous transmettons un pointeur vers la structure décrivant la barre ; la structure elle-même n'est pas transmise par valeur, ce qui signifie que l'activation et la désactivation du nombre d'éléments dans la barre n'affectera en rien les performances. Notez que je parle du temps de performance de la strate elle-même, je ne tiens pas compte du temps de remplissage du tableau.
Voici le résultat des performances si vous ne laissez qu'une seule valeur dans la structure elle-même :
C'est-à-dire qu'en effet, le temps de déploiement d'une structure légère, constituée d'une seule valeur longue, a diminué plusieurs fois, passant de 9 secondes à 2,35, mais le temps d'exécution lui-même est resté presque le même (il a même légèrement augmenté, car j'ai commencé à appeler rand() dans la vérification if). Si le moteur délègue l'exécution au stratège, ce qui se produit effectivement, le temps d'exécution devient encore plus long et la taille de la structure décrivant la barre n'y est absolument pour rien.
Donc, si vous devez répéter quelque chose, étudiez le C pour commencer et nous aurons alors quelque chose à discuter.
Je ne veux pas discuter de l'écart constaté moins de deux fois, // qui peut être imputé, par exemple, à des différences de compilateurs et de processeurs.
Les performances d'Ivan sont proches des performances réelles, pour des stratégies légères, et c'est assez motivant pour écrire des "calculateurs" simples pour chacune de ses stratégies.
Pour cela la productivité est énorme par rapport à un mashup universel de testeur régulier. C'est exactement ce qu'Ivan voulait dire, et pas à Renat, mais à vous, moi et d'autres "utilisateurs" qui attendent "sous la mer du temps".
pas un programmeur, en seulement cinq heures.
Non, hrenfix a un testeur single-threaded, c'est écrit dans son post.
Je ne me souviens pas qu'il ait dit qu'il n'était pas un programmeur, mais il est depuis longtemps connu ici comme un programmeur parmi d'autres.
1) ...... Mais il est également précisé qu'il a été réalisé, pour ainsi dire, avec un demi-bang, par un non-programmeur, en seulement 5 heures.
2) Et nous ne saurons pas avant longtemps si hrenfx parlait de performances en mode multithread ou single-thread.
1) Le résultat a été obtenu en cinq heures par un homme qui n'écrit pas le testeur pour la première fois, c'est-à-dire un "non-programmeur" très expérimenté. Par exemple,un de ses exploits, vieux de trois ans déjà.
2) Lisez plus attentivement le message original et vous le découvrirez tout de suite. "la manivelle n'est pas un lecteur..." ? ;)