Unser Einsatz bei MilkyWay

[Emploi]

Ich wollts komplizierter Ausdrücken, aber:

technischer fortschritt:

wenn ich mit einem Moped ( SingleCores ) unterwegs bin
dann darf ich mich nicht wundern das ich von einem Sportwagen ( Quad ) überholt werde

Oder von einem Thrust SuperSonic (Grafikkarte, meine klingt auch so unter Last ) überholt...

PS: Den fährt man nur in der Wüste, was soll dieser komische geblitzt Vergleich... *rolleyes*

 

[Gipsel]

Da ich jetzt ja sowieso öfter mit Travis wegen der GPU-App kommuniziere, habe ich das Thema in der letzten PM nochmal angesprochen, diesmal auch mit ein paar der Zahlen aus meinem vorherigen Post hier im Thread. Der Aufhänger war seine Frage, warum denn bisher nur so wenige mit der GPU-App gerechnete Resultate bei ihm ankommen
Der relevante Teil meiner Antwort:

Furthermore it is simply not attractive to run at the moment, as the credits are abysmal and you won't get more than 300 WUs per core and day (which equates to less than one hour of work for a HD4870). Even with a quadcore (1200 WUs a day limit) you get only about 330 credits a day for this. You have to be really enthusiastic to run it in the current state.
That actually needs to change if the app becomes ready for widespread use. So you have to lift/raise the creditlimit and the WU limit and drop the credit per WU even further than you have already done to keep the balance as I explained already. You can compensate that partly by just using a better compiler for your builds, but you know that, too. I started to implement some kind of flops counting to the GPU app. So in the long term it could be possible to calibrate to SETI just by using the same multiplier for the actual executed floating point operations. Last time I checked that multiplier was 2.77 credits/TFlop. If I didn't made a mistake, the WUs with one stream require about 1.25 TFlop (depending a bit on the cuts). It is hard to count it in the C source as there are function calls like sqrt or exp, so I have done it in the assembly for the GPU. But that should be quite exact (have no idea how SETI counts).
That would result in about 3.5 credits per WU, which would be definitely too low with the current stock app (maybe bearable with the fastest optimized app) on CPUs, but looks quite good for the GPU (if the WU limit is raised considerably). I don't suggest that you implement it that way, but it shows the general direction. I guess the conclusion should be that there is something to do on a lot of fronts.

 

[Sixpack44]

Da bin ich dann mal auf die Antwort gespannt. Ich vermute mal...fällt das WU pro Tag Limit, läuft die Graka App ohne Probleme, wird sich AMD/ATI über einen kleinen Run auf die 48er Karten freuen.

Übrigens Gipsel.....Ganz grosses Kino von Dir... Daumen hoch. Wollte ich schon ne Weile gesagt haben.

 

[Emploi]

... Der Aufhänger war seine Frage, warum denn bisher nur so wenige mit der GPU-App gerechnete Resultate bei ihm ankommen ....

Weil ich hier sonst nen Hörschaden bekomme, die Nachbarn stört es zwar noch nicht, aber die 4870 macht imho odentlich Lärm unter Last...

BTW: Die 300 WUs wären in ner knappen 1/2+0.5% Stunde durch

 

[Sabroe SMC]

Da bin ich dann mal auf die Antwort gespannt. Ich vermute mal...fällt das WU pro Tag Limit, läuft die Graka App ohne Probleme, wird sich AMD/ATI über einen kleinen Run auf die 48er Karten freuen.

Übrigens Gipsel.....Ganz grosses Kino von Dir... Daumen hoch. Wollte ich schon ne Weile gesagt haben.

Definitiv

 

[Gipsel]

Um noch mal zu meinem Posting zurückzukommen:

