3. BOINC Pentathlon - Collatz Diskussionsthread
- Ersteller thorsam
- Erstellt am
WindHund
Grand Admiral Special
Schon geschehen.
Ist ungültig gleich zu setzen mit Error?
Das Postfach von Gipsel ist voll, ich habe ihm eine Profil Nachricht hinterlassen.
Solange auch gültige WU´s dabei sind, ist mir das im moment egal.
MagicEye04
Grand Admiral Special
Also über die Trägheit kann ich mich absolut nicht beschweren.
Ich merke zum Glück nix davon, dass auf der Karte was gerechnet wird, sogar Videos schauen kann ich nebenbei noch ruckelfrei.
Edit: Schwupp, schon ist es wieder passiert und es rechnet nur noch eine WU auf der GPU - mitten im laufenden Betrieb.
Zuletzt bearbeitet:
Kater Sylvester
Grand Admiral Special
2.832.750 credit pending 
Sagi T
Grand Admiral Special
372.375.00
.
EDIT :
.
Yopp, habe ich auch schon gesehen...
Habe den Takt gestern mal gesenkt, mal sehen ob es hilft. Aber wenn Fehler dann sollten doch alle falsch sein und nicht nur vereinzelt. Das verstehe ich nicht...
.
EDIT :
.
Yopp, habe ich auch schon gesehen...
Habe den Takt gestern mal gesenkt, mal sehen ob es hilft. Aber wenn Fehler dann sollten doch alle falsch sein und nicht nur vereinzelt. Das verstehe ich nicht...
Sabroe SMC
Grand Admiral Special
Pending credit: 800,250.00
Habe den Takt gestern mal gesenkt, mal sehen ob es hilft. Aber wenn Fehler dann sollten doch alle falsch sein und nicht nur vereinzelt. Das verstehe ich nicht...
du brauchst für deine amd 7970 die optimierte opencl app, so wie es Sabroe SMC schon geschrieben hat. http://boinc.thesonntags.com/collatz/power_apps.php
die app installierst du bei win7 ins verzeichnis
C:\ProgramData\BOINC\projects\boinc.thesonntags.com_collatz
(ist ein versteckter ordner)
Emploi
Grand Admiral Special
Wenn wir alle auf Mini only umstellen, könnten wir uns dadurch einen taktischen Vorteil sichern?
tspoon
Grand Admiral Special
Bei schwachen Grafikkarten empfiehlt sich minis zu verwenden (HTPC, Laptop, Büro etc).
Ich hab aktuell soviele 3000 auf Lager, da mach ich jetzt mal ne Runde Minis zum Vergleich.
Ich hab aktuell soviele 3000 auf Lager, da mach ich jetzt mal ne Runde Minis zum Vergleich.
Zuletzt bearbeitet:
Opteron hat mir eine PN geschrieben (die letzte, die ins Postfach paßte ![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
). Ich packe meine Antwort an ihn auch einfach mal hier ins Forum.
===============
Um ehrlich zu sein, bin ich da schon eine Weile raus. Allerdings muß ich gestehen, daß ich kürzlich mitbekommen habe, daß da nicht alles rund läuft. Ich habe auch schon mit dem Gedanken gespielt, mich da mal wieder zu melden (ich habe natürlich noch die email-Adresse vom Chef da, Jon Sonntag aka Slicker). Allerdings könnte das kurzfristig wohl vielleicht schwierig werden.
Das Problem ist, daß AMD die Spezifikationen für CAL bzw. die Intermediate Language für Tahiti etwas geändert hat (haben sie für Cayman auch schon gemacht, aber das war sehr minimal, trotzdem mußte MW@home angepaßt werden). Allerdings gibt es noch keine Dokumentation dafür und es ist zweifelhaft, daß es sie je geben wird, da AMD IL/CAL wohl als offizielle Schnittstelle auslaufen läßt (eventuell geben sie irgendwann direkt die ISA frei, für GCN kann man prinzipiell sehr viel einfacher low-level schreiben als für die VLIW-Architekturen). Da ist also Probieren angesagt oder eine Art Reverse Engineering ausgehend von OpenCL (man kann sich die IL Versionen von OpenCL-Kerneln erzeugen lassen, leider nicht die passenden CAL-Aufrufe dazu). Verkompliziert wird das noch dadurch, daß bei Collatz ein zusätzlicher (ebenfalls veralteter) Layer dazwischen liegt. Das ist ja am Anfang noch in Brook+ geschrieben worden und benutzt immer noch ein paar Routinen daraus, um eben sehr einfach auch für die älteren Architekturen möglichst effektiven Code zu haben (es werden z.B. gar keine ComputeShader genutzt sondern Pixelshader und die Lookup-Tables liegen in Texturen, die Ergebnisse werden in Textur-Buffer rausgeschrieben; die Sachen mit den Texturen sind über OpenCL [Image Extension] erst ab Cypress verfügbar).
Wo das eigentliche Problem liegt, kann ich so auf Anhieb nicht sagen. Ein wenig sieht es danach aus, daß entweder conditional moves auf GCN anders funktionieren (eher unwahrscheinlich) oder es eine Kohärenzgeschichte beim Zugriff auf die benutzten Arrays ist (Collatz nutzt Lese-Schreib-Zugriff und verläßt sich auf eine implizite Synchronisation beim Kernelaufruf, es findet keine explizite Synchronisation statt). Ich würde fast auf das Letztere tippen. Bei GCN ist ja ein kohärentes Cache-System dazugekommen, wo über Flags beim Speicherzugriff festgelegt wird, wie das genau gehandhabt wird (und anders als bei nVidia laufen auch die Texturen vollständig über die gleiche Cache-Hierarchie). Es ist halbwegs wahrscheinlich, daß dort was schiefläuft. Denn ich habe den Eindruck (habe mir gerade ein paar der Ergebnisse der GCN-GPUs im Vergleich zu Cypress angesehen), daß die GCN-Teile schon im Prinzip richtig rechnen, dann allerdings etwas beim Zusammenzählen der Schritte und Ermittlung der Zahl mit dem längsten Weg zur 1 öfter was schiefläuft. Und genau das geschieht über Lesen eines bzw. mehrerer Werte aus dem Speicher, Vergleichen und wieder Zurückschreiben, also genau da, wo die Kohärenzgeschichte dazwischenfunken könnte (es wird eventuell nicht immer der aktuelle Wert aus dem Speicher gelesen, sondern zum Teil ein veralteter, weil die Kohärenz bei GCN über eine explizite Synchronisation sichergestellt werden müßte; offenbar überlappt GCN die Ausführung mehrerer Kernel, so daß die implizite Synchronisation beim Aufruf nicht mehr funktioniert; ist aber nur eine Vermutung). Ich habe keine Ahnung, ob man das überhaupt auf die Schnelle in der IL-Version beheben könnte oder ob man da keinen ausreichenden Einfluß hat bzw. da etwas mehr umschreiben müßte. Kurz, eine Lösung auf dem Weg wäre vielleicht die performanteste (auch weil da noch mehr kleinteilige Optimierungen gegenüber einer C-ähnlichen Version drin sind, die wohl auch nochmal 15-20% bringen), ist aber vermutlich eher unwahrscheinlich.
Alternativ könnte man die OpenCL-Version etwas aufbohren und die alte Version für die GCN-GPUs sperren. Ich denke, man könnte bestimmt so 10-15% mehr Speed aus der OpenCL-Version rausholen. Slicker benutzt sehr wahrscheinlich nicht die cl_amd_media Erweiterung von OpenCL. Die stellt ein paar zusätzliche Befehle zur Bitmanipulation zur Verfügung (einer davon ist für Collatz ganz nützlich und war für ~2/3 des Geschwindigkeitsvorsprungs der Evergreens vor der HD4000er-Serie mit der alten Version verantwortlich).
Ich muß erstmal sehen, daß ich bei mir zu Hause die ganzen Entwicklungsumgebungen und SDKs wieder installiere. Dann kann ich Slicker mal nach dem aktuellen OpenCL-Quelltext fragen und schauen, was man da machen kann. Aber das ist sicher keine Lösung für morgen, das wird wohl mindestens eine Woche dauern.
Tut mir leid.
==================
Daß auch GCNs öfter mal WUs validiert bekommen, liegt übrigens daran, daß der Validator nur die Maximalschritte und die entsprechende Zahl vergleicht, nicht aber die Gesamtzahl der Schritte für die komplette WU. Wie oben gesagt, rechnet GCN im Prinzip schon richtig, nur der sogenannte "reduction kernel", der die Zwischenergebnisse (die in einem 256 bis 512MB großen Textur-Array liegen) zusammenrechnet arbeitet vermutlich nicht korrekt (wegen der oben erwähnten Kohärenzgeschichte). Trotzdem kommt es mit einer gewissen Wahrscheinlichkeit vor, daß die richtige Zahl (dann auch mit der richtigen Schrittanzahl, wie gesagt ist die eigentliche Berechnung bei GCN im Prinzip vermutlich schon richtig) dabei rauskommt. Nur die Gesamtschrittanzahl für die WU ist praktisch immer falsch und unterscheidet sich auch zwischen verschiedenen GCN-GPUs, es ist also mehr oder weniger zufällig, weswegen ich auf die Kohärenzgeschichte tippen würde.
PS:
Das bedeutet übrigens, daß die GCN-GPUs wahrscheinlich wirklich so schnell sind, wie es den Anschein hat, man müßte nur die Ergebnisse korrekt hinbekommen (GCN spart also keine Schritte ein, nur das Zusammenrechnen funktioniert nicht richtig). Der Grund dafür ist die relativ geringe Auslastung, die Collatz auf den VLIW-GPUs schafft. Auf der R600-Generation waren das irgendwas (aus dem Gedächtnis, also nur grobe Richtlinie) bei 2,2/5 Slots über ~2,7/5 bei der R700-Generation (full speed Bithifts) und den Evergreens/VLIW5-NIs (die sparen aber ein paar Bitshifts wegen Nutzung der bitalign-Instruktion, benötigen also weniger Befehle und sind deswegen schneller). Cayman/Trinity ist nicht ganz vergleichbar, weil Integer-Multiplikationen 4 Slots statt nur einem belegen, so daß die Belegung von 2,8/4 Slots pro Takt und Einheit etwas langsamer als bei den Evergreens ist. Aber genau das ist im Prinzip die Vergleichsbasis zu Tahiti (Integer-Multiplikationen sind dort auch nur 1/4 des Speeds). Nur hat man dort keine Probleme mehr mit der VLIW-Befüllung. Treten keine anderweitigen Limits (Speicher) auf, sollte der Speed einer HD7970 im Optimalfall
32/24 * 925/880 * 4/2,8 = 2,0 (CUs, MHz, Füllgrad)
Also grob das Doppelte einer HD6970 betragen.
Edit:
). Ich packe meine Antwort an ihn auch einfach mal hier ins Forum.===============
Um ehrlich zu sein, bin ich da schon eine Weile raus. Allerdings muß ich gestehen, daß ich kürzlich mitbekommen habe, daß da nicht alles rund läuft. Ich habe auch schon mit dem Gedanken gespielt, mich da mal wieder zu melden (ich habe natürlich noch die email-Adresse vom Chef da, Jon Sonntag aka Slicker). Allerdings könnte das kurzfristig wohl vielleicht schwierig werden.
Das Problem ist, daß AMD die Spezifikationen für CAL bzw. die Intermediate Language für Tahiti etwas geändert hat (haben sie für Cayman auch schon gemacht, aber das war sehr minimal, trotzdem mußte MW@home angepaßt werden). Allerdings gibt es noch keine Dokumentation dafür und es ist zweifelhaft, daß es sie je geben wird, da AMD IL/CAL wohl als offizielle Schnittstelle auslaufen läßt (eventuell geben sie irgendwann direkt die ISA frei, für GCN kann man prinzipiell sehr viel einfacher low-level schreiben als für die VLIW-Architekturen). Da ist also Probieren angesagt oder eine Art Reverse Engineering ausgehend von OpenCL (man kann sich die IL Versionen von OpenCL-Kerneln erzeugen lassen, leider nicht die passenden CAL-Aufrufe dazu). Verkompliziert wird das noch dadurch, daß bei Collatz ein zusätzlicher (ebenfalls veralteter) Layer dazwischen liegt. Das ist ja am Anfang noch in Brook+ geschrieben worden und benutzt immer noch ein paar Routinen daraus, um eben sehr einfach auch für die älteren Architekturen möglichst effektiven Code zu haben (es werden z.B. gar keine ComputeShader genutzt sondern Pixelshader und die Lookup-Tables liegen in Texturen, die Ergebnisse werden in Textur-Buffer rausgeschrieben; die Sachen mit den Texturen sind über OpenCL [Image Extension] erst ab Cypress verfügbar).
Wo das eigentliche Problem liegt, kann ich so auf Anhieb nicht sagen. Ein wenig sieht es danach aus, daß entweder conditional moves auf GCN anders funktionieren (eher unwahrscheinlich) oder es eine Kohärenzgeschichte beim Zugriff auf die benutzten Arrays ist (Collatz nutzt Lese-Schreib-Zugriff und verläßt sich auf eine implizite Synchronisation beim Kernelaufruf, es findet keine explizite Synchronisation statt). Ich würde fast auf das Letztere tippen. Bei GCN ist ja ein kohärentes Cache-System dazugekommen, wo über Flags beim Speicherzugriff festgelegt wird, wie das genau gehandhabt wird (und anders als bei nVidia laufen auch die Texturen vollständig über die gleiche Cache-Hierarchie). Es ist halbwegs wahrscheinlich, daß dort was schiefläuft. Denn ich habe den Eindruck (habe mir gerade ein paar der Ergebnisse der GCN-GPUs im Vergleich zu Cypress angesehen), daß die GCN-Teile schon im Prinzip richtig rechnen, dann allerdings etwas beim Zusammenzählen der Schritte und Ermittlung der Zahl mit dem längsten Weg zur 1 öfter was schiefläuft. Und genau das geschieht über Lesen eines bzw. mehrerer Werte aus dem Speicher, Vergleichen und wieder Zurückschreiben, also genau da, wo die Kohärenzgeschichte dazwischenfunken könnte (es wird eventuell nicht immer der aktuelle Wert aus dem Speicher gelesen, sondern zum Teil ein veralteter, weil die Kohärenz bei GCN über eine explizite Synchronisation sichergestellt werden müßte; offenbar überlappt GCN die Ausführung mehrerer Kernel, so daß die implizite Synchronisation beim Aufruf nicht mehr funktioniert; ist aber nur eine Vermutung). Ich habe keine Ahnung, ob man das überhaupt auf die Schnelle in der IL-Version beheben könnte oder ob man da keinen ausreichenden Einfluß hat bzw. da etwas mehr umschreiben müßte. Kurz, eine Lösung auf dem Weg wäre vielleicht die performanteste (auch weil da noch mehr kleinteilige Optimierungen gegenüber einer C-ähnlichen Version drin sind, die wohl auch nochmal 15-20% bringen), ist aber vermutlich eher unwahrscheinlich.
Alternativ könnte man die OpenCL-Version etwas aufbohren und die alte Version für die GCN-GPUs sperren. Ich denke, man könnte bestimmt so 10-15% mehr Speed aus der OpenCL-Version rausholen. Slicker benutzt sehr wahrscheinlich nicht die cl_amd_media Erweiterung von OpenCL. Die stellt ein paar zusätzliche Befehle zur Bitmanipulation zur Verfügung (einer davon ist für Collatz ganz nützlich und war für ~2/3 des Geschwindigkeitsvorsprungs der Evergreens vor der HD4000er-Serie mit der alten Version verantwortlich).
Ich muß erstmal sehen, daß ich bei mir zu Hause die ganzen Entwicklungsumgebungen und SDKs wieder installiere. Dann kann ich Slicker mal nach dem aktuellen OpenCL-Quelltext fragen und schauen, was man da machen kann. Aber das ist sicher keine Lösung für morgen, das wird wohl mindestens eine Woche dauern.
Tut mir leid.
==================
Daß auch GCNs öfter mal WUs validiert bekommen, liegt übrigens daran, daß der Validator nur die Maximalschritte und die entsprechende Zahl vergleicht, nicht aber die Gesamtzahl der Schritte für die komplette WU. Wie oben gesagt, rechnet GCN im Prinzip schon richtig, nur der sogenannte "reduction kernel", der die Zwischenergebnisse (die in einem 256 bis 512MB großen Textur-Array liegen) zusammenrechnet arbeitet vermutlich nicht korrekt (wegen der oben erwähnten Kohärenzgeschichte). Trotzdem kommt es mit einer gewissen Wahrscheinlichkeit vor, daß die richtige Zahl (dann auch mit der richtigen Schrittanzahl, wie gesagt ist die eigentliche Berechnung bei GCN im Prinzip vermutlich schon richtig) dabei rauskommt. Nur die Gesamtschrittanzahl für die WU ist praktisch immer falsch und unterscheidet sich auch zwischen verschiedenen GCN-GPUs, es ist also mehr oder weniger zufällig, weswegen ich auf die Kohärenzgeschichte tippen würde.
PS:
Das bedeutet übrigens, daß die GCN-GPUs wahrscheinlich wirklich so schnell sind, wie es den Anschein hat, man müßte nur die Ergebnisse korrekt hinbekommen (GCN spart also keine Schritte ein, nur das Zusammenrechnen funktioniert nicht richtig). Der Grund dafür ist die relativ geringe Auslastung, die Collatz auf den VLIW-GPUs schafft. Auf der R600-Generation waren das irgendwas (aus dem Gedächtnis, also nur grobe Richtlinie) bei 2,2/5 Slots über ~2,7/5 bei der R700-Generation (full speed Bithifts) und den Evergreens/VLIW5-NIs (die sparen aber ein paar Bitshifts wegen Nutzung der bitalign-Instruktion, benötigen also weniger Befehle und sind deswegen schneller). Cayman/Trinity ist nicht ganz vergleichbar, weil Integer-Multiplikationen 4 Slots statt nur einem belegen, so daß die Belegung von 2,8/4 Slots pro Takt und Einheit etwas langsamer als bei den Evergreens ist. Aber genau das ist im Prinzip die Vergleichsbasis zu Tahiti (Integer-Multiplikationen sind dort auch nur 1/4 des Speeds). Nur hat man dort keine Probleme mehr mit der VLIW-Befüllung. Treten keine anderweitigen Limits (Speicher) auf, sollte der Speed einer HD7970 im Optimalfall
32/24 * 925/880 * 4/2,8 = 2,0 (CUs, MHz, Füllgrad)
Also grob das Doppelte einer HD6970 betragen.
Edit:
GCN ist übrigens potentiell effizienter, wenn es um Integer-Additionen mit >32Bit Länge (wie auch bei Collatz, die rechnen mit 192Bit Integern) geht. Da kann also noch ein zusätzlicher Speedup herkommen (man spart bis zur Hälfte der Additionsbefehle, wenn der Compiler das richtig gebacken bekommt, weil es einen Add-Carry-Befehl mit 3 Source-Operanden gibt [und jeder Add-Befehl automatisch die Carry-Flags erzeugt und wahlweise auch in 2 Skalarregister rausschreibt, bei den VLIW-Architekturen war hierzu ein zusätzlicher Befehl nötig]). Man ist also richtig flexibel.
v_add v0, s[0:1], v1, v2 // v0 = v1 + v2, Übertrag (64 carry flags, also für jedes Element der Wavefront 1 Bit) in Skalarregister s0 und s1 (vcc wäre auch möglich)
v_addc v3, vcc, v4, v5, s[0:1] // v3 = v4 + v5 + Übertrag (aus den 2 Skalarregistern), neuer Übertrag in vcc (vector condition code, ein spezielles Skalarregister)
v_addc v6, vcc, v7, v8, vcc // v6 = v7 + v8 + Übertrag (diesmal aus vcc), neuer Übertrag wieder in vcc
v_add v0, s[0:1], v1, v2 // v0 = v1 + v2, Übertrag (64 carry flags, also für jedes Element der Wavefront 1 Bit) in Skalarregister s0 und s1 (vcc wäre auch möglich)
v_addc v3, vcc, v4, v5, s[0:1] // v3 = v4 + v5 + Übertrag (aus den 2 Skalarregistern), neuer Übertrag in vcc (vector condition code, ein spezielles Skalarregister)
v_addc v6, vcc, v7, v8, vcc // v6 = v7 + v8 + Übertrag (diesmal aus vcc), neuer Übertrag wieder in vcc
Zuletzt bearbeitet:
MrBad
Grand Admiral Special
Ich versteh zwar kein Wort aber trotzdem Danke Gipsel. 
@t: Meine 4850 läuft übrigens nach etwas Zickerei jetzt doch mit BM 6.10.58 und Catalyst 11.9
Bisher siehts gut aus, werd dann später wieder Rosetta und WCG zulassen.
@t: Meine 4850 läuft übrigens nach etwas Zickerei jetzt doch mit BM 6.10.58 und Catalyst 11.9
Bisher siehts gut aus, werd dann später wieder Rosetta und WCG zulassen.
Und hast du dir richtige Einstellung gemacht eine HD6970 sind zb. "S1 T7 L8 N22" die richtigen Parameter, für eine Llano 3410MX jedoch sind "S1 T7 L8 N18" weniger CPU belastend (app_info Werte welche drinn ist sind Optimal), 0.2% CPU last vs 100% CPU last, sonnst gleich! Am bseten mal in die Readme datei schaue, welche im Zip ist und mal ein paar Testfall durchlaufen lassen.
Werde nachher mal schauen den werten nach sollte die APP eigentlich, wenn die Werte des Testfall auf die WU übertragbar sind weit weniger Zeit benötigen als die Standart app (2.09), mal schaunen, lasse man meine WU auslaufen. bevor ich die opencl app ausprobieren auf dem Llano.
Werde nachher mal schauen den werten nach sollte die APP eigentlich, wenn die Werte des Testfall auf die WU übertragbar sind weit weniger Zeit benötigen als die Standart app (2.09), mal schaunen, lasse man meine WU auslaufen. bevor ich die opencl app ausprobieren auf dem Llano.
Zuletzt bearbeitet:
gruenmuckel
Grand Admiral Special
Ich wollte nur mal zum Vergleich anmerken, das meine HD5850 mit Catalyst 12.4 problemlos läuft.
Ebenso meine HD4850 mit Catalyst 11.9
Beide unter Windows 7 64bit.
Diese Treiber sollten also für diese Karten unproblematisch sein.
Bei der HD4850 bin ich übrigens auf 0:53:42 runter mit 780/1030mhz.
Zeiten der HD4850 editiert.
Ebenso meine HD4850 mit Catalyst 11.9
Beide unter Windows 7 64bit.
Diese Treiber sollten also für diese Karten unproblematisch sein.
Bei der HD4850 bin ich übrigens auf 0:53:42 runter mit 780/1030mhz.
Zeiten der HD4850 editiert.
Zuletzt bearbeitet:
tspoon
Grand Admiral Special
Es lohnt nicht wirklich nur auf große WUs zu gehen. Gestern hat ich noch Mischmasch aus groß und klein und eine deutlich höhere Steigerung der Credits als heute. Wo ich nur große WUs berechnet habe.
Ab ca.18 Uhr werden nur noch kleine WUs zum Vergleich kommen. Durch Kunfumeister der Langsamkeit Peng werden wir dann nen Vergleich haben.
Ab ca.18 Uhr werden nur noch kleine WUs zum Vergleich kommen. Durch Kunfumeister der Langsamkeit Peng werden wir dann nen Vergleich haben.
Zuletzt bearbeitet:
Kater Sylvester
Grand Admiral Special
Pending steigend 2.886.750 credit
Emploi
Grand Admiral Special
Könnte es eigentlich Probleme geben, wenn man mit einer schellen Karte nur die Minis rechnet, achtet mal bitte drauf. "Max tasks per day 134" sind für meine 5870 zu wenig... Nicht das uns das den Kopf kostet, ich weiße mal die langen über Nacht besser wieder an.
Onkel_Dithmeyer
Redaktion
☆☆☆☆☆☆
Was willste mit der GPU denn sonst anfangen?
Emploi
Grand Admiral Special
Ebend, hier gibt es nur eine Strategie: GPU. Mehr....!:
Zuletzt bearbeitet:
gruenmuckel
Grand Admiral Special
800mhz ist respektabel für eine HD4850, oder? Kommt auch nicht über 64°C.
Ähnliche Themen
