OpenCL : tests de l'implémentation interne dans MQL5 - page 4
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
Si je comprends bien, 1 GPU est un agent très puissant ? Les agents du CPU peuvent-ils être désactivés dans ce cas (en raison de leur faible vitesse par rapport à la vidéo) ? Et encore : est-il possible d'avoir deux ATI sans crossfire ?
AMD déconseille fortement l'utilisation de Crossfire pour OpenCL, car avec Crossfire, il y a en fait deux GPU mais le pilote DOIT répartir UNE tâche graphique entre eux. Au contraire, pour OpenCL 1.1, il n'existe pas encore de moyen pour le pilote de la carte vidéo lui-même de diviser un seul travail OpenCL entre les deux GPU (voir ci-dessus).
La même chose pour nvidia SLI.
Comment l'inclusion d'OpenCL affectera-t-elle le coût des calculs dans le nuage ?
Le coût d'un agent avec GPU sera plus élevé que celui d'un agent sans GPU, car le temps estimé du premier agent sera nettement plus court ?
Étant donné qu'un seul agent sur la machine locale recevra un GPU, il s'avère que le coût des différents agents sur la même machine locale sera différent (et pré-calculé) ?
Comment l'inclusion d'OpenCL affectera-t-elle le coût de l'informatique dans le nuage ?
Le coût d'un agent avec GPU sera-t-il plus élevé que celui d'un agent sans GPU parce que le temps de calcul du premier agent sera nettement plus court ?
Étant donné qu'un seul agent sur la machine locale recevra le GPU, il s'avère que le coût des différents agents sur la même machine locale sera différent (et pré-calculé) ?
Par défaut, le terminal/agent choisit le périphérique GPU le plus puissant en fonction de ses caractéristiques au démarrage. Jusqu'à présent, il n'y a pas d'idée de sélection de périphériques à partir de MQL5 - cela ne ferait que compliquer le code et entraîner des erreurs supplémentaires.
Au lieu de cela, il y a une idée plus belle sous la forme d'une allocation automatique de chaque GPU physique à des agents distincts, ce qui permettra de les utiliser à leur plein potentiel.
Disons que nous avons un EX5 (utilisant OpenCL) qui s'optimise 20 fois plus vite sur les agents avec GPU que sans GPU.
Nous exécutons l'optimisation sur le cloud. Il est évident qu'il est plus avantageux (en termes de temps) d'exécuter l'optimisation en premier lieu sur les agents qui disposent d'un GPU physique. En leur donnant l'essentiel des options d'énumération. C'est équivalent au fait que leur PR est 20 fois plus élevé. MAIS, leur RP sans utilisation de GPU est la même. C'est-à-dire qu'un nouveau calcul de PR, PR_gpu, doit être saisi.
"Lorsqu'une tâche est exécutée, le travail effectué par l'agent de test est comptabilisé comme le produit de son PR par le Temps passé. "
Il découle de cette formule que s'il n'y a pas de PR_gpu, le coût de toutes les optimisations sur le nuage avec GPU sera moins cher que sans.
Malheureusement, l'introduction d'un calcul alternatif du RP - un seul passage de test du fichier EX5 optimisé contient un grand nombre de pièges, en raison desquels il est impossible de l'utiliser universellement.
Il découle de cette formule que s'il n'y a pas de PR_gpu, le coût de l'optimisation complète sur le nuage avec GPU sera moins cher que sans.
Malheureusement, l'introduction d'un calcul alternatif du RP - un seul passage de test d'un fichier EX5 optimisé - comporte un grand nombre de pièges qui rendent impossible son utilisation universelle.
sans entrer dans les détails, que je ne connais pas, si le PR réel n'est pas révisé, alors il n'y a aucun intérêt à se tourner vers le cloud avec le GPU.
Aussi, si vous introduisez un nouveau concept, et que vous l'aimez) Par exemple, si vous introduisezun nouveau concept, ce que vous aimez faire, il est préférable de le définir immédiatement ou de deviner qu'il s'agit dans ce cas du côté utilisateur.
Actuellement, PR = Const Koef / temps nécessaire pour accomplir la tâche de référence.
Le coût de l'optimisation est égal au nombre de tâches de référence qui ont pu être calculées pendant le temps qu'a duré l'optimisation. En d'autres termes, le coût du calcul ne dépend pas de la manière dont le nuage répartit les tâches entre les agents. Mais la durée de l'optimisation finale dépend de l'allocation appropriée, qui est la métrique la plus importante.
Il est clair que le nuage alloue les tâches aux agents en proportion des RP précalculés afin de réduire le temps de calcul (mais pas le coût - CONST).
Les tâches OpenCL seront bien entendu confiées en priorité aux agents disposant du bon GPU.
le coût du calcul ne dépend pas de la manière dont le nuage répartit les tâches entre les agents.
Malheureusement, l'introduction d'un calcul alternatif du RP - un test unique d'un fichier EX5 optimisé - comporte un grand nombre d'écueils qui rendent impossible son utilisation universelle.
Puisque le coût pour l'optimiseur est toujours constant, mais que sa durée dépend fortement d'un calcul PR adéquat (pour la tâche donnée), peut-être devrions-nous introduire l'optimiseur à entrer son code EX5 PR_calculate sur sa conscience. Où l'optimiseur, sur la base des caractéristiques de son algorithme, définira le PR distributif le plus adapté à sa tâche.
Par exemple, si la tâche est purement calculatoire, l'accent sera mis sur les mathématiques dans PR_calculate.
Si la tâche traite d'énormes quantités de données, l'accent sera mis sur la vitesse de traitement de la mémoire.
Si le GPU est un peu utilisé - affichez-le dans votre PR_calcul.
Si le GPU est utilisé partout dans EX5 - écrivez un PR_calcul approprié (avec utilisation appropriée du GPU).
Dans le cadre de ce système, ceux qui louent l'énergie au nuage ne perdent rien, et ceux qui utilisent l'énergie du nuage ont la possibilité d'accélérer considérablement leurs calculs.
Si PR_calculate n'est pas spécifié, la tâche de référence universelle déjà acceptée est utilisée.
P.S. PR_calculate est uniquement utilisé pour allouer des tâches dans le nuage. Pour le calcul des coûts, on utilise toujours le même vieux PR.
P.P.S. Il y a, bien sûr, des écueils - PR_calculate doit être exécuté au préalable sur tous les agents libres. PR_calculate peut être écrit en erreur - bouclé. Ainsi, pour le temps nécessaire au calcul de PR_calcul, vous devez également facturer de l'argent selon le schéma classique de PR. Etc.
Puisque le coût pour l'optimiseur est toujours constant, mais que sa durée dépend fortement d'un calcul adéquat (pour la tâche donnée) de PR, il vaut peut-être la peine d'introduire à la conscience de l'optimiseur une entrée à son code EX5 PR_calcul. Où l'optimiseur, sur la base des caractéristiques de son algorithme, définira le PR distributif le plus adapté à sa tâche.