OpenCL: Echte Herausforderungen - Seite 6

[Roffild]

Mathemat: Ich habe es noch nicht mit dem Tester überprüft.

Warum haben Sie dann ungeprüften Unsinn gepostet?

Vielleicht bin ich ja doch der einzige, der OpenCL im Tester ausprobiert hat... ausprobiert...

[Sceptic Philozoff]

Roffild:

Warum haben Sie dann ungeprüften Unsinn gepostet?

Wahrscheinlich bin ich doch der einzige, der OpenCL im Tester verwendet hat... ausprobiert...

Das ist kein Unsinn, sondern eine erfüllte Bitte.

Noch einmal: Schreiben Sie an servicedesk und begründen Sie, was Sie wollen. Wenn Sie das nicht verantworten können, ist das Ihr Problem.

Zum Zeitpunkt der Abfassung dieser Artikel hatte die Diskussion über die Verwendung von OpenCL im Tester noch nicht ernsthaft begonnen. Der Antrag bezieht sich genau auf diese Zeit.

Sie sollten Ihr Gehirn einschalten, denn 0,35300 ms beziehen sich auf clEnqueue[Read/Write]Buffer() und nicht auf den globalen Speicherzugriff innerhalb des Kernels.

Dieser Befehl ist in der OpenCL für MQL5 Implementierung nicht vorhanden. Was soll das heißen?

[Vladimir Gomonov]

Roffild:

Gehen Sie meine Beiträge noch einmal durch.

Das Hauptkriterium: Die Ausführung des MQL-Codes im "OpenCL-Stil" für 1 Tick muss die Zeit = Number_Buffers * 0,35300 ms überschreiten

Um die Geschwindigkeit des Algorithmus in MQL mit einer Genauigkeit von Mikrosekunden (1000 Mikrosekunden = 1 Millisekunde) herauszufinden, müssen Sie mehrere Male im Tester und Total_Time / Number_of_Ticks (mein oberster Beitrag) ausführen.

Wäre die Pufferverzögerung nicht, würde mein Code den Test in ~30 Sekunden bestehen - das ist ~2 mal schneller als MQL im "OpenCL-Stil" (55 Sekunden) und ~11 mal schneller als normaler Code (320 Sekunden).

Welche anderen Kriterien gibt es?

Ich verlange nicht, dass Sie alle meine Forumsbeiträge zu OpnCL erneut lesen. :) Dort werden alle grundlegenden Kriterien beschrieben und diskutiert.

Das Hauptkriterium ist das Verhältnis t_alg/t_mem, wobei t_alg - die algorithmisch optimierte Zeit für die Berechnung des Kernel-Algorithmus und t_mem - die Zugriffszeit auf den gelöschten (*) Speicher. Je länger dieses Kriterium ist, desto besser sind die Aussichten auf eine Beschleunigung durch OpenCL, d. h. je schwerer die Berechnungen und je weniger Array-Transfers zum und vom Gerät sind, desto besser sind die Aussichten.

(*) Fernspeicher = alle Arten von "Nicht-Register"-Speicher (Registerspeicher ist sehr schnell), z. B. (1) globaler Gerätespeicher ist viel langsamer als Registerspeicher, aber viel schneller als (2) Speicher außerhalb des Geräts (CPU RAM).

[Roffild]

Mathemat:

Dies ist kein Unsinn, sondern eine zufriedenstellende Anwendung.

Noch einmal: Schreiben Sie an servicedesk und begründen Sie, was Sie wollen. Wenn Sie das nicht verantworten können, ist das Ihr Problem.

Noch einmal: Bug #865549 vom 2013.10.17 23:17 und die Entwickler sind benachrichtigt, aber unwahrscheinlich, dass etwas zu beheben. Wahrscheinlich hat jemand diese Einschränkung absichtlich hinzugefügt, um nicht den gesamten Prozessor während der Optimierung auszusetzen.

Aber in den Artikeln wird kein Wort darüber verloren!

Mathemat:

Es ist an der Zeit, Ihr Gehirn einzuschalten, denn 0,35300 ms bezieht sich auf clEnqueue[Read/Write]Buffer() und nicht auf den globalen Speicherzugriff innerhalb des Kernels.

Dieser Befehl ist in der OpenCL für MQL5-Implementierung nicht vorhanden. Was soll das heißen?

