AMD ou Intel ainsi que la marque de la mémoire - page 50
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
J'ai peur de vous décevoir, mais les résultats de performance de ce scénario sont encore moins pertinents que ceux du premier scénario. Le fait est que la plupart des compilateurs calculent les expressions du type de celles que vous voyez ici au moment de la compilation (puisqu'il n'y a aucun intérêt à évaluer ce qui peut l'être à l'avance). C'est-à-dire que le code à l'intérieur des boucles est équivalent à quelque chose comme ceci : Int = 120 et Double = 120.0. C'est-à-dire que rien d'utile n'est fait du tout. Et si vous remplacez le code à l'intérieur des boucles par ce que j'ai écrit, le résultat restera le même (vérifiez par vous-même). En fait, il mesure les frais généraux de l'organisation en boucle. Le résultat dans le second cas est un peu plus petit car la saisie de Double (8 octets) est un peu plus longue que celle de Int (4 octets).
Et si dans le premier script, la gestion des tableaux (la partie la plus longue) reflétait au moins d'une certaine manière les performances du sous-système de mémoire (et du bus avec les caches), ce test mesure en général des "chevaux sphériques dans le vide" et montre des résultats qui ne sont pas vraiment des perroquets.
joo, j'espère ne pas vous offenser. :)
Hmm, peut-être, et très probablement vous avez raison. Dans ce cas, il faut soit créer des branches complexes et astucieuses dans le code, soit fournir au CPU des chiffres qu'il ne peut pas "connaître" à l'avance : les guillemets. Comme ce conseiller expert non commercial https://forum.mql4.com/ru/25722/page41 :(
Le fait de changer la priorité en temps réel dans ce test a modifié le classement d'un peu plus de 1%.
Le test donne une stabilité à 104.8311. Il doit pleuvoir. Je pense que couper l'internet avec l'antivirus est un peu bizarre. Il est plus facile de donner la priorité en temps réel au terminal.
L'antivirus normal fonctionne comme un service sur le système, et ne pas obtenir de ressources peut bloquer l'ordinateur.
Hmm, peut-être, et très probablement vous avez raison. Dans ce cas, il faut soit créer des branches complexes et astucieuses dans le code, soit fournir au CPU des chiffres qu'il ne peut pas "connaître" à l'avance : les guillemets. Comme ce conseiller expert non commercial https://forum.mql4.com/ru/25722/page41 :(
Avez-vous essayé d'insérer Int = 120 et Double = 120 ? :)
Je propose la solution suivante.
Utilisez le conseiller expert ci-joint pour tester les performances plus ou moins réelles.
Il s'agit de la même moyenne mobile que celle utilisée auparavant, mais elle a exclu la fonction de calcul du lot. Il ouvre toujours des positions à 0,1 lot.
Effectuez le test en utilisant les prix d'ouverture. Le test porte sur la période du 15.09.08 au 15.09.09.
Le solde est de 1 000 000 de dollars. Il est donc certain qu'il n'y a pas eu d'appel de marge en cas d'effet de levier et d'exigences de marge. Pour cela, le lot permanent est de 0,1.
J'ai augmenté le nombre de passages en diminuant l'étape du MovingShift. Cela permettra d'atténuer les "à-coups" occasionnels de la charge sur le processeur, à mon avis.
Mon résultat est de 7:08 avec les résultats insignifiants désactivés, et de 7:11 avec eux. Peut-être que ce n'est pas un gros problème, mais juste l'influence de la charge de fond.
Vérifions cette EA. Les résultats de begemot61 et de four2one sont particulièrement intéressants.
Docent, tout le monde ici ne comprend pas la langue. Veuillez poster l'expert vous-même, afin qu'il n'y ait pas de divergences.
OK, je vais le poster moi-même. J'ai juste commenté les calculs dans la fonction de calcul du lot.
Mon résultat est 9:10 (les résultats inutiles sont affichés). En considérant les fréquences, les résultats du ff sont les suivants :
431*3 = 1293 (le vôtre).
550*2,53 = 1391,5 (le mien).
La différence est de 7,6 % en votre faveur.
J'ai supprimé le fichier. C'est un peu plus rapide sur le tien - 9:05.
Docent, tout le monde ici ne comprend pas la langue. Veuillez afficher le conseiller expert lui-même, afin qu'il n'y ait pas de confusion ici non plus.
Il est en fait joint ci-dessous avec le fichier de paramètres dans l'archive...
Juste pour avoir 1 fichier, pas 2.
Veuillez vérifier avec le mien - il pourrait y avoir une différence.
Et attendre les résultats des autres.
>> Quelles applications exactement ?
Sur une tâche de calcul lourde, à l'origine multiprocesseur.
Data (ancien script) sur Atom.
Je propose la solution suivante.
Utilisez le conseiller expert ci-joint pour vérifier les performances plus ou moins réelles.
Il s'agit de la même moyenne mobile que précédemment, mais elle a exclu la fonction de calcul du lot. Il ouvre toujours des positions à 0,1 lot.
Le solde est de 1 000 000 $. Ainsi, avec tout effet de levier et toute exigence de marge, il n'y a pas d'appel de marge. Pour cela, le lot permanent est de 0,1.
J'ai augmenté le nombre de passes en réduisant le pas de MovingShift. Cela permettra d'atténuer les "à-coups" occasionnels de la charge sur le processeur, à mon avis.
Je suis d'accord. Le script était à l'origine un "cheval sphérique". Nous avons besoin de résultats plus proches de la réalité. Vos changements dans l'EA et les paramètres initiaux semblent raisonnables.
Mon résultat est de 7:08 avec les résultats insignifiants désactivés, et de 7:11 avec eux. Peut-être que ce n'est pas si important, mais juste l'effet de la charge de fond.
Je laisserais la sortie complète. Ce nombre fluctuera en fonction des conditions de la DC particulière. Tous ne le sont pas.
En général, vous pouvez éliminer complètement l'influence du DC - il existe un programme qui vous permet de définir n'importe quel écart. Et nous pouvons exclure l'influence des différents historiques, il suffit d'inclure l'historique du symbole dans les archives avec l'expert du test. En outre, il est clair : terminal hors ligne, réglage de l'étalement, importation de l'historique depuis les archives et le test.
Concernant l'article. Tant que la méthodologie n'est pas affinée et que les statistiques ne sont pas collectées, il n'y a rien à dire. Il serait possible de créer quelque chose comme une page sur le net avec un formulaire à remplir par le visiteur. Il y a aussi une archive avec la méthodologie, le conseiller, l'histoire, etc. Nous devrons y réfléchir. Il serait intéressant de le placer sur le site du forum lui-même. Mais c'est au-delà de nos capacités.