OpenCl und die dazugehörigen Werkzeuge. Bewertungen und Eindrücke. - Seite 6
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
Ich vermute, dass es das ist, was Mischek vor einem Monat geschrien hat.
Ich sehe die Anwendung von OpenCL entweder in umfangreichen Tests oder in sehr intensiven parallelisierten Berechnungen im laufenden Betrieb.
Bisher brauche ich das nicht (alle schweren Berechnungen sind in meinem init() des Induktors), aber es ist erwähnenswert.
Alexey, ich habe das gleiche Problem: Ich versuche, etwas in init zu ziehen, und dann in Echtzeit :)
Mein Gehirn ist auf eine prozedurale Sprache eingestellt. OOP ist wünschenswert, aber nicht zwingend erforderlich.
Für die fanatischen B4-Fans, die nicht mql5.com besuchen: OpenCL: interne Tests der Implementierung in MQL5
Danke, das habe ich persönlich nicht gesehen. Aber so einfach ist das nicht.
Außerdem verwirrt Rinat die Leute: OpenCL 1.0 kann problemlos mit Double Float arbeiten, es ist eine "öffentliche Option", die von allen Herstellern unterstützt wird - ABER NICHT FÜR ALLE ALTEN KARTEN.
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
"Optionale doppelte Präzision und halbes Fließkomma
OpenCL 1.0 fügt Unterstützung für Double Precision und Half Floating Point als optionale Erweiterungen hinzu. Der Datentyp double muss dem Speicherformat IEEE-754 double precision entsprechen.
Eine Anwendung, die double verwenden möchte, muss die Direktive #pragma OPENCL EXTENSION cl_khr_fp64 : enable einfügen, bevor ein Datentyp mit doppelter Genauigkeit im Kernel-Code deklariert wird. Damit wird die Liste der eingebauten Vektor- und Skalardatentypen um folgende Typen erweitert: .....".
Es kann im Strategy Tester funktionieren, aber es wird nicht im OpenCL 1.0 Expert Advisor funktionieren, nicht weil, wie Rinat sagt, "es dort keinen Double Float gibt", sondern, wie ich bereits erwähnt habe, weil es kein Safe Threading in OpenCL 1.0 gibt und es kein Threading in MT4-5 gibt.
OpenCL (und CUDA) ist im Allgemeinen verwirrend. Was wollen Sie? Schließlich wollten die Eisen- und Radiotechniker das Konzept der Programmierung verändern. Sie haben eine eiserne Mentalität.
Es gibt auch ein Problem mit der so genannten "PLATFORM SELECTION": das Programm, d.h. MT oder DLL oder Expert Advisor, MUSS die Plattform (AMD, Nvidia, Intel) auswählen, die mehrere verschiedene sein kann, auf der der OpenCL-Anschluss läuft, und dann manuell DEVICE auswählen, wenn Ihr Computer mit Multi-GPU läuft. Die automatische Plattformauswahl in OpenCL ist noch nicht vorhanden. Rinat spricht von "automatischer Auswahl des Stärksten", aber ich weiß nicht, wie das geht. In dem dort gezeigten Beispiel gibt es keine Plattformauswahl und keine Geräteauswahl (GPU, CPU).
Außerdem gibt es im Standard noch keine automatische Parallelisierung von OpenCL-Aufgaben auf mehreren GPUs oder auf GPU+CPU. Sagen wir es mal so: AMD hat in einigen Versionen seiner Treiber/SDKs ein solches Autoprovisioning eingeführt, aber es gab einige Probleme und AMD hat diese Funktion vorerst abgeschaltet.
Fazit: Die Entwicklung und Aktivierung von OpenCL-Programmen mit MT4-5 erfordert einen gewissen manuellen Aufwand und funktioniert daher nicht automatisch oder durch "Neukompilierung mit Option". Das wiederum ist im realen Betrieb mit einer Vielzahl von Verzögerungen verbunden. Es wird eine subtile Arbeit sein, und, was wichtig ist, ich erlaube mir zu wiederholen, es ist leider JEWISH ORIENTED PROGRAMMING, das falsch ist. Das Debuggen von parallelen Programmen für CUDA oder OpenCL erwies sich als viel schwieriger, als die eisernen Revolutionäre annahmen. Nvidia hat sogar seine CUDA-Konferenz im Herbst 2011 abgesagt - aufgrund von Treiberproblemen und einer Vielzahl von Beschwerden über stockendes Debugging. Sie haben also dem neuesten Toolkit weitere 1000 neue Funktionen hinzugefügt - und was macht man damit, wenn die einfachsten Programme gar nicht oder nur mit Unterbrechungen ausgeführt werden können? Schließlich haben sie in ihren Beschreibungswerkzeugen nicht einmal die Hälfte der internen Mechanismen von OpenCL oder CUDA erwähnt.
Die GPU-Geschwindigkeit (in GigaFLOPS) einer hängenden Grafikkarte aufgrund von Treiber- oder Softwarekompatibilität ist Null.
Danke, ich habe es nicht persönlich gesehen. Aber so einfach ist das nicht.
....Darum geht es eigentlich nicht. Sie können auf einer Fünf im Verfahrensstil schreiben.
joo: Und diese Tatsache entmutigt mich, akhtung! - MQL4 Aufruf dll funktioniert schneller als MQL5 Aufruf der gleichen dll...
Das ist es, was so beunruhigend ist.
Sie hätten eine native Unterstützung für OMP in MQL5 entwickeln können. Es wäre einfach und billig für den Programmierer, und es ist nicht nötig, eine DLL zu schreiben.
Aber dieser Bienenschwarm in einer unvollständigen eisernen Programmiersprache... inspiriert mich noch nicht wirklich. Ja, eine hundertfache Beschleunigung ist in manchen Fällen großartig, aber in Bezug auf die Programmierkultur ist es ein Rückschritt.
Es gibt eine Menge Verwirrung bei OpenCL (und CUDA) im Allgemeinen. Was wollen Sie? Schließlich haben sich die Eisen- und Radiotechniker vorgenommen, das Konzept der Programmierung zu verändern. Sie haben eine eiserne Mentalität.
Es gibt auch ein Problem mit der so genannten "PLATFORM SELECTION": Das Programm, d.h. MT oder Expert DLL oder EA, MUSS die Plattform (AMD, Nvidia, Intel) auswählen, die auf Ihrem Computer mehrere verschiedene sein können und auf der der OpenCL Connector laufen wird, und dann manuell DEVICE auswählen, wenn Ihr Computer mit Multi-GPU läuft. Die automatische Plattformauswahl in OpenCL ist noch nicht vorhanden. Rinat spricht von "automatischer Auswahl des Stärksten", aber ich weiß nicht, wie das geht. In dem dort gezeigten Beispiel gibt es keine Plattformauswahl und keine Geräteauswahl (GPU, CPU).
Außerdem gibt es noch keine Standardmethode zur automatischen Parallelisierung von OpenCL-Aufgaben über mehrere GPUs oder über GPU+CPU. Sagen wir es mal so: AMD hat in einigen Versionen seiner Treiber/SDKs eine solche Autoparallelisierung implementiert, aber es gab Probleme und AMD hat sie bisher abgeschaltet.
Fazit: Die Entwicklung und Aktivierung von OpenCL-Programmen mit MT4-5 erfordert einen gewissen manuellen Aufwand und funktioniert daher nicht automatisch oder durch "Neukompilierung mit Option". Das wiederum ist im realen Betrieb mit einer Vielzahl von Verzögerungen verbunden. Es wird ein gutes Werk sein, und, was wichtig ist, ich erlaube mir zu wiederholen, es ist leider JEWISH ORIENTED PROGRAMMING, das falsch ist. Das Debuggen von parallelen Programmen für CUDA oder OpenCL erwies sich als viel schwieriger, als die eisernen Revolutionäre annahmen. Nvidia hat sogar seine CUDA-Konferenz im Herbst 2011 abgesagt - aufgrund von Treiberproblemen und einer Vielzahl von Beschwerden über stockendes Debugging. Sie haben also dem neuesten Toolkit weitere 1000 neue Funktionen hinzugefügt - und was macht man damit, wenn die einfachsten Programme gar nicht oder nur mit Unterbrechungen ausgeführt werden können? Schließlich haben sie in ihren Beschreibungswerkzeugen nicht einmal die Hälfte der internen Mechanismen von OpenCL oder CUDA erwähnt.
Die GPU-Geschwindigkeit (in GigaFLOPS) einer aufgrund von Treiber- oder Softwarekompatibilität hängenden Grafikkarte ist gleich Null.
Darum geht es eigentlich nicht. Sie können auch auf 5 in einem prozeduralen Stil schreiben.
Aber das ist alarmierend.
Sie hätten eine native Unterstützung für OMP in MQL5 entwickeln können. Es ist einfach und sauber, es muss kein dll geschrieben werden.
Aber dieser Bienenschwarm in einer unvollständigen Hardware-Programmiersprache... ...scheint nicht sehr aufregend zu sein. Ja, eine hundertfache Beschleunigung in einigen Fällen ist großartig, aber in Bezug auf die Programmierkultur ist es ein Rückschritt.
Ich habe auch festgestellt, dass mql4 schneller arbeitet als MQL5. In den meisten Fällen manifestiert sie sich in mathematischen Operationen, die vom Programmierer optimiert werden.
Aber ich denke, das ist nicht das Hauptproblem - durch die Verwendung von OpenCL MQ haben sie einen Weg eingeschlagen, der parallel zum Hauptprogrammierungspfad verläuft - vielleicht erfordert dies bisher einen Schritt zurück, aber in der zukünftigen Entwicklung der Computertechnologie werden wir integrierte skalierbare Systeme sehen, bei denen es bereits vom Code abhängt, ob die sequentielle oder parallele Verarbeitung verwendet wird.
Der Weg ist also genau richtig. Obwohl es heutzutage nicht so viele Algorithmen gibt , die die Implementierung paralleler Ansätze erfordern, liegt das eher daran, dass es in der Mathematik noch keine Ausrüstung für die Implementierung paralleler Berechnungen gab und daher keine Notwendigkeit bestand, solche Algorithmen zu entwickeln.
Alexey, denken Sie nur an eine Tatsache, alle mathematischen Entdeckungen wurden vor 200-300 Jahren gemacht, die letzten 100 Jahre war das mathematische Denken nur Polieren, was ist. Erst die Entdeckung des Nationalsozialismus hat den Bedarf an Parallelrechnungen geweckt. In den nächsten 100 Jahren werden die Algorithmen wesentlich paralleler sein. Und unter anderem Sie können eine davon erfinden.
Ich habe auch Tatsachen gesehen, dass mql4 schneller ist als MQL5. Dies ist am häufigsten bei vom Programmierer optimierten Matrixoperationen zu beobachten.
Aber ich denke, das ist nicht das Hauptproblem - mit dem Einstieg in OpenCL hat MQ einen Weg eingeschlagen, der parallel zum Hauptweg der Programmierung verläuft; vielleicht erfordert dies bisher einen Schritt zurück, aber in der zukünftigen Entwicklung der Computertechnologie werden wir integrierte skalierbare Systeme sehen, bei denen es bereits vom Code abhängt, ob die sequentielle oder parallele Verarbeitung genutzt wird.
Der Weg ist also genau richtig. Obwohl es heutzutage nicht so viele Algorithmen gibt , die eine parallele Implementierung erfordern, liegt das eher daran, dass es in der Mathematik keine Ausrüstung für die Implementierung von parallelen Berechnungen gab und daher keine Notwendigkeit bestand, solche Algorithmen zu entwickeln.
Alexey, denken Sie nur an eine Tatsache, alle mathematischen Entdeckungen wurden vor 200-300 Jahren gemacht, die letzten 100 Jahre mathematisches Denken war nur Polieren, was ist. Erst die Entdeckung des Nationalsozialismus hat die Forderung nach parallelen Berechnungen hervorgebracht. In den nächsten 100 Jahren werden die Algorithmen wesentlich paralleler sein. Und unter anderem Sie können eine davon erfinden.
Nein, Sie sind nicht ganz hoffnungslos. :)
Hallo.
MQ sind gut, sie hatten keine Angst, sich mit einem solchen Schmerz (für sie) wie die Einführung der Unterstützung für GPU-Berechnungen. Der Schmerz hängt in erster Linie damit zusammen, dass die Einführung grundlegend neuer Technologien die Zuverlässigkeit und Fehlertoleranz der Plattform als Ganzes zunächst verringert. Aber sie verstehen sehr gut, dass die Zukunft dem parallelen Rechnen gehört und dass sie früher oder später etwas in dieser Richtung tun müssen (der erste Schritt wurde bereits getan - Cloud).
PS Hallo Nikolai. Warum bist du verschwunden? - Schreiben Sie mir eine Nachricht.
Dies ist keine Tatsache, denn sie ist es nicht. Die qualitative Entwicklung der Mathematik ist nie unterbrochen worden.
Und parallele Berechnungen werden nicht nur von NS benötigt, sondern es gibt auch profanere Aufgaben, z. B. Videocodierung oder Rendering.
Aber der allgemeine Vektor der MQ-Bewegung ist sicherlich ermutigend.