Äh... Sie zitieren auch Artikel über OpenCL...

Nur damit Sie es wissen: clEnqueueReadBuffer = CLBufferRead und clEnqueueWriteBuffer = CLBufferWrite werden synchron aufgerufen.

Das Lernen beginnt hier

MetaDriver: Das Hauptkriterium ist das Verhältnis t_alg/t_mem, wobei t_alg die algorithmisch optimierte Berechnungszeit des Kernel-Algorithmus und t_mem die Zeit für den Zugriff auf den gelöschten (*) Speicher ist. Mit anderen Worten: Je "schwerer" die Berechnungen und je geringer die Array-Transfers zum und vom Gerät sind, desto größer ist das Beschleunigungspotenzial mit OpenCL.

Dies ist nur ein Kriterium zur Optimierung der Ausführung. Vor meinen Beiträgen gab es keine ungefähren Zahlen über die Übertragungsrate der Puffer selbst.

[Roffild]

Leute, bevor ihr weiter diskutiert, denkt über die drei Beiträge nach, die hier beginnen, und zwar über

mql5: In diesem speziellen Beispiel wird der Vorteil der Verwendung von OpenCL durch den Overhead beim Pufferkopieren aufgezehrt.

Weil Sie sich auf die Optimierung des Kernels selbst konzentrieren, während sich meine Beiträge mit Puffern befassen.

[Sceptic Philozoff]

Roffild: Nur damit Sie es wissen: clEnqueueReadBuffer = CLBufferRead und clEnqueueWriteBuffer = CLBufferWrite und sie werden synchron aufgerufen.

Ich weiß schon seit langem, dass die OpenCL-Implementierung für MQL5 nur ein Wrapper für die echte API ist. Übrigens habe ich in meinem zweiten Artikel geschrieben, dass die Möglichkeit der Einstellung der Arbeitsgruppengröße fehlt. Ich habe eine Anfrage an Servicedesk gestellt, und sie haben es nach einer Weile erledigt.

Ich weiß auch, dass CLBuffer[Read/Write] ähnlich wie clEnqueue[Read/Write]Buffer ist, aber diese Funktionen sind überhaupt nicht identisch: Sie haben unterschiedliche Syntaxen.

Aber ich verstehe nicht, warum Sie ständig über clEnqueueXXX-Funktionen sprechen, die in OpenCL für MQL5 nicht vorhanden sind.

Ich werde versuchen zu verstehen, was Sie wollen.

Roffild:

Es ist Zeit, Ihr Gehirn einzuschalten, denn 0,35300 ms bezieht sich auf clEnqueue[Read/Write]Buffer() und nicht auf den globalen Speicherzugriff im Kernel.

Das zweite Problem kann durch die Optimierung des Kernels selbst gelöst werden, während das erste eine eiserne Grenze darstellt.

Ja. Gegen wen haben Sie eine Beschwerde? Der Hersteller der Grafikkarte?

[Roffild]

Mathemat: Ich weiß auch, dass CLBuffer[Read/Write] analog zu clEnqueue[Read/Write]Buffer ist, aber diese Funktionen sind überhaupt nicht identisch: Sie haben unterschiedliche Syntaxen.

Aber ich verstehe nicht, warum Sie ständig über clEnqueueXXX-Funktionen sprechen, die in OpenCL für MQL5 nicht vorhanden sind.

Da gibt es keinen Unterschied. Wahrscheinlich gibt es eine solche Verpackung:

template<typename T>
cl_int BufferWrite(cl_mem buffer, const T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueWriteBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}
template<typename T>
cl_int BufferRead(cl_mem buffer, T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof(bufsize), &bufsize, 0);
        return (errcode = clEnqueueReadBuffer(enqueue, buffer, CL_TRUE, 0, bufsize, ptr, NULL, NULL, NULL));
}

Sie müssen sich also auch keine Syntax ausdenken. Die Tatsache, dass das 3. Argument = CL_TRUE ist, wurde bereits bestätigt.

Mathemat:

Das zweite Problem kann durch die Optimierung des Kerns selbst gelöst werden, während das erste Problem ein eiserner Zwang ist und das Gehirn nicht helfen wird.

Gut. Gegen wen haben Sie eine Beschwerde? Der Hersteller der Grafikkarte?

