Optimierte MilkyWay@home Applikation

[heavy-Ions@boinc]

LOL ... guckt mal dort --> http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=551



Jetzt seit ihr die bösen
Hört sich für mich so an, als ob Travis euch unterstellen würde, das ihr die winderpause ausgenutzt habt, um zu cheaten...

Der typ hat echt einen an der waffel ....

Der Böse zu sein ist doch auch nett
Ist es denn so das berechnungen über SSEx instruktionen ungenauer sind als über x87 operationen? oder eher umgekehrt?
.
EDIT :
.

heavy-Ions@boinc war schneller

aber nur knapp

 

[Crunch3r]

Der Böse zu sein ist doch auch nett

Naja, ist halt mal jemand anders dran

EDIT... was ganz witzig ist, ist das die ergebnisse von platform zu platform, AMD vs. Intel, sowieso unterschiedlich sind... das hat der gute traver aber nicht kapiert.
z.B. wird im 64 bit mode fp code auf mit SSE2 gerechnet ....

Selbst zwischen linux und windows ist es ein unterschied... per default ist die prescision für die FPU in linux auf 80 bit gesetzt und in windows auf 64 bit...

 

[gruenmuckel]

Mich wundert das deren Server schon so lange durchhalten. Haben die neuerdings jemand kompetenten im Team?

 

[heavy-Ions@boinc]

Naja, ist halt mal jemand anders dran

8)
frag mich warum die das nicht früher erkannt haben
es gab ja schon opt. apps die denen beim validieren aufgefallen sind.....

 

[gruenmuckel]

8)
frag mich warum die das nicht früher erkannt haben
es gab ja schon opt. apps die denen beim validieren aufgefallen sind.....

Vielleicht rechnet der Validator ungenau?

 

[Crunch3r]

Vielleicht rechnet der Validator ungenau?

Das würde mich nicht wundern

Was witzig ist, das dieser "vergleich" von einem typen aus dem polnischen team kommt...
Die haben ja selber eine optimierte version(nur nicht so schnell)... Ein Schelm, wer böses dabei denkt

 

[[MTB]JackTheRipper]

Soweit ich weiß haben Gipsel und 2D ihre Versionen vorab mit den selben WUs geprüft...

Wird wohl doch auf einen Boykott rauslaufen müssen *g*

 

[heavy-Ions@boinc]

Das würde mich nicht wundern

Was witzig ist, das dieser "vergleich" von einem typen aus dem polnischen team kommt...
Die haben ja selber eine optimierte version(nur nicht so schnell)... Ein Schelm, wer böses dabei denkt

LOL. wußte ich noch gar nicht
mich würde mal interesseiren ob die ein und dieselbe WU auf unterschiedlichen rechnern immer das gleiche ergebniss mit der standard app abwirft. Da die x87 einheiten ja von cpu zu cpu sich wohl unterscheiden......

 

[[MTB]JackTheRipper]

Eine zu ungenau rechnende Standardapp wäre natürlich richtig nett

 

[Crunch3r]

Wird wohl doch auf einen Boykott rauslaufen müssen *g*

LOL

Da gibt's ja schon spezialisten für, vielleicht sollte man dann die profi boycotteure mal befragen wie man das dann am besten anstellt

News

Incorrect Applications
January 15, 2009
Part of the assimilator update allows us to track users that repeatedly return invalid results and stop awarding credit to them. If you're using a non-stock app you might want to make sure it's returning the correct results, or you might stop getting credit from it.

Naja... werden wir ja dann bald sehen ob es noch credits gibt oder nicht...

 

[gruenmuckel]

LOL

Da gibt's ja schon spezialisten für, vielleicht sollte man dann die profi boycotteure mal befragen wie man das dann am besten anstellt



Naja... werden wir ja dann bald sehen ob es noch credits gibt oder nicht...

ALso ich bekomme Credits und zwar mit dem hier mal geposteten MW 1.8 Archiv, und zwar die SSE3-Apps auf Athlon 64 San DIego und Core 2 Duo E6300.

 

[heavy-Ions@boinc]

ALso ich bekomme Credits und zwar mit dem hier mal geposteten MW 1.8 Archiv, und zwar die SSE3-Apps auf Athlon 64 San DIego und Core 2 Duo E6300.

