![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
(Suite)
J'ai réalisé quelques programmes simples de compréhension analytique montrant que le marché a une forte influence sur les ticks Ask et Bid.
La marque a-t-elle déjà trouvé sa place dans la citation du forum ?
c'est un HIT ... :-)
PS/ Tester est nécessaire pour vérifier les performances du robot. Optimiseur pour s'assurer que les paramètres sont stables. Le testeur ne fait pas de stratégies et l'optimiseur ne devine pas le marché.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Mon mécontentement aux testeurs de stratégie. aux développeurs MQL
Renat Fatkhullin, 2017.12.02 15:23
Et vous comparez la compression de leur zip en mode de compression faible. Peut-être que les fichiers BMP sont comme ça.
La compression des ressources fonctionne.
Il n'est pas sérieux de dire de telles choses sans preuves sur fond de réfutation directe.
Prenez ce code. Mon EX5 fait 1 717 722 octets. Le ZIP à son mode de compression le plus faible est de 1 177 567 octets.
Prenez ce code. Mon EX5 fait 1 717 722 octets. ZIP en mode le plus faible - 1 177 567 octets.
C'est vrai, ces fichiers particuliers sont faiblement compressés et la taille des fichiers EX est raisonnable.
Bien sûr, à l'intérieur de l'EX, les ressources sont compressées.
C'est vrai, ces fichiers particuliers se compressent mal et la taille du fichier EX est raisonnable.
Bien sûr, à l'intérieur des ressources EX, les ressources sont compressées.
Non, malheureusement.
Résultat
Votre ZIP se compresse beaucoup mieux que l'EX5.
Les ressources sont compressées avec l'algorithme lzss le plus rapide possible, et non zippées.
Il n'est pas suicidaire de zipper pendant très longtemps puis de dézipper pendant longtemps.
Les ressources sont compressées avec l'algorithme lzss le plus rapide possible, et non zippées.
Il n'est pas suicidaire de zipper pendant très longtemps puis de dézipper pendant longtemps.
Résultat
80 ms, c'est du suicide ?
Résultat
80ms, c'est du suicide ?
Passez-le sur un Céloron.
Et ensuite, vous pouvez passer à une taille de fichier plus grande en variant le projet.
Passe-le sur un Céloron.
C'est une question de temps relatif, bien sûr. Sur mon i7, la compilation du code source à partir de la KB nécessite
'demo_bitmapoffset.mq5' demo_bitmapoffset.mq5 1 1 0 error(s), 0 warning(s), compile time: 232 msec 1 1
Quand je commente ça.
J'obtiens une réduction de 30 ms.
'demo_bitmapoffset.mq5' demo_bitmapoffset.mq5 1 1 0 error(s), 0 warning(s), compile time: 202 msec 1 1
Le passage total au ZIP pur (80 ms) prendrait 282 ms. Le ralentissement serait donc de 21,5 %. Et ceci pour le code source le plus simple.
Si vous prenez des sources qui se compilent en quelques secondes, le ralentissement sera d'environ 1%. Il semble que ce n'est pas une grosse affaire dans ce cas.
Non, nous croyions et croyons toujours que les ressources doivent être compressées et décompressées aussi rapidement que possible sur l'ensemble du zoo de processeurs. Il y a beaucoup de processeurs étranglés par l'économie, y compris les atomes semi-vitaux. Il y a une perte de vitesse d'une douzaine de fois par rapport aux puissants processeurs d'aujourd'hui.
À propos, dans la dernière version de MT5, nous avons considérablement augmenté la vitesse de lancement du terminal et de l'éditeur après une évaluation approfondie de l'impact de la compression des ressources et des méthodes d'initialisation de la protection. Nous avons gagné des secondes entières sur des processeurs bas de gamme.
Ce qui était imperceptible sur un i7/xeon complet, était un désastre en quelques secondes sur des atomes/celebrons et des appareils de puissance similaire.
Non, nous croyions et croyons toujours que les ressources doivent être compressées et décompressées aussi rapidement que possible sur l'ensemble du zoo de processeurs. Il y a beaucoup de processeurs étranglés par l'économie, y compris les atomes semi-vitaux. Il y a une perte de vitesse d'une douzaine de fois par rapport aux puissants processeurs d'aujourd'hui.
À propos, dans la dernière version de MT5, nous avons considérablement augmenté la vitesse de lancement du terminal et de l'éditeur après une évaluation approfondie de l'impact de la compression des ressources et des méthodes d'initialisation de la protection. Nous avons gagné des secondes entières sur des processeurs bas de gamme.
Ce qui était imperceptible sur un i7/xeon complet, était un désastre en quelques secondes sur des atomes/celebrons et des appareils de puissance similaire.
Chapeau bas à vous pour une telle recherche ! J'aimerais avoir la même approche approfondie pour les CopyTicks et les CustomSymbols. C'est presque un désastre là-bas.