Bei SETI war der Umrechnungsfaktor meiner letzten dort gerechneten WU angeblich (keine Ahnung wie die genau zählen) 2.77 credits/TFlop.
[..]
Unabhängig vom Problem [..] wie man mit Operationen lediglich einfacher Genauigkeit umgeht (GPUGrid) kann man einfach mal versuchen, diesen Umrechnungsfaktor auf Milkyway anzuwenden. Für die GPU-App habe ich die Fließkommaoperationen abgezählt und kann so einfach sagen, was dabei herauskommt.
Die WUs mit einem Stream benötigen etwa 1,25 TFlop (genauer Wert variiert etwas je nach WU). Dies würde also 3,46 credits/WU rechtfertigen (statt ~26.89 wie jetzt).

Ich habe mich gewundert, wieviele GraKas bei SETI von der CUDA-App unterstützt werden (alles unter den GTX kann ja nur single precision) und habe mal ganz kurz in den Code da geschaut. Und was mußte ich feststellen, SETI rechnet sogar auf CPUs eigentlich nur mit single precision. Bei der Gelegenheit habe ich auch noch einen Kommentar im Code gefunden, daß bei SETI nicht nur Rechenoperationen, sondern auch Loads und Stores als Fließkommaoperationen gezählt werden.

Insofern ist das etwas schwierig, den gleichen Umrechnungsfaktor von 2,77 credits/TFlop anzusetzen, da MW (genau wie z.B. Einstein) double precision benutzt. Man sollte demzufolge MW fairerweise etwas mehr zugestehen (aber wahrscheinlich etwas weniger, als einfach das Doppelte von 5,54 credits/DP-TFlop, da SETI ungleich komplexer ist und es dort schwieriger ist, die CPUs mit der gleichen Effizienz auszunutzen).

Daraus ergibt sich übrigens auch, daß eine GTX 280 mit der CUDA-SETI-Applikation (die aber auch viel komplizierter und aufwendiger ist) deutlich weniger single-precision-Durchsatz macht, als eine HD4870 (oder auch 4850) bei Milkyway in double precision schafft
Ich will gar nicht daran denken, was dabei rauskommen würde, wenn MW single precision nutzen würde Aber für so blindes Number Crunching wie bei MW sind die GraKas eben auch gebaut. Wenn es MW nicht schon geben würde, müßte man es als Demonstrationsprojekt für GraKas geradezu erfinden.

Insgesamt zeigt das, daß die gerechte Creditvergabe in Zukunft wohl noch schwieriger wird.

 

[Bikeman]

da MW (genau wie z.B. Einstein) double precision benutzt.

Kleine Korrektur: Einstein@Home benutzt zu einem sehr wesentlichen Anteil single precision Berechnungen, ansonsten hätte die SSE - Optimierung ja auch nichts gebracht (SSE unterstützt nur single precision Vektor-Operationen). Bei Einstein@Home laufen Entwicklungen in Richtung CUDA, aber das dauert vermutllich noch etwas zur "Serienreife".
CU
Bikeman

 

[Sabroe SMC]

Kleine Korrektur: Einstein@Home benutzt zu einem sehr wesentlichen Anteil single precision Berechnungen, ansonsten hätte die SSE - Optimierung ja auch nichts gebracht (SSE unterstützt nur single precision Vektor-Operationen). Bei Einstein@Home laufen Entwicklungen in Richtung CUDA, aber das dauert vermutllich noch etwas zur "Serienreife".
CU
Bikeman

Lasst da mal den GIPSEL ran! Vielleicht hilft Euch der entscheidend weiter?

 

[Bikeman]

Lasst da mal den GIPSEL ran! Vielleicht hilft Euch der entscheidend weiter?

Warum nicht... in der Vergangenheit haben sich die Projektverantwortlichen von E@H immer sehr offen für Beiträge von Freiwilligen gezeigt (solange diese MIT und nicht GEGEN die offiziellen Programmierer arbeiten). Was ich hier an Kommentaren in Bezug auf MW lese (ich meine jetzt nicht Gipsel!!) hört sich oft so an an wie "hey, die offiziellen Programmierer sind doch alles Idioten, das können Freiwillige besser". Das ist mal keine Grundlage für eine vertrauensvolle Zusammenarbeit von Freiwilligen und offiziellen Programmierern, IMHO. Aber ich will jetzt nicht off-topic werden. Wenn sich jemand wirklich ernsthaft daran interessiert, an einer CUDA Implementierung für E@H mitzuarbeiten, kann ich ihm/ihr nur nahelegen sich bei Bernd Machenschalk im E@H Forum zu melden um die Möglichkeiten einer Zusammenarnbeit zu bekaspern.

