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 ne comprends pas quel est exactement l'inconvénient. Vous avez téléchargé l'historique une fois dans OnInit() pour tous les symboles - c'est tout.
La création d'un indicateur garantit-elle que l'historique est téléchargé à la bonne profondeur ?
" Référence MQL5 - Accès aux séries chronologiques et aux indicateurs - Organisation de l'accès aux données "https://www.mql5.com/ru/docs/series/timeseries_access
La réception de nouvelles données du serveur entraîne une mise à jour automatique des données de prix utilisées dans le format HC pour toutes les échéances et un nouveau calcul de tous les indicateurs, qui les utilisent évidemment comme données d'entrée pour le calcul.
Lorsque j'appelle un indicateur depuis un conseiller expert, si l'historique d'un symbole n'est pas chargé, le terminal commence à télécharger les données et le trafic reste le même.
Je n'aime pas le chargement indépendant des données, vous devez constamment les surveiller, logiquement le terminal de la 5ème génération lui-même devrait le faire ! MT4 a un chargement indépendant de l'historique à partir du code de l'indicateur - "c'était une douleur dans le cul" :)
Oh ! maintenant c'est constructif, mais personne n'interdit de limiter le nombre de barres dans les paramètres du terminal - cela consommera moins de mémoire, CopyClose() etc. nécessite aussi des tableaux, et c'est la même mémoire de l'ordinateur. Et il semble que dans l'indicateur lui-même, vous pouvez limiter le nombre de barres pour le recalcul - cela nécessite également moins de mémoire.
Une telle construction fonctionnera-t-elle correctement avec le testeur ?
Oui, "être prévenu, c'est être armé" :)
Je ne suis pas d'accord ici sur la consommation de mémoire similaire par la fonction CopyClose(). Cette fonction permet d'utiliser de petits tableaux, et le tampon de l'indicateur - il est toujours étiré à sa longueur totale spécifiée dans les paramètres du terminal, c'est-à-dire au moins 50 mille barres.
Dites-moi, pourquoi les ressources de calcul sont-elles du ressort du CPU et non du GPU ? Peut-être n'ai-je pas compris quelque chose, mais l'efficacité de CUDA et d'OpenCL est reconnue dans de nombreuses industries. Même pour les calculs médicaux. Et quelques misérables 2-4-8 agents sont tout simplement pathétiques comparés aux 128 ou plus agents d'une carte graphique.
Qui vous interdit d'utiliser les ressources de calcul du GPU ?
Voir :
OpenCL : le pont vers les mondes parallèlesOpenCL : Du codage naïf au codage plus intelligent
Qui vous empêche d'utiliser les ressources de calcul du GPU ?
Voir :
OpenCL : le pont vers les mondes parallèlesOpenCL : Du codage naïf à un codage plus significatif
il n'y a aucun moyen de connecter les cartes vidéo aux calculs
Ne soyez pas absurde. Je vous ai donné les liens vers deux articles où il est écrit en russe et en anglais comment utiliser les capacités du GPU pour les calculs.
Ne soyez pas absurde. Je vous ai donné les liens vers deux articles où il est écrit en russe et en anglais comment utiliser les capacités du GPU pour les calculs.
MQ n'a toujours pas trouvé le moyen de normaliser la pléthore de vises fonctionnant sur les ordinateurs en nuage.
Problème 1 : il y a plusieurs cœurs de processeur sur l'ordinateur et une carte vidéo, tous les agents se dirigent vers la carte pour lui demander des ressources.
Problème 2 : les vises diffèrent beaucoup à la fois en mémoire et en nombre de cœurs (écrire du code pour un widget personnalisé est une chose, mais écrire du code universel est beaucoup plus difficile). N'oubliez pas que l'intelligence de la foule est égale à celle du mouton le plus stupide. D'où le problème de la barre à fixer. Pour un code, 128 cœurs et 512 Mo de mémoire suffiront, tandis qu'un autre code ne nécessitera pas moins de 2 Go et 2048 cœurs. Là encore, la viscosité varie beaucoup plus que l'unité centrale, d'où le problème de l'inclusion des applications. Pour les processeurs, le problème est résolu par le niveau PR à partir duquel les cœurs peuvent être utilisés par les agents.
Dites-moi, pourquoi les calculs sont effectués par des CPU et non par des GPU ? Peut-être que quelque chose m'échappe, mais l'efficacité de CUDA et d'OpenCL est reconnue dans de nombreux secteurs. Même les calculs médicaux sont utilisés. Et quelques misérables agents 2-4-8 sont tout simplement pathétiques comparés aux 128 agents ou plus d'une carte graphique.
Le nuage n'a pas que 2-4-8 agents, il s'adapte en fonction de la tâche. J'ai testé une EA avec 512 agents, pour les tâches sérieuses, il pourrait en avoir plus.
Ne vous faites pas d'illusions, les agents n'utilisent pas de GPU parce que MQ n'a toujours pas trouvé comment standardiser une masse hétéroclite de vis sur les ordinateurs claud.
Ne dis pas de bêtises, le GPU est utilisé par les agents locaux. Je n'ai pas demandé pour la bouilloire de Claud, j'ai demandé pour le compteur.
Voir https://www.mql5.com/ru/forum/6042/page10Renat:
La carte vidéo est-elle déjà activée dans la nouvelle version du testeur ou non ? Si oui, où puis-je voir les résultats ?
Oui, bien sûr. Vous pouvez appeler les fonctions OpenCL depuis MQL5 et calculer vos tâches.
Voir https://www.mql5.com/ru/forum/23/page15
MetaTrader 5 Client Terminal build 655
...
25. MetaTester : Ajout de la prise en charge de l'utilisation de programmes OpenCL dans les agents de test.
Les programmes OpenCL sont destinés à effectuer des calculs sur des cartes vidéo qui prennent en charge OpenCL 1.1 ou plus. Les cartes vidéo modernes contiennent des centaines de petits processeurs spécialisés capables d'effectuer simultanément des opérations mathématiques simples sur des flux de données entrants. Le langage OpenCL organise ce type de calcul parallèle et permet d'accélérer considérablement une certaine catégorie de tâches.