OpenCL: interne Implementierungstests in MQL5 - Seite 33

 
Mathemat:

Andrew, ist, sagen wir, Intel + Radeon überhaupt eine schlechte Sache?

Nicht schlecht, nur unverhältnismäßig teuer (wegen des Prozessors). :)

Übrigens bin ich ein langjähriger Fan von nVidia-Karten. Ich habe sogar noch irgendwo eine Schachtel mit dem legendären GeForce 3. Und wenn ich Spiele spielen wollte, würde ich nicht zögern, mich an den "grünen" Grafikchip-Hersteller zu halten.

 
Fangen Sie den Beitrag in einer privaten Nachricht hier ein. Ich möchte es nicht hierher bringen.
 
MetaDriver:
Aber im Ernst: Ich bin gespannt, was für eine Leistung Sie aus ihm herausholen können, vor allem, wenn Sie 2 Giga DDR5 haben. Wie sich herausstellt, kann der integrierte GPU-Speicher eine SEHR wichtige Ressource für OpenCL-Berechnungen sein.

Aus allen mir zur Verfügung stehenden Informationen habe ich geschlossen, dass die wichtigste Ressource die Anzahl der GPU-Kerne ist. Wenn es nicht genug davon gibt, wird das Problem in aufeinanderfolgende Durchläufe von Kernen mit neuen Threads aufgeteilt, aber es ist schwer, beim Kauf der Karte an dieser Ressource zu sparen, denn je mehr Kerne, desto höher der Preis.

Der zweitwichtigste Faktor ist die Geschwindigkeit, mit der der GPU-Speicher läuft (da auf den Speicher häufig zugegriffen wird). GPU-Aufgaben sind in den meisten Fällen recht primitiv und verwenden 1-2-3 Operationen, bevor sie auf den Speicher zugreifen, um die Ergebnisse anzuzeigen. Alle komplexen logischen Operationen sind für GPUs kontraindiziert, daher würden Programmierer versuchen, sie zu minimieren, was logischerweise zu häufigeren Speicherzugriffen führen würde. Hier gibt es Varianten, wenn die Aufgabe vom Programmierer so beschrieben wird, dass die Speicherzugriffe so gering wie möglich sind, dann ist diese Ressource nicht so wichtig.

Und als dritte Ressource würde ich den GPU-Speicher nennen. Denn Crash-Tests haben gezeigt, dass unabhängig von der Anzahl der gleichzeitigen Kontexte der gesamte verteilte Speicher in den Kontexten in einem Speicherfeld zugewiesen wird und sich nicht überschneidet. Lassen Sie mich das an einem Beispiel erklären: Wenn Sie N Kontexte haben, in denen jeweils Puffer in 1/4 des Gerätespeichers zugewiesen sind, können Sie 4 solcher Kontexte gleichzeitig haben. Einem fünften Kontext, auch wenn Sie ihn erstellen, wird kein Speicher zugewiesen, da er bereits durch die vorherigen Kontexte verteilt ist. Wenn Sie jedoch Speicher in einem der vorhergehenden Kontexte freigeben (indem Sie einfach den Puffer entfernen), wird etwas Platz geschaffen, und der fünfte Kontext funktioniert problemlos.

Renat:

Es ist noch zu früh - wir müssen sicherstellen, dass OpenCL-Programme nicht das gesamte Netzwerk aufgrund von GPU-Störungen und OpenCL-Programmen selbst zum Stillstand bringen.

Tatsächlich können OpenCL-Programme erst ins Netz gestellt werden, nachdem sie auf lokalen Agenten getestet wurden, um sicherzustellen, dass das Programm funktioniert und den Computer nicht zerstört.