CU
Bikeman

 

[erde-m]

...Was ich hier an Kommentaren in Bezug auf MW lese (ich meine jetzt nicht Gipsel!!) hört sich oft so an an wie "hey, die offiziellen Programmierer sind doch alles Idioten, das können Freiwillige besser". Das ist mal keine Grundlage für eine vertrauensvolle Zusammenarbeit von Freiwilligen und offiziellen Programmierern, IMHO. ...
CU
Bikeman

Das liegt aber eher daran, das die Hilfeangebote der Freiwilligen von den Projektverantwortlichen abgekanzelt wurden und deren Code alles andere als optimal ist. Das hat sich erst gebessert, als Gipsel und Twodee das Gegenteil bewiesen haben....Trotzdem ist die Gesamtsituation mehr als unbefriedigend geblieben...

 

[Nightshift]

@ Bikeman:

Da stimme ich dem von erde-m Gesagten im wesentlichen zu wobei die Debatte hier und da etwas emotional wird. Aber bei einer gezielten Zusammenarbeit kann es eigentlich nicht so weit kommen wie in diesem Fall. Da sind ja schon die Rahmenbedingungen ganz andere.

 

[erde-m]

@ Bikeman:

Da stimme ich dem von erde-m Gesagten im wesentlichen zu wobei die Debatte hier und da etwas emotional wird. Aber bei einer gezielten Zusammenarbeit kann es eigentlich nicht so weit kommen wie in diesem Fall. Da sind ja schon die Rahmenbedingungen ganz andere.

Bei Einstein und auch anderen Projekten ist die Zusammenarbeit mit den Projektbetreibern auf einer ganz anderen Ebene möglich. Da kann richtig was bei rum kommen...

MW ist eine ganz andere Geschichte - besondere Umstände eben. Bei Spin gibt es ja auch einige Hindernisse und trotzdem nicht so ein Gezänk wie bei MW.

 

[heavy-Ions@boinc]

Bei Spin gibt es ja auch einige Hindernisse und trotzdem nicht so ein Gezänk wie bei MW.

aber nur weil die closed source apps haben
stell dir mal die schlechte linux-app von Spin in den händen von 2D, Gipsel oder crunch3r vor
ich wette statt 1h crunch-time kämen die auf unter 20min pro wu

 

[Gipsel]

Lasst da mal den GIPSEL ran! Vielleicht hilft Euch der entscheidend weiter?

Also mal ein bißchen langsam.
Schon der GPU-Kram bei Milkyway kostet mich mehr Zeit, als ich eigenlich verantworten kann. Und das ist ein ziemlich einfach zu überschauendes Projekt. Ich glaube allein der Quellcode von einem Projekt wie Einstein oder auch SETI ist locker den Faktor 10 bis 30 umfangreicher.
Ich möchte nicht wissen, wieviele Mannjahre schon in die CUDA-App von SETI geflossen sind. Nachdem was man so hört, sind da eine ganze Menge von nvidia Software-Entwicklern mit beschäftigt (ist eben ein Prestige-Projekt). Die kennen ihre Hardware und machen den ganzen Tag nichts anderes.
Ich bin alleine, habe bevor das mit MW losging für ein paar Jahre kein bißchen programmiert, schon gar nichts in der Richtung GPGPU, muß den ganzen Tag lang an meiner Doktorarbeit schreiben (Experimentalphysik, also auch nichts was in die Richtung geht) and bastel spätabends bzw. nachts ein bißchen dran rum. Dazu kommt, daß double precision mit ATI wirklich kein Zuckerschlecken ist, da man doch für einige Sachen auf die Assembler-Ebene gehen muß. Da kann man nur hoffen, daß das mit der Stream-SDK 1.4 oder dann OpenCL besser wird.

 