wahrscheinlich kann der validator gar nicht unterschieden ob die dinger richtig gerechnet sind oder nicht
Wenn sie "aussortieren" dann wahrscheinlich über die benötigte rechnezeit pro WU

 

[Crunch3r]

Eine zu ungenau rechnende Standardapp wäre natürlich richtig nett

Die rechnet doch schon ungenau seit dem hier:

December 3, 2008
[B^S] Astral Walker kindly suggested an code optimization which seems to be getting about a 10% speedup. I've updated the application again to v0.7 (at least the linux and osx binaries). Windows should be on its way when Dave gets it on the server. I've updated the code release directory as well.

Da hat wohl der travis selber nicht getestet

 

[[MTB]JackTheRipper]

wahrscheinlich kann der validator gar nicht unterschieden ob die dinger richtig gerechnet sind oder nicht
Wenn sie "aussortieren" dann wahrscheinlich über die benötigte rechnezeit pro WU

Wie soll er's auch überprüfen? Dazu müsste ja das Ergebnis von ihm korrekt gegengerechnet werden.

 

[Caipi]

wahrscheinlich kann der validator gar nicht unterschieden ob die dinger richtig gerechnet sind oder nicht
Wenn sie "aussortieren" dann wahrscheinlich über die benötigte rechnezeit pro WU

Moin

die werden mit der Hand nachrechnen

 

[heavy-Ions@boinc]

Moin

die werden mit der Hand nachrechnen

dann ist es ja wenigsten genau genug

 

[Crunch3r]

dann ist es ja wenigsten genau genug

so etwa ?

 

[Twodee]

Die rechnet doch schon ungenau seit dem hier:



Da hat wohl der travis selber nicht getestet

diesen pseudo speedup (von version 0.6 auf 0.7) durch genauigkeitsverlust hab ich garnicht übernommen, das lief bei mir schon immer über SSE(x).

 

[Gipsel]

diesen pseudo speedup (von version 0.6 auf 0.7) durch genauigkeitsverlust hab ich garnicht übernommen, das lief bei mir schon immer über SSE(x).

Da liege ich einmal krank im Bett und schon passiert sowas!
Da kann ich mich ja wohl glücklich schätzen, daß wohl die meisten mit Twodees Version unterwegs sind

Aber wo das gerade hier angesprochen wurde. Was war denn das eigentlich für eine Änderung von diesem Astral Walker, welche die Ergebnisse mit der Standardapp geändert hat? Könnte mich da mal einer aufklären und auf die Codestelle hinweisen? Die Änderung war ja schon drin, bevor ich mir das angesehen habe, ich war ja diesmal sozusagen Späteinsteiger.
Das macht doch aber bestimmt nicht soviel aus, wie im MW-Forum gepostet. Da fällt auch auf, daß alle optimierte Versionen auf einem Rechner wirklich identische Ergebnisse abliefern, nur eben andere als die Original-App.
Daß das zwischen verschiedenen Rechnertypen Unterschiedlich ist, weiß ich ja. Insbesondere sowas wie die (für MW recht wichtige) exp-Funktion ist ja sehr empfindlich auf ein bißchen Rauschen in den letzten Bits (das Rauschen potenziert sich sozusagen auch). Und gerade hier habe ich schon böse Sachen über die Implemention in den Bibliotheken (ist ja nicht in Hardware gegossen) auf einigen Plattformen gehört. Denke aber mal nicht, daß da Intel geschlampt hat.

Übrigens sollte man mit dem Original auch auf keinen Fall erwarten, daß nach einem Resume von einem Checkpoint genau das Gleiche rauskommt wie ohne Unterbrechung. Dazu werden da nämlich zuwenig Stellen der Zwischenergebnisse abgelegt, nur mal so am Rande. Hilft ja nichts, das Endergebnis mit 15 Nachkommastellen auszugeben, in die Checkpointfiles aber nur 6 zu schreiben

Aber hilft ja alles nichts. Weißt Du woran es liegt Twodee?

Edit:
Übrigens, für alle die es interessiert habe ich mal hier die Ergebnisse der offiziellen Test-WU:
Originalversion: fitness: -3.046272445362277
Meine Version: fitness: -3.046272445362275

Also auch nicht bis auf das allerletzte Bit identisch, aber solche Unterschiede treten nunmal auf und sind für das bei MW eingesetzte Optimierungsverfahren auch total unerheblich. Es ist übrigens gar nicht so unwahrscheinlich, daß meine sogar näher am "richtigen" Ergebnis dran sind.

