MT5 et la vitesse en action - page 61
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
Je pense que ce mur de QM ne passera pas sans le soutien des membres du forum. Le code est court, les pros devraient pouvoir le comprendre rapidement. Il n'y a aucun défaut. Il est clairement démontré que les prix à travers les positions sont obtenus beaucoup plus rapidement qu'à partir de Market Watch. Comment MQ ne peut pas voir l'évidence - je ne comprends pas.
1. Votre test compte réellement un micro pourcentage d'itérations en raison de la condition
En substance, vous ne comptez que les anomalies où le processeur est surchargé de tâches et repousse l'exécution de la tâche donnée sur l'étagère lointaine, car plus de 99 % des itérations sont effectuées en moins d'une microseconde.
Et même si vous fixez la condition >0, il n'y a toujours pas d'objectivité.
2. La mesure du temps de telles opérations rapides ne doit être effectuée que sous forme de temps de cycle complet, et non d'une seule itération.
3. mais puisque le cycle dans votre exemple est limité à 10 secondes (Pourquoi ! Pour les ticks, je pense que 0,1 seconde est tout à fait suffisant. Parce qu'il se peut très bien que 3 ticks arrivent dans une seconde, et que les trois ticks soient exécutés pendant 10 secondes chacun, et en parallèle), donc aucun timing n'est nécessaire. Il est plus facile de calculer le nombre d'itérations qui seront exécutées dans un temps donné. Plus il y en a, plus la productivité est élevée.
J'ai modifié votre code "un peu". Je pense que ma variante reflète mieux la réalité.
Le calcul se fait un par un, afin de ne pas mélanger les deux variantes. Les tics pairs sont pourSYMBOL_BID, les impairs - pour GetBid().
J'ai ajouté les sommes et leur sortie juste au cas où, pour essayer de tromper le compilateur contre l'optimisation.
Le résultat de la sortie est cumulatif.
Mon résultat :
Comme vous pouvez le constater, la différence de performance est trois fois plus importante en faveur de la version standard.
Comme vous pouvez le constater, la différence de performance est trois fois plus importante en faveur de la version originale.La version originale de fxsaber montre-t-elle l'avantage de GetBid, ou s'agit-il d'un PC plus puissant/moins chargé ?
La version originale de fxsaber présente-t-elle un avantage GetBid, ou bien le PC est-il plus puissant/moins chargé ?
Sa variante a également montré l'avantage de GetBid à pleine charge CPU. Mais en même temps, ma variante présente trois fois plus d'avantages que la fonction normale à la même charge.
Cela s'explique par le fait que ma variante prend en compte le temps moyen de toutes les itérations pour obtenir le prix de l'offre et qu'il ne s'agit que d'une fraction minuscule avec des accrochages anormaux.
Qui sait pour quelle raison le processeur s'embourbe dans la fonction régulière (lorsque le retard est supérieur à 100 µ) dans une "minute" difficile. Mais le temps moyen est tout de même trois fois inférieur pour la fonction régulière
Ainsi, par exemple, si (Interval##A > 100), c'est le cas :
alors que si (Interval##A > 0) est déjà très différent, montrant une distribution aléatoire des délais anormaux entre la version régulière et la version alternative d'obtention du prix de l'offre.
en même temps mon test avec la même charge CPU montre :
Par conséquent, je pense que la version du test de fxsaber est loin d'être objective.
Je n'ai pas chargé le CPU avec des agents, mais avec ce script. C'était plus efficace.
après une légère modification du test fxsaber pour démontrer clairement quel pourcentage d'itérations est pris en compte dans les calculs :
c'est-à-dire environ 0,01%.
Tu parles.
Si le temps d'exécution moyen de SymbolInfoDouble(_Symbol, SYMBOL_BID) est d'environ 50 nanosecondes, seuls ceux dont le temps d'exécution est supérieur à 100 000 nanosecondes sont pris en compte.
après une légère modification du test fxsaber pour montrer clairement quel pourcentage d'itérations est pris en compte dans les calculs :
c'est-à-dire environ 0,01%.
Tu parles.
Si le temps d'exécution moyen de SymbolInfoDouble(_Symbol, SYMBOL_BID) est d'environ 50 nanosecondes, seules les itérations supérieures à 100 000 nanosecondes sont comptées.
Nous aurions pu simplement faire en sorte que la condition ne soit pas supérieure à 100 µs, mais supérieure à 3 µs. Le résultat était apparemment le même. L'idée était qu'il s'agissait d'une étude segmentaire et que dans différentes conditions d'exécution, il pouvait y avoir une différence dans différents segments et dans différentes sections. Les priorités d'exécution sont souvent établies en fonction de n'importe quoi. À faible charge, certaines priorités, à forte charge, d'autres, à charge critique, celles qui ne laissent pas l'ordinateur se bloquer et tomber en panne, et les performances passent au second plan.
En général, il n'est pas bon de négocier avec une charge de plus de 70 % du matériel. C'est une performance presque critique. La charge en fer des EA de combat ne doit pas être supérieure à 60%.
et avez-vous déjà des courtiers HFT ?)
essayez de tester SymbolInfoTick quand il n'y a qu'un seul symbole dans la vue d'ensemble du marché et quand il y a des dizaines de symboles, mais demandez un seul outil - comme dans votre exemple
il y a une forte probabilité que le serveur envoie du trafic compressé et que SymbolInfoTick subisse des décalages périodiques lors de la décompression des données.
c'est-à-dire que lorsqu'il y a beaucoup de symboles, les creux dans le temps de test seront encore plus fréquents ou plus profonds.
Dans les constructions récentes, la réception du flux de tics n'a aucun effet, même en théorie. En pratique, SymbolInfoTick fonctionne déjà avec le cache, mais certains citoyens continuent à chercher un chat noir.
Ce n'est même pas 80% dans le test. Il y a 6 agents fonctionnant sur 4 cœurs, c'est-à-dire 100% garantis.
La seule question est de savoir comment le planificateur de tâches de son système gère la situation. Dans le même temps, certains prétendent que c'est la mise en œuvre du terminal qui est en cause.
En d'autres termes, une situation est créée artificiellement lorsqu'un ordinateur est surchargé, lorsque littéralement tout ce qui s'y trouve ralentit, et ensuite certaines revendications sont faites sous la forme de "Oh, regardez, pourquoi le terminal traîne-t-il parfois".
Fermons les yeux sur le fait que, même dans de telles conditions, elle est "d'environ 0,01%" - au diable les détails ! Il suffit de dire que "personne ne se soucie de la température moyenne d'un hôpital", "les décalages posent des problèmes lors des transactions" et "nous voulons du HFT".
De plus, il est évident que nous voulons HFT dans 20 experts sur un vieux bureau de bureau ou une machine virtuelle morte.
PS PositionSelectByTicket() dans son implémentation a certainement accès à une ressource partagée avec synchronisation des accès. Et si vous ne sélectionnez pas la position sur chaque appel, vous lisez l'ancien prix. Il était plus facile de faire un "snapshot" via SymbolInfoDouble.