[Bikeman]

Also mal ein bißchen langsam.
Schon der GPU-Kram bei Milkyway kostet mich mehr Zeit, als ich eigenlich verantworten kann. Und das ist ein ziemlich einfach zu überschauendes Projekt. Ich glaube allein der Quellcode von einem Projekt wie Einstein oder auch SETI ist locker den Faktor 10 bis 30 umfangreicher.

Was Einstein@Home betrifft: Wenn man alle benutzten Bibliotheken hinzunimmt ist der Source Code wirklich umfangreich, aber die wirklich geschwindigkeitsrelevanten Teile sind eigentlich recht übersichtlich. Wer will kann sich ja selbst ein Bild machen, ist ja alles Open Source unter GPL.

CU
Bikeman

 

[Nightshift]

Um nochmal auf die Thematik zurück zu kommen:

Wirklich getan hat sich ja nichts.

Im Gegenteil, man schaue sich einmal an wieviele Credits die Teams rausblasen bei Milkyway, vor allem bei SUSA und den Francophonen scheint es da in Hinblick auf den Kampf um Platz 1 Combined keine Zurückhaltung zu geben.

Und selbst andere Teams aus denen es zuerst noch reichlich Kritik bezüglich der verbesserten Apps gab haben mittlerweile einen deutlich höheren Output als P3D.
Denke nicht, dass da eine Planung in Hinblick auf gemeinsame Aktionen auch nur im Ansatz Erfolg hätte.

Es wäre also wirklich dringend nötig seitens der Projektbetreiber die Credits deutlich zu kürzen.
Je mehr bei dem Projekt mitmachen desto stärker wirkt sich die inflationäre Creditvergabe aus.

 

[heavy-Ions@boinc]

die credits wurden ja nun runtergesetzt. jetzt hat mw zwar immer noch die credit/stunde krone auf, aber wenigstens ist es lange nicht mehr so schlimm wie noch vor ein paar wochen.
also fast im grünen bereich meiner meinung nach.

 

[SR530]

also fast im grünen bereich meiner meinung nach.

Der Begriff "fast" ist sehr dehnbar. Was ist daran richtig, wenn ich mit meinen paar Kernen das dreifache mache wie bei POEM?

 

[Ole]

Milkyway gehört auf die Ignoreliste ganz einfach.

Nur weil andere Teams da meinen machen zu müssen...

Wenn Susa in den Bach springt, springst Du mit?

 

[Terminatrix]

Weiss gar nicht wieso da immer noch so viele crunchen.
Scheint den meisten ja doch wohl nur um die Credits zu gehen.

 

[Crashtest]

nee - man muss doch Gipsel danken indem man seine Apps nutzt !

 

[Twodee]

nee - man muss doch Gipsel danken indem man seine Apps nutzt !

oder man nutzt seine eigene

 

[Ole]

Also sorry, danke sagen, indem ich die Apps nutze?

Für mich klingt das wirklich ziemlich schal ...und sehr nach Ausrede.

 

[[MTB]JackTheRipper]

Bei MW sind sie doch gerade am ausbalancieren der Credits.
Mittlerweile seh ich es wieder als rechenbar an. Gebt ihnen noch nen Monat, oder spätestens bis der Cuda Client kommt, dann wird die Sache schon ganz anders aussehen.

 

[Crashtest]

Also sorry, danke sagen, indem ich die Apps nutze?

Für mich klingt das wirklich ziemlich schal ...und sehr nach Ausrede.

wenn keiner die App nutzen würde (insb. ATI) - wärste nich so "berühmt"

es verwenden sehr viele bei MW die "Gipsel-App" (evtl. mehr als de Projekt-App)