Also für alle Wagemutigen gibt es hier eine SSE3-Version. Die sollte ja am beliebtesten sein. Ist übrigens nicht die allerschnellste. Habe sicherheitshalber ein paar Compilerswitches entschärft, obwohl die eigentlich nichts am Output der Test-WU geändert haben. Aber wer weiß.

Edit2:
Soll ich dann eigentlich nochmal den kompletten Satz von mir verlinken? Die alten Links sind ja wohl schon tot.
Oder warten wir lieber, bis sich der Staub ein wenig gelegt hat?

 

[KIDH]

Hilft ja nichts, das Endergebnis mit 15 Nachkommastellen auszugeben, in die Checkpointfiles aber nur 6 zu schreiben

Das ist dann aber echt nen Armutszeugnis...wenn ich mich dran erinnere, wie oft uns unser Phy-Prof mit signifikanten Stellen zugekekst hat.

 

[Gipsel]

Das ist dann aber echt nen Armutszeugnis...wenn ich mich dran erinnere, wie oft uns unser Phy-Prof mit signifikanten Stellen zugekekst hat.

Das sind ja noch nicht mal signifikante Stellen, sondern einfach fixe 6 Nachkommastellen. Zur Illustration mal ein Ausschnitt aus einem Original-Checkpoint-File:

background_integral: 0.000603
stream_integrals[1]: 41.480854

oder

background integral: 0.000002
stream_integrals[1]: 0.219593

Bei mir sieht das übrigen so aus:

background_integral: 0.0006027868947414175
stream_integrals[1]: 41.48085376171016

oder

background integral: 2.350910513914358e-006
stream_integrals[1]: 0.2195925551916911

 

[KIDH]

Das sind ja noch nicht mal signifikante Stellen, sondern einfach fixe 6 Nachkommastellen.

Daraus nehme ich, daß beim Rumschieben und Miteinanderverechnen noch nichtmal auf Signifikanz geachtet wird? Das wär ja dann noch der blanke Hohn für ne Phy-App.

Ah...jetzt seh ichs...das ist ja wirklich böse, die rechnen die Stellenzahl nicht ab der ersten Ziffer =/ 0 sondern ab dem Komma...das ist wirklich toll!

Gruß
KIDH

 

[Gipsel]

Daraus nehme ich, daß beim Rumschieben und Miteinanderverechnen noch nichtmal auf Signifikanz geachtet wird? Das wär ja dann noch der blanke Hohn für ne Phy-App.

Ah...jetzt seh ichs...das ist ja wirklich böse, die rechnen die Stellenzahl nicht ab der ersten Ziffer =/ 0 sondern ab dem Komma...das ist wirklich toll!

Gruß
KIDH

Zumindest wenn die Rechnung von einem Checkpoint fortgesetzt wird, geht da so ein wenig verloren. Wird die Rechnung nicht unterbrochen, läuft das schon mit den vollständigen Werten weiter.

Was die Anzahl der echten signifikanten Stellen angeht, müßte man mal den Algo ein wenig analysieren. Allerdings ist es schon so, daß die Ausgabe des Endergebnisses (diese fitness) mit 15 Nachkommastellen (was meist 16 signifikante Stellen bedeutet) eine Genauigkeit vortäuscht, die nicht vorhanden ist. Also ich würde drauf tippen, daß mindestens die letzten 4 Stellen oder so schlicht und einfach numerisches Rauschen sind. Die ganzen exp bei MW sind ja recht empfindlich auf sowas.

 

[KIDH]

Jap, das war mir klar @Checkpoint. Aber das ist ja schonmal ein Fakt der generell unterschiedliche Ergebnisse bedeutet, falls es zu einem Checkpoint kommt oder schlimmer: zu mehreren. Bei der WU-Länger ist das vll nicht so kritisch...aber trotzdem einfach schlampig....naja da hilft dann wohl die übertriebene Genauigkeit etwas aus das zu korrigieren...da bekommt man ja selbst als Physik- und Programmier-Idiot die Krise.

 

[Gipsel]

Übrigens hat Travis die auch schon oben verlinkte SSE3-Version abgesegnet.
Bzw. hat er erklärt, daß so kleine Abweichungen unkritisch sind (die ja auch mit der Stock-App zwischen verschiedenen Architekturen auftreten).