AMD ou Intel ainsi que la marque de la mémoire - page 62
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
Nouvelles réponses et nouvelles questions - vous êtes toujours plus rapide que vous ne le devriez. Et la raison est tout aussi évidente : les transactions sont toujours inférieures aux miennes (43012 aux mêmes paramètres)... Bien que la différence ne soit plus aussi importante - environ 10%.
Mais ce qu'on peut en faire d'autre, on ne le sait pas encore.
J'ai apporté des modifications au tableau.
Mathemat, lancez un test avec des paramètres comme dans le post de Peter - combien de transactions y aura-t-il ?
Peter, est-ce votre nombre maximum de transactions? Je veux dire trier les résultats par nombre de transactions ?
Peter, est-ce votre nombre maximum de transactions ? Je veux dire trier les résultats par nombre de transactions ?
Non. C'est juste la première itération de l'optimisation. Vous vous intéressez aux extrémums par le nombre ? Je devrai alors refaire le test - j'ai déjà quitté ce terminal. Mais je peux - l'ordinateur n'est pas encore occupé. Est-ce que j'en ai besoin comme ça ?
510 -12767.51 8719 0 .72 -1.46 13779.51 1.38% MovingPeriod=55 MovingShift=10 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
1 -56968.97 39923 0 .61 -1.43 57046.37 5.70% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
C'était, curieusement, la première et la dernière itération.
Que puis-je faire d'autre ? Je peux poster le fichier d'exportation de l'historique (22 m d'archives - 150 non compressés) et vous pouvez exécuter votre test en l'important. Mon spread au moment de l'optimisation (j'étais en course hors ligne) était de 17 pips dans leur cinq chiffres Alpari. Vous pouvez aussi le configurer - je vous ai donné le lien vers le logiciel.
Mon test est le même, 9 h 05.
1 -56631.66 41959 0.62 -1.35 56711.86 5.67% MovingPeriod=5 MovingShift=1 Lots=0.1 MaximumRisk=0.02 DecreaseFactor=3
Il semble, Peter, que tu as trié par nombre de transactions, car mes paramètres externes sont les mêmes que les tiens (surlignés en bleu). Eh bien, nous avons réduit de 5%, mais cela ne me satisfait pas...
BARS a conseillé de mettre une carte graphique externe (la carte intégrée consomme de la mémoire). Je vais pouvoir vérifier ça.
Et je pense qu'il y a un autre facteur - la synchronisation du FSB de la pierre et de la mémoire. Les performances sont maximales lorsqu'elles sont égales, mais je devrais surclocker la pierre une fois et demie, jusqu'à environ 3,8 GHz. La pierre peut résister, elle en est capable, mais ma carte n'est pas la bonne, pas pour l'overclocking...
Et les timings de la mémoire ne sont pas trop critiques, je pense que quelque part sur ixbt lire.
P.S. J'ai aussi Alpari, mais j'ai téléchargé les données depuis le serveur metaquot.
J'ai un total de 6 710 383 transactions et par conséquent une moyenne de passage de 13157.61
BARS m'a conseillé de mettre une carte graphique externe (la carte intégrée consomme de la mémoire). Je pourrai le vérifier.
Et je pense qu'il y a un autre facteur - la synchronisation du FSB de la pierre et de la mémoire. Les performances sont maximales lorsqu'elles sont égales, mais je devrais surclocker la pierre une fois et demie, jusqu'à environ 3,8 GHz. La pierre peut résister, elle en est capable, mais ma carte n'est pas la bonne, pas pour l'overclocking...
J'ai lu quelque part sur ixbt que les timings de la mémoire ne sont pas trop critiques.
Quant à la vidéo intégrée, vous pouvez la négliger à une telle vitesse de mémoire et avec 2 canaux disponibles - elle ne sera sérieusement lente qu'en 3D. Sur le bureau, elle se situera dans la marge d'erreur de la mesure.
Pour un fonctionnement synchrone du processeur FSB et de la mémoire, il est possible de réduire le facteur de multiplication. 7*400 par exemple ne sera que 2.8GHz.
La sensibilité aux délais dépend principalement de la tâche à accomplir. Certaines applications ne remarqueront pas du tout la dégradation des timings, tandis que d'autres réagiront de manière très sensible.
OK.
Puisque nous voulons du réalisme dans les tests de vitesse des testeurs, et que nous ne voulons vraiment pas avoir affaire à des experts non commerciaux inutiles et non pertinents ainsi qu'à des chevaux sphériques inutiles, estimons combien de temps est consacré à quoi.
1. Les frais généraux de l'opération terminale et de l'optimiseur qu'elle contient. t1
2. Heure d'écriture du journal dans le fichier. t2
3. Temps d'exécution de l'Expert Advisor, 1 cycle complet sur la barre void start(). t3
Temps total :
T=k*barres*(t1+t2+t3)
k-nombre de passes dans l'optimiseur, identique pour tous les programmes
bars- nombre de barres dans l'historique, la différence entre les participants au test n'est pas supérieure à 1% (je pense), elle peut être acceptée avec une bonne précision, const.
t1 - ne dépend pas de facteurs externes (météo, crise économique, etc. :), dépend uniquement du matériel testé.
t2-dépend du fer.
t3 - dépend d'un grand nombre de facteurs, non directement liés au fer, et affectant la précision des résultats en raison du contenu du code des fonctions commerciales.
Afin d'offrir des conditions égales à tous les participants au test, sur laquelle des trois composantes pouvons-nous agir ?
Eh bien, probablement T3.
Le nombre de métiers est difficile à gérer. Mais nous pouvons ajouter un bloc de calculs "très utiles" au code du conseiller expert afin de réduire au minimum l'influence des facteurs négatifs. Disons que le bloc de calculs "très utiles" prendrait 95-99% du temps total. C'est tout. La tâche est résolue. Nous obtiendrons une fidélité suffisante pour nos expériences.
zy. À propos du cheval sphérique, alias script. J'ai beaucoup de tâches qui n'ont rien à voir avec l'optimisation des conseillers experts dans l'optimiseur. Il s'agit à la fois d'indicateurs gourmands en ressources et de calculs mathématiques complexes dans des scripts. Par exemple, mon indicateur utilise des ns avec 400-600-200 neurones. Au total, il utilise 360800 poids. J'utilise un script séparé pour entraîner ce poids lourd. L'indicateur lit les poids prêts dans le fichier. Il est clair que si nous implémentons la formation dans l'indicateur lui-même, nous aurons des problèmes avec l'affichage des graphiques. Vous pouvez donner d'autres exemples.
Aïe, c'est ce que je voulais aussi, d'ailleurs. J'ai obtenu 6 577 074 transactions, un peu moins que vous, Docent.
P.S. Je viens de le refaire. Mon temps était de 8:18 (498 sec !!!), bien que je n'aie absolument rien fait. Mais ce tic (je m'étais "interrogé" sur l'optimisation pendant une minute ou deux auparavant) avait disparu.
J'ai supprimé les deux fichiers dont j'avais besoin (du cache et de l'historique). Je ne comprends rien. Je vais réessayer de mettre une carte vidéo.