Die Beschwerde richtet sich an die Verfasser der Artikel, dass es keine praktischen Daten über diese wichtigste Einschränkung gibt! (Es gab keine, bis ich es getestet habe.)

[Vladimir Gomonov]

Roffild:

Die Beschwerde richtet sich an die Verfasser des Artikels, dass es keine praktischen Daten zu dieser wichtigsten Einschränkung gibt! (Es gab keine, bis ich es getestet habe.)

Und lesen Sie keine Artikel mehr, Sie werden sich nicht beschweren. ;)

--

Warum hacken Sie auf mir herum? Wie können Sie in einem Artikel unbekannte Daten zitieren? Die Verzögerung bei der Datenübertragung zu/von einem Gerät ist enorm und muss berücksichtigt werden? Die konkreten Zahlen hängen von der jeweiligen Hardware ab. Nun, Sie haben es an sich selbst getestet, und das ist gut für Sie. Manchmal erstellen Leute (mich eingeschlossen) Testcode, um die Möglichkeiten und Grenzen verschiedener Hardware abzuschätzen. Sie bitten andere Leute, ihre Ergebnisse mitzuteilen, und die Leute tun es oft (Hut ab dafür), gleichzeitig kann jeder Statistiken einsehen und sehen, was in welchen Kombinationen funktioniert. Dann kauft jemand neue Hardware oder ändert die Herangehensweise an das Schreiben von Code mit Blick auf die Ergebnisse. Schreiben Sie doch eine Beschwerde an Sportlotto, vielleicht funktioniert Ihr Code dann schneller...

:)

[Roffild]

Eigentlich habe ich schon alles auf https://www.mql5.com/ru/forum/13715/page5#comment_646513 erledigt , aber die Autoren der Artikel selbst wollten etwas anderes beweisen.

Ihre Artikel enthalten keine spezifischen und sehr wichtigen Informationen, sind also nicht fertig und beschreiben unrealistische Aufgaben.

Sie mögen den Artikeln keine Informationen hinzufügen, aber es ist dumm, so zu tun, als ob diese Zahlen nichts bedeuten.

[Sceptic Philozoff]

Ich verstehe den versteckten Sinn des Skripts/Ratgebers, den Sie gepostet haben, nicht, Roffild. Der Code ist, gelinde ausgedrückt, unverständlich.

- Wo befindet sich das Pragma cl_khr_fp64? Man braucht sie, wenn man im Kernel mit Double rechnet.

- Warum befindet sich dieses Codestück in der OnTick()-Funktion, das durch einmaliges Berechnen in die anfängliche Initialisierung eingefügt werden kann?

uint units = (uint)CLGetInfoInteger(hcontext, CL_DEVICE_MAX_COMPUTE_UNITS);
uint global_work_offset[] = {0};
uint global_work_size[1];
uint local_work_size[1];
global_work_size[0] = ArraySize(price);
local_work_size[0] = global_work_size[0] / units;

- Warum ist die Größe der globalen Aufgabe gleich 240 Byte? Sie müsste viel größer sein, um von OpenCL profitieren zu können. Nun, sie sollte mindestens eine Million Mal größer sein, wenn man nur nach dem Auge urteilen kann.

- Warum sollte eine globale Aufgabe durch die Anzahl der Einheiten geteilt werden, um die Größe einer lokalen Aufgabe zu erhalten? Sowohl CPU als auch GPU ermöglichen es, eine globale Aufgabe in eine viel größere Anzahl von Teilaufgaben zu unterteilen. Und Einheiten ist in Ihrem Fall nur eine Anzahl von SIMD-Engines.

Sagen wir, ich habe zum Beispiel 28 Einheiten in meiner Grafikkarte (Radeon HD7950). Aber diese Zahl ist nicht genau durch 240 teilbar. Das bedeutet, dass ein erheblicher Teil der Berechnungen nicht parallel sein kann.

Die Anzahl der Shader, die ich habe, beträgt 1792. Ihre ist 1440. Das ist in etwa die Zahl, die man für das korrekte Laden der Karte in der globalen Aufgabe unterbringen sollte. Sie müssen jedoch die korrekte Größe der Gesamtaufgabe berechnen. (Und es ist besser, nicht zu dividieren, sondern zu multiplizieren.)

Und was Ihre Karte die ganze Zeit über zählt, ist überhaupt nicht klar.

Kurz gesagt: Was soll Ihr Code tun?