OpenCl und die dazugehörigen Werkzeuge. Bewertungen und Eindrücke. - Seite 28
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
In ein paar Jahren werden wir Sie an diesen Thread erinnern.
Für mich persönlich war dieser Zweig sehr nützlich - selbst als der Themenstarter begann, meinen unreifen Geist vor der verminderten Genauigkeit von Berechnungen zu erschrecken.
Der Optimierungsmodus von MT5 ist sehr langsam , wenn der genetische Algorithmus aktiviert ist. Ich habe einen Expert Advisor auf MT4 erstellt und ihn getestet und optimiert. Die Optimierungszeit beträgt nicht mehr als 5 Minuten auf einem Dual-Core-System (natürlich hat MT4 nur einen Kern, aber andere Aufgaben stören nicht, da sie auf dem zweiten Kern laufen können). Ich habe den gleichen Expert Advisor für MT5 umgeschrieben. Ich habe sie zur Optimierung getestet. Die Optimierungszeit beträgt mehr als eine Stunde, um genau zu sein fast 2 Stunden. Worin besteht der Unterschied?
Es gibt keinen Unterschied mehr.
Nun, MetaTrader 5 scheint sogar beim Testen nach Eröffnungskursen die Nase vorn zu haben: Vergleich der Testgeschwindigkeit in MetaTrader 4 und MetaTrader 5
Wie versprochen, haben wir den Testmodus zum Öffnen der Bar vereinfacht und beschleunigt.
Nun, es sind zwei Jahre vergangen.
Die CUDA-Version des EA funktioniert. Unter MT4. Bisher befindet sie sich nur im Testmodus. Bislang kann ich die von nVidia versprochene Beschleunigung der Berechnungen nicht erreichen.
Hier gibt es zwei Probleme:
1. nVidia selbst, das die Geschwindigkeit der Umgestaltung von Programmen übertreibt, oder seine Dokumentation überhaupt nicht erstellt, oder einige wesentliche Aspekte der Programmierung grundlegend ändert.
2. Die Parallelisierung von Algorithmen unter GPU dauert viel länger als erwartet. Als ich anfing, ein Programm von DLL auf CUDA-DLL zu portieren, dachte ich mir, basierend auf meiner mehr als 20-jährigen Erfahrung mit der Sprache Caelian, dass die Versprechungen von nVidia durch 3 geteilt werden sollten und die von ihnen angegebene Zeit für die Portierung des Algorithmus mit, sagen wir, 3 multipliziert werden sollte.
Aber es stellte sich heraus, dass die allgemeine Regel lautet: Alle Versprechungen von nVidia müssen durch Zehner geteilt werden und die geschätzte Zeit der Portierung von C auf CUDA muss mit 10 multipliziert werden.
Hinweis: Wenn Sie die Grundsätze der Funktionsweise von GPU-Beschleunigern verstanden haben, können Sie den Algorithmus in DREI WOCHEN von C auf CUDA portieren. Und Sie können es direkt tun - nur um den Aufbau zu überprüfen. Das heißt, Ihr Programm wird von NUR EINEM von Hunderten oder Tausenden von kleinen Prozessoren in der Videokarte ausgeführt. Dies läuft etwa 70 (siebzig) Mal LANGSAMER als auf der CPU. Ja, langsam, aber es funktioniert.
Dann können Sie mit deutlich mehr Aufwand Ihr Programm parallelisieren. Dies funktioniert bereits 4-5 mal langsamer oder nur 2-3 mal schneller als beim Zentralprozessor.
Und Ihren ALGORITHM global zu modifizieren, so dass er in PASSIONS, ich wiederhole in PASSIONS, ausgeführt wird und nicht sequentiell, wie man es Ihnen an allen Universitäten der Welt beibringt, das ist eine schwierige Aufgabe.
Um es klar zu sagen: Es ist schwierig, aber nicht ungewöhnlich, einen gewöhnlichen sequentiellen Algorithmus nach dem Multithreading-Prinzip zu parallelisieren. Das ist eine Sache. Auf der GPU erhalten Sie auf die gleiche Weise eine 5-10-fache Beschleunigung. Aber den sequentiellen Algorithmus in einen Bunch-Algorithmus umzuwandeln (ich habe kein besseres Wort in meinem Wortschatz), Hunderte und Tausende von GPU-Prozessoren zu belasten und die von nVidia versprochene 100-fache Beschleunigung zu erreichen - das kann ein Problem sein.
Aber auch das ist lösbar. Es ist nur eine Frage der Zeit.
Aber es gibt auch die Krim, die Benderiten und so weiter .....
3. MetaTrader-4 hat keine Probleme beim Schreiben einer DLL für CUDA.
Das Problem ist, dass die nVidia-Softwareentwickler (2500 Personen) mit dem in MetaTrader-4-5 verwendeten Multithreading-Modell nicht einverstanden sind. Nvidia hat dieses Modell grundlegend geändert, als sie von CUDA 3.2 auf 4.0+ umgestellt haben. Und wenn Sie sie fragen, warum das so war (wie bei Metatrader-4 und Hunderten von anderen Multi-Thread-Programmen) und jetzt so ist, werden Sie als Antwort nur hören : "Sie haben unser kAnstment grundlegend missverstanden".
Das habe ich schon mal irgendwo gehört.... kürzlich.....
4. Es ist viel einfacher, einen neuen Algorithmus von C nach CUDA zu übersetzen als direkt von C nach generischem OpenCL, daher empfehle ich diesen Weg. Zumal nVidia gerade heute offiziell CUDA-6 vorstellen soll, mit dem es theoretisch möglich sein wird, auf den neuen Maxwell-Serien-GPUs und unter einigen Betriebssystemen den Programmieraufwand deutlich zu reduzieren - durch Speichervereinheitlichung und Wegfall von Weiterleitungsoperationen zwischen CPU und GPU.
Und?
Und?
Niemand ist daran interessiert?
Seit einem Jahr keine einzige Frage und kein einziger Beitrag.
Aber es ist interessant für Nvidia: sie haben meine Beschwerden in diesem und anderen Foren gelesen, haben ihren Kunstrat zusammengetrommelt, ihn in jeder möglichen Weise gerieben - und entschieden, dass Händler auch Menschen sind, und dass das Handelsterminal auch ein Programm ist, und haben in der neuesten Version von CUDA einen speziellen Schlüssel für den Compiler eingeführt - um ein hochgradig multithreaded Programme in CUDA zu erstellen.
http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/
eine Zeichenfolge wie
nvcc --default-stream per-thread ./pthread_test.cu -o pthreads_per_thread
Leider hat sich auch der Xeon Phi nicht durchgesetzt. Und es ist noch näher an der konventionellen Programmierung.
Wer Leistung für universelle Berechnungen benötigt, kann sie jetzt leicht und ohne große Belastung von Mehrprozessorsystemen für allgemeine Zwecke erhalten. Die Anzahl der Kerne in Intel-Prozessoren wächst schnell genug.
Unsere Server haben zum Beispiel jeweils 40 Kerne, ich habe sogar einen Arbeitsrechner mit 20 Kernen und DDR4-Speicher. Ein Server mit 40 Xeon-Kernen mit 3 GHz schlägt eindeutig einen Xeon Phi mit niedriger Frequenz und 56 oder mehr Kernen, ohne dass eine einzige Zeile Code umgeschrieben werden muss.
Wer Leistung für Mehrzweckberechnungen benötigt, kann sie jetzt leicht und ohne große Belastung von Mehrzweck-Multiprozessorsystemen erhalten. Die Anzahl der Kerne in den Intel-Prozessoren wächst recht schnell.
Unsere Server haben zum Beispiel jeweils 40 Kerne, ich habe sogar einen Arbeitsrechner mit 20 Kernen und DDR4-Speicher. Ein Xeon-basierter Server mit 40 Kernen bei 3 GHz schlägt eindeutig einen Xeon Phi mit 56 oder mehr Kernen bei niedriger Frequenz, ohne dass eine einzige Zeile Code neu geschrieben werden muss.
Sie irren sich leicht (2 Mal. Beide.). Im Grunde genommen dachte ich das auch, vor allem, als ich in die GPU-Programmierung einstieg.
(1). Die "Leistung in universellen Berechnungen" auf einer Host-CPU kann NUR für die einfachsten Algorithmen leicht erreicht werden. Das ist der Knackpunkt für die meisten OpenMP- und GPU-Programmierer. Es werden Hunderte von Millionen CUDA-Grafikkarten verkauft, aber nur etwa 300 Programme für sie. Für Finanzen - nur etwa 7-8 (ohne die Sammlungen nutzloser Bibliotheken).
Die vollständige Liste finden Sie auf der nVidia-Website:
http://www.nvidia.com/object/gpu-applications.html?cFncE
(Unser erster kommerziell verfügbarer CUDA-beschleunigter EA für MT4-Handelsterminal ist *noch* nicht da).
Diese Liste hat sich seit mehreren Jahren nicht geändert.
Und warum? Nun, da sich der komplexe adaptive Algorithmus, der auf einer Host-CPU leicht aus Teilen zusammengesetzt werden kann , herausstellt, dass es nicht ausreicht, ihn zu programmieren, muss er BREAK. Und das ist gar nicht so einfach, denn :
a). Besonderheiten und Einschränkungen des CUDA-OpenCL-GPU-Modells (Kernel unterschiedlicher Größe sollten nacheinander ausgeführt werden).
b). Jegliche Datenübertragung über den PCI-Bus zwischen der GPU und dem Host-Prozessor macht den gesamten Geschwindigkeitsgewinn zunichte. Und bei komplexen adaptiven Algorithmen kommt man ohne sie nicht aus.
(2). "keine einzige Zeile Code neu geschrieben werden muss" gilt ebenfalls nur für einfache Algorithmen. Die Situation wird dadurch verschlimmert, dass OpenMP - als echte Alternative zur GPU - auf mysteriöse Weise funktioniert, d.h. manchmal funktioniert es, und manchmal produziert es Müll. Es ist eine Illusion, dass durch das Hinzufügen einer Pragma-Zeile an einer Stelle der Algorithmus sofort parallelisiert wird. Sie ist weit davon entfernt. In einem komplexen Algorithmus treten so unerwartete Korrelationen zwischen Daten und parallelen Threads auf, dass wir auf die Konstruktion eines Graphen nicht verzichten können.
Die GPU ist eine ganz andere Sache. Am Anfang gibt es mehr zu tun, aber das Programm funktioniert IMMER korrekt, was das Timing angeht. Außerdem wird ein für CUDA umgeschriebenes Programm (auch ohne die Kernel zu schreiben) durch eine Zeile pragma AKTIV in OpenMP übersetzt und DAS funktioniert auch. Es macht überhaupt keinen Sinn, es erst danach in OpenMP zu übersetzen - es wäre viel perspektivischer und zuverlässiger, Kernel für CUDA-OpenCL hinzuzufügen. Überraschenderweise erweisen sich die Kernel für CUDA-GPUs als kurz, klar und zuverlässig.
Nun, was die absolute Geschwindigkeit und Zuverlässigkeit angeht, hat die Host-CPU keine Chance gegen die GPU.
=Die Finanzmärkte und insbesondere die Devisenmärkte sind eine SEHR komprimierte Version riesiger Prozesse rund um den Globus.
=Aus diesem Grund kann ein Algorithmus zur Preisvorhersage nicht einfach sein. Deshalb muss sie heutzutage adaptiv und im übertragenen Sinne statistisch sein.
=Ohne Simulation und adaptive Rückkopplung in einem so guten Algorithmus gibt es also keinen Ausweg.
=Wenn also die Host-CPU für die Auftragserteilung noch brauchbar ist (d.h. ihre Geschwindigkeit noch ausreicht), ist es fast unmöglich, zu Test- und Optimierungszwecken ohne GPU zu arbeiten.
Sie haben zweimal behauptet, ich hätte mich geirrt, und dann unter dem Deckmantel des Beweises einen völlig fremden Beweis angeführt.
Ich habe Recht mit dem Folgenden (was sofort gesagt wurde):
Ich habe OpenMP noch gar nicht erwähnt. Meiner Ansicht nach ist OpenMP eine "Silberkugel für Weicheier". Wenn Sie um echte Leistung kämpfen, sollten Sie den OpenMP-Unsinn loswerden und von Hand ursprünglich korrekten/nativen Multithreading-Code schreiben, ihn profilieren und bis zum Maximum ausreizen.
Sie selbst haben bewiesen, dass es nicht genug Software für GPU-Computing gibt. Bei den meisten GPU-Programmen handelt es sich nur um die einfachsten Fälle, darunter Passwortknacker und dumme Miner (Spiele werden nicht behandelt).
Meiner Meinung nach entwickeln sich CPUs und die zugrundeliegende Infrastruktur schnell genug weiter, um die Leistung von GPUs in realen Anwendungen zu übertreffen. Vor 3-4 Jahren hätte man noch an das Potenzial von GPUs glauben können, aber jetzt ist es klar geworden.
Sie haben zweimal behauptet, ich hätte mich geirrt, und dann unter dem Deckmantel des Beweises einen völlig irrelevanten Beweis angeführt.
Ich habe Recht mit dem Folgenden (was sofort gesagt wurde):
Ich habe OpenMP noch gar nicht erwähnt. Meiner Ansicht nach ist OpenMP eine "Silberkugel für Weicheier". Wenn Sie um echte Leistung kämpfen, lassen Sie den OpenMP-Unsinn beiseite und schreiben Sie von Hand ursprünglich korrekten/nativen Multithreading-Code, profilieren Sie ihn und treiben Sie ihn auf die Spitze.
Sie selbst haben bewiesen, dass es nicht genug Software für GPU-Computing gibt. Bei den meisten GPU-Programmen handelt es sich nur um die einfachsten Fälle, einschließlich Passwort-Crackern und dummen Minern (Spiele stehen nicht zur Diskussion).
Meiner Meinung nach entwickeln sich CPUs und die zugrundeliegende Infrastruktur schnell genug weiter, um die Leistung von GPUs in realen Anwendungen zu übertreffen. Vor 3-4 Jahren hätte man noch an das Potenzial von GPUs glauben können, aber jetzt ist es klar geworden.
1. Wenn man die Wachstumsrate der Kerne von der Host-CPU extrapoliert, ist es unwahrscheinlich, dass ihre Anzahl in den nächsten Jahren 3000 Kerne erreichen wird, wie HEUTE eine gute Grafikkarte hat. Und jeder Kern der Grafikkarte läuft mit etwa 1 GHz. Es wäre also für einen Host-Prozessor unmöglich, mit der GPU zu konkurrieren. Aber das setzt voraus, dass es ein gutes Programm gibt, das nicht nur mit diesen 3000 Kernen arbeiten kann, sondern auch alle Tücken der heutigen GPU-Hardware-Architektur aufnimmt. Und die Videogeschwindigkeit des GDDR5-Speichers auf einer durchschnittlichen Grafikkarte liegt heute bei etwa 150 GByte/Sekunde. Alle Arten von DDR4-Speicher (25 GB/Sek.) haben noch einen langen Weg vor sich.
Wie kann ein Host-Prozessor mit 40-60 Kernen konkurrieren, selbst bei 4 GHz und 25 Gb/s Speicher?
2. Alle Arten von Exoten wie Phi haben nicht die notwendige Unterstützung und Vielseitigkeit wie eine Grafikkarte. Deshalb sind sie ausgestorben.
3. über die Notwendigkeit der direkten Multithreading-Programmierung - ja, ich stimme Ihnen zu, aber es ist eine mühsame Aufgabe. Es ist sehr schwierig, einen komplexen NEUEN adaptiven Algorithmus in einer Multithreading-Version auf einmal zu schreiben. Und man muss sozusagen mit der Evolution arbeiten. Außerdem brauche ich Ihnen nicht zu sagen, wie schlecht Windows mit Multi-Threads umgeht, wenn es wirklich viele davon gibt (es gibt alle Arten von Verzögerungen). Deshalb hat sogar das Betriebssystem so genannte Fasern entwickelt - vereinfachte Fäden.
Fazit: Es gibt nichts Günstigeres, Erfolg versprechenderes und Zuverlässigeres als GPU.