OpenCL: interne Implementierungstests in MQL5 - Seite 4
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Wenn ich das richtig verstehe, ist 1 GPU ein sehr leistungsfähiges Mittel? Ist es möglich, CPU-Agenten in diesem Fall zu deaktivieren (aufgrund ihrer geringen Geschwindigkeit im Vergleich zu Video)? Und noch einmal: Ist es möglich, zwei ATIs ohne Crossfire zu verwenden?
AMD rät dringend davon ab, Crossfire für OpenCL zu verwenden - denn bei Crossfire gibt es eigentlich zwei GPUs, aber der Treiber MUSS EINE Grafikaufgabe zwischen ihnen aufteilen. Im Gegensatz dazu gibt es für OpenCL 1.1 noch keine Möglichkeit für den Grafikkartentreiber selbst, einen einzelnen OpenCL-Auftrag auf die beiden GPUs aufzuteilen (siehe oben).
Dasselbe gilt für nvidia SLI.
Wie wird sich die Einbeziehung von OpenCL auf die Kosten von Berechnungen in der Cloud auswirken?
Die Kosten für einen Agenten mit GPU werden höher sein als die Kosten für einen Agenten ohne GPU, da die geschätzte Zeit des ersten Agenten deutlich kürzer sein wird?
In Anbetracht der Tatsache, dass nur ein Agent auf dem lokalen Rechner eine GPU erhält, stellt sich heraus, dass die Kosten der verschiedenen Agenten auf demselben lokalen Rechner unterschiedlich (und vorberechnet) sind?
Wie wird sich die Einbeziehung von OpenCL auf die Kosten der Datenverarbeitung in der Cloud auswirken?
Werden die Kosten für einen Agenten mit GPU höher sein als die Kosten für einen Agenten ohne GPU, weil die Rechenzeit des ersten Agenten deutlich kürzer sein wird?
Angesichts der Tatsache, dass nur ein Agent auf dem lokalen Rechner eine GPU erhält, stellt sich heraus, dass die Kosten der verschiedenen Agenten auf demselben lokalen Rechner unterschiedlich (und vorberechnet) sind?
Standardmäßig wählt das Terminal/der Agent beim Start das leistungsstärkste GPU-Gerät anhand seines Funktionsumfangs aus. Bisher gibt es keine Idee, Geräte aus MQL5 auszuwählen - das würde den Code nur verkomplizieren und zu zusätzlichen Fehlern führen.
Stattdessen gibt es eine schönere Idee in Form einer automatischen Zuweisung jeder physischen GPU zu separaten Agenten, die es erlaubt, ihr volles Potenzial zu nutzen.
Nehmen wir an, wir haben einen EX5 (mit OpenCL), der auf Agenten mit GPU 20 Mal schneller optimiert als ohne GPU.
Wir führen die Optimierung in der Clouddurch. Es ist offensichtlich, dass es (in Bezug auf die benötigte Zeit) am vorteilhaftesten ist, die Optimierung zunächst auf den Agenten durchzuführen, die über einen physischen Grafikprozessor verfügen. Sie erhalten den Großteil der Aufzählungsoptionen. Das ist gleichbedeutend mit der Tatsache, dass ihre PR 20 Mal höher ist. ABER, ihre PR ohne GPU ist die gleiche. D.h. es muss eine neue PR-Berechnung, PR_gpu, eingegeben werden.
"Wenn eine Aufgabe ausgeführt wird, wird die vom Testagenten geleistete Arbeit als das Produkt aus seiner PR und der aufgewendeten Zeit gezählt. "
Aus dieser Formel ergibt sich, dass die Kosten aller Optimierungen in der Cloud mit GPU günstiger sind als ohne PR_gpu.
Leider birgt die Einführung einer alternativen PR-Berechnung - einzelner Testdurchlauf der optimierten EX5-Datei - eine Vielzahl von Fallstricken, so dass sie nicht universell eingesetzt werden kann.
Aus dieser Formel folgt, dass die Kosten für die gesamte Optimierung in der Cloud mit GPU billiger sind als ohne GPU, wenn es keine PR_gpu gibt.
Leider birgt die Einführung einer alternativen PR-Berechnung - ein einziger Testdurchlauf einer optimierten EX5-Datei - eine Vielzahl von Fallstricken, die einen universellen Einsatz unmöglich machen.
ohne auf Einzelheiten einzugehen, die ich nicht kenne, wenn die aktuelle PR nicht überarbeitet wird, hat es keinen Sinn, sich mit der GPU in die Cloud zu begeben
Auch, wenn Sie ein neues Konzept einführen und es Ihnen gefällt) Wenn Sie zum Beispielein neues Konzept einführen, was Sie gerne tun, ist es besser, es sofort zu definieren oder zu vermuten, dass es in diesem Fall um die Benutzerseite geht.
Derzeit ist PR = Const Koef / Zeit, die für die Erfüllung der Benchmark-Aufgabe benötigt wird.
Die Kosten der Optimierung entsprechen der Anzahl der Benchmark-Aufgaben, die in der Zeit, die die Optimierung dauerte, berechnet werden konnten. Das heißt, die Kosten für die Berechnung hängen nicht davon ab, wie die Cloud die Aufgaben unter den Agenten aufteilt. Die endgültige Optimierungsdauer hängt jedoch von der richtigen Zuweisung ab, die die wichtigste Kennzahl ist.
Es ist klar, dass die Wolke den Agenten Aufgaben im Verhältnis zu den vorberechneten PR zuweist, um die Rechenzeit (aber nicht die Kosten - CONST) zu reduzieren.
OpenCL-Aufgaben werden natürlich zuerst an Agenten mit der richtigen GPU vergeben.
Die Kosten der Berechnung hängen nicht davon ab, wie die Cloud die Aufgaben zwischen den Agenten verteilt.
Leider birgt die Einführung einer alternativen PR-Berechnung - ein einzelner Testlauf einer optimierten EX5-Datei - eine Vielzahl von Fallstricken, die eine universelle Anwendung unmöglich machen.
Da die Kosten für den Optimierer immer konstant sind, ihre Dauer aber stark von einer adäquaten (für die gegebene Aufgabe) PR-Berechnung abhängt, sollten wir vielleicht einführen, dass der Optimierer seinen EX5-Code PR_calculate nach seinem Gewissen eingeben kann. Der Optimierer wird auf der Grundlage der Merkmale seines Algorithmus die für seine Aufgabe am besten geeignete Verteilungs-PR festlegen.
Wenn die Aufgabe beispielsweise rein rechnerisch ist, liegt der Schwerpunkt von PR_calculate auf der Mathematik.
Wenn die Aufgabe große Datenmengen verarbeitet, liegt der Schwerpunkt auf der Geschwindigkeit der Speicherverwaltung.
Wenn die GPU ein bisschen benutzt wird - zeigen Sie es in Ihrem PR_calculate an.
Wenn die GPU überall in EX5 verwendet wird - schreiben Sie ein entsprechendes PR_calculate (mit entsprechender Verwendung der GPU).
Bei dieser Regelung haben diejenigen, die Strom an die Cloud vermieten, nichts zu verlieren, während diejenigen, die den Cloud-Strom nutzen, die Möglichkeit haben, ihre Berechnungen erheblich zu beschleunigen.
Wenn PR_calculate nicht angegeben ist, wird die bereits akzeptierte universelle Referenzaufgabe verwendet.
P.S. PR_calculate wird nur für die Zuweisung von Aufgaben in der Cloud verwendet. Für die Kostenberechnung wird nach wie vor die alte PR verwendet.
P.P.S. Es gibt natürlich einige Fallstricke - PR_calculate muss für alle freien Mitarbeiter im Voraus ausgeführt werden. PR_calculate kann fehlerhaft geschrieben werden - in einer Schleife. Sie müssen also auch die Zeit für PR_calculate nach dem klassischen PR-Schema berechnen. Etc.
Da die Kosten für den Optimierer immer konstant sind, ihre Dauer aber stark von der angemessenen (für die gegebene Aufgabe) Berechnung von PR abhängt, lohnt es sich vielleicht, zum Gewissen des Optimierers die Eingabe in seinen EX5-Code PR_calculate einzuführen. Der Optimierer wird auf der Grundlage der Merkmale seines Algorithmus die für seine Aufgabe am besten geeignete Verteilungs-PR festlegen.