Die Aufgabe eines verteilten parallelen Rechnernetzes. Der Name selbst kann einen ungeschulten Leser verwirren. Wenn Sie Probleme mit der Organisation eines verteilten Netzwerks auf Multicore-Rechnern hatten, dann haben Sie jetzt ein Problem. Alle Kerne können als separate Netzeinheiten betrachtet werden, da sie separate Aufgaben erfüllen. Aber zuvor ihre Ausführungsgeschwindigkeit unterschied sich höchstens 2-3 mal (für die Sie Geschwindigkeitsbeschränkungen für langsame Kerne eingeführt haben), die Menge des Speichers in den meisten Fällen nicht eine Rolle spielen, wie Arrays haben 10^7 Elemente maximal (für moderne Maschinen ist Pennies).

Mit der GPU ändert sich das Problem jedoch dramatisch. Zunächst einmal sind nur ~12 Double Arrays mit der Länge 10^7 bereits 1Gb, was für viele Karten eine Grenze darstellt. Bei CPU-Berechnungen sind Aufgaben mit mehreren Puffern durchaus üblich (obwohl GPU-Programmierer natürlich den Host-Speicher verwenden können, aber das ist ähnlich wie virtueller RAM, kurz gesagt, es ist schlecht).

Zweitens ist der Unterschied in der Ausführungsgeschwindigkeit linear proportional zur Anzahl der Kerne in einer GPU. Der Unterschied zwischen den beiden Karten beträgt 10-1000 Mal.

Im Allgemeinen läuft die Aufgabe der Vernetzung auf die Klassifizierung des auszuführenden Programms hinaus. Achten Sie auf den CUDA Profiler. Die Statistiken können als Grundlage für die Klassifizierung von Aufgaben herangezogen werden. Wenn die Aufgabe so konzipiert ist, dass die meiste Zeit mit Speicherzugriffen verbracht wird, ist ein Cluster von Maschinen mit großen Speichergrößen erforderlich, aber wenn die meiste Zeit auf Arithmetik verwendet wird, brauchen wir einen Cluster mit einer großen Anzahl von Kernen. Cluster können flexibel oder integrierbar sein (dies ist eine Frage der Ausführung).

Allerdings wird die Aufgabe durch die Vereinheitlichung, die die Zeit selbst vornimmt, ein wenig vereinfacht. Eine Karte mit 12 Kernen hat wahrscheinlich 256 MB, eine Karte mit 96 Kernen hat 512 MB. Im Durchschnitt lassen die Hersteller keine großen Abweichungen zu (im Gegensatz zur CPU, bei der der Benutzer seinen alten Stein mit RAM bis zum Anschlag aufkleben oder den neuen Stein mit minimalem RAM ausstatten kann, nur um beim Kauf Geld zu sparen).

Obwohl, meiner Meinung nach, ein korrekterer Ansatz wäre es, einen Debugger für OpenCL zu erstellen und auf seiner Grundlage verteidigen Optimierung für das Gerät in Bytecode. Andernfalls kämen wir zu Assembler, wo der Programmierer raten müsste, auf welcher Karte das Programm laufen würde, und durchschnittliche Eigenschaften des Programms für eine mögliche Umgebung.

 
MetaDriver:

Sagen Sie mir, wenn es Ihnen nichts ausmacht, wie Sie den Test durchführen? Wo, was soll geändert werden? Kopieren, auswählen, Ergebnis:

Win7 x64 Build 607

 
WChas:

Dieses Beispiel muss nicht im Tester "ausgeführt" werden. Um das Skript auszuführen, ziehen Sie es per Drag & Drop aus dem "Navigator" auf das Diagramm. Das Ergebnis wird im Bereich " Werkzeuge", Registerkarte " Experten", angezeigt.

 

w7 32 bit 4GB ( 3.5GB verfügbar)

Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) gegen Radeon HD 5770

 
Snaf:

w7 32 bit 4GB ( 3.5GB verfügbar)

Intel Core 2 Quad Q9505 Yorkfield (2833MHz, LGA775, L2 6144Kb, 1333MHz) gegen Radeon HD 5770

Cool, jetzt weißt du, wo du suchen musst... :)
 
MetaDriver:
Cool, jetzt weißt du, wo du graben musst... :)

die Prozessoren sind bereits 2-3 Generationen im Rückstand

und Video 5770 - 6770 -7770

:)

 
Urain:

Aus den verfügbaren Informationen bin ich zu dem Schluss gekommen, dass die wichtigste Ressource die Anzahl der GPU-Kerne ist, im Falle eines Mangels wird das Problem durch aufeinanderfolgende Durchläufe von Kernen mit neuen Threads gelöst, aber es ist schwer, beim Kauf einer Karte an dieser Ressource zu sparen, denn je mehr Kerne, desto höher der Preis.

Der zweitwichtigste Faktor ist die Geschwindigkeit, mit der der GPU-Speicher läuft (da auf den Speicher häufig zugegriffen wird). GPU-Aufgaben sind in den meisten Fällen recht primitiv und verwenden 1-2-3 Operationen, bevor sie auf den Speicher zugreifen, um die Ergebnisse anzuzeigen. Alle komplexen logischen Operationen sind für GPUs kontraindiziert, daher würden Programmierer versuchen, sie zu minimieren, was logischerweise zu häufigeren Speicherzugriffen führen würde. Hier gibt es Varianten, wenn die Aufgabe vom Programmierer so beschrieben wird, dass die Speicherzugriffe so gering wie möglich sind, dann ist diese Ressource nicht so wichtig.

Und als dritte Ressource würde ich den GPU-Speicher nennen. Denn Crash-Tests haben gezeigt, dass unabhängig von der Anzahl der gleichzeitigen Kontexte der gesamte verteilte Speicher in den Kontexten in einem Speicherfeld zugewiesen wird und sich nicht überschneidet. Lassen Sie mich das an einem Beispiel erklären: Wenn Sie N Kontexte haben, in denen jeweils Puffer in 1/4 des Gerätespeichers zugewiesen sind, können Sie 4 solcher Kontexte gleichzeitig haben. Einem fünften Kontext, auch wenn Sie ihn erstellen, wird kein Speicher zugewiesen, da er bereits durch die vorherigen Kontexte verteilt ist. Durch das Freigeben von Speicherplatz in einigen der vorherigen Kontexte (einfaches Entfernen des Puffers) wird jedoch etwas Platz geschaffen, und der fünfte Kontext funktioniert problemlos.

Nikolai, ich stimme Ihnen zu, was die individuelle Wertehierarchie angeht. Aber was die Cloud betrifft... das Problem liegt im Speicher. Wenn die ersten beiden Ressourcen auf dem Cloud-Rechner nicht ausreichen, wird das Client-Programm einfach langsamer. Wenn zu wenig GPU-Speicher vorhanden ist, kann es einfach zu einem Absturz kommen. Das heißt, wenn der Treiber den Puffer nicht verteilt, ist das schon die halbe Miete. Es ist ein Unglück, wenn zwar genügend Speicher vorhanden ist, aber nicht genug für die übrigen GPU-Kontexte (einschließlich der Systemkontexte) übrig bleibt. Dann stürzt der Fahrer einfach ab (wie die Praxis gezeigt hat). Vielleicht ist dies nur ein Fehler in der Treibersoftware, aber solange er besteht, wäre es besser, OpenCL-Programme nicht in die Cloud zu lassen. Remote-Agenten können, aber die Cloud sollte nicht.
 

nach dem Upgrade auf Build 607 funktionierte plötzlich opencltest auf meinem Laptophttps://www.mql5.com/ru/code/825, vorher funktionierte es nicht (vor etwa zwei Wochen), ich glaube es sagte "OpenCL nicht gefunden"

"Ich rieche einen Trick", habe noch nicht mit Mandelbrot-Fraktalen herumgespielt ))))))))))))) aber es ist immer noch schön, dass ein neuer Laptop nicht für einen vollständigen MT5-Test verwendet werden kann

OpenCL Test
OpenCL Test
  • Stimmen: 10
  • 2012.02.07
  • MetaQuotes Software
  • www.mql5.com
Небольшой рабочий пример расчета фрактала Мандельброта в OpenCL, который кардинально ускоряет расчеты по сравнению с софтверной реализацией примерно в 100 раз.