Optimierte MilkyWay@home Applikation

[Crashtest]

Frage zu MW & ATI CAL:

irgendwo stand, dass jemand eine CAL optim. MW-App bastelt:

ich würd auch mit testen & debuggn;
mein Testsystem : a3200, 2GB-Ram, ati-4650

 

[DerRob]

EDIT: Habe mal versucht herauszulesen wo und wie z.Z. das creditlimit von Milkyway liegt und weiss es eff immer noch nicht. Zuletzt bei 2,5k pro Kern & Core also kannst du m.M nach die schnellste App nehmen. Der 330 müsste immer noch unter dem Limit liegen bei aktivierten HT.

das limit liegt bei etwa 2,6k pro kern und tag (0,03 credits pro sec), und ab ca. 1200 sec pro WU erreicht man das. ein schnelleres berechnen der WUs bringt also im hinblick auf die credit-"ausbeute" nichts mehr

 

[TAL9000]

das limit liegt bei etwa 2,6k pro kern und tag (0,03 credits pro sec), und ab ca. 1200 sec pro WU erreicht man das. ein schnelleres berechnen der WUs bringt also im hinblick auf die credit-"ausbeute" nichts mehr

Na das schafft der 1,6GHz Atom mit HT nicht, also kann dort die schnellste App verwendet werden.

TAL9000

 

[Gipsel]

auf meinem Intel Dual 3,0GHz WIN XP home

läuft nur die opt vers. SSE2 ( ~ 15 min. je wu )

wenn ich die opt vers. SSE3 einsetze werden die wus mit
berechnungsfehler abgebrochen

warum

Meinst Du meine Versionen? Die sind zwar unter XP64 kompiliert, aber die laufen bei mir auch unter XP32 (auf einem X2 getestet). Wirklich BOINC beendet gewesen beim Kopieren der .exe und der app_info.xml?

Außerdem sind 15 Minuten für 3GHz aber auch ein wenig langsam, oder ist das ein P4? Denke dran, daß erst Prescotts SSE3 können.

 

[HGW]

Probiers mal mit der SSE3 App aus dem Archiv hier.
http://www.file-upload.net/download-1321999/MW-update18.rar.html

Die läuft bei mir problemlos.

Was ist es denn überhaupt für ne CPU? Nicht das es einer der ersten P4 mit Dualcore, aber ohne SSE3 ist (falls es das überhaupt gab).

lt. CPU-Z

Anhang anzeigen 13322


Meldung:
18.01.2009 14:52:51|Milkyway@home|[error] Process creation failed: Das System kann die angegebene Datei nicht finden. (0x2)

 

[Gipsel]

Frage zu MW & ATI CAL:

irgendwo stand, dass jemand eine CAL optim. MW-App bastelt:

ich würd auch mit testen & debuggn;
mein Testsystem : a3200, 2GB-Ram, ati-4650

Das bin ich. Ist übrigens aus Bequemlichkeitsgründen eine Kombination aus Brook+ und IL-Assembler mit CAL für die fehlenden Features von Brook.

Der momentane Stand sieht so aus, daß es inzwischen läuft und auch richtig rechnet. Was noch fehlt ist die (einfache) Skalierung der Threadanzahl, um die GPU ordentlich auszulasten.
Wenn das fertig ist, muß ich bloß noch Travis überzeugen, das Creditlimit aufzuheben D), weil wohl nicht so viel CPU-Zeit zusammenkommen wird. Außerdem muß man mal sehen, wie das überhaupt im Client läuft. Der bietet nämlich keine GPU-Unterstützung für ATIs, ist ja CUDA-only. Wer weiß, wie das dann mit dem Scheduling funktioniert. Ansonsten kann man das ja nur als Technologiedemonstration benutzen. Aber mal sehen. Vielleicht geht ja auch alles besser, als man glaubt.

Falls erhöhter Testbedarf besteht, melde ich mich.

 

[Crashtest]

Gipsel:

da ich als Delphi-User so gut wie kein C-Wissen hab, kann ich CAL (& Brook+) nicht in den Boinc 6.7 source integrieren - C ist für mich Chaos ich verwende { } für Kommentare und nicht um Funktion usw. zu basteln !!!

die Portierung der cal.h, cal_ext.h und calcl.h nach Delphi ist schon schwer genug ....


zur Integration in BOINC:

wenn man sich den BOINC Code der "coproc.cpp" und "coproc.h" ansieht, stellt man fest, BOINC ist es sogut wie egal was da sich als Coprozi meldet, solange die Projekt-App den Coprozi richtig nutzen kann; Boinc meldet nur Name, RAM, Anzahl ... mehr aber nicht !
und beschränkt die Anzahl der max. lauffähigen Anwendungen auf 8 ?!?

Daher sollte Berkeley langsam AMD/ATI CAL auch in de coproc.cpp... integrieren, aber immer noch keine Spur von CAL & Co im 6.7 Source

Es müssen halt mehr ATI Nutzer sich bei Berkeley melden - ATIs sind bei doubleprezi viel schneller als nV !!!

 

[Gipsel]

zur Integration in BOINC:

wenn man sich den BOINC Code der "coproc.cpp" und "coproc.h" ansieht, stellt man fest, BOINC ist es sogut wie egal was da sich als Coprozi meldet, solange die Projekt-App den Coprozi richtig nutzen kann; Boinc meldet nur Name, RAM, Anzahl ... mehr aber nicht !
und beschränkt die Anzahl der max. lauffähigen Anwendungen auf 8 ?!?

Daher sollte Berkeley langsam AMD/ATI CAL auch in de coproc.cpp... integrieren, aber immer noch keine Spur von CAL & Co im 6.7 Source

Es müssen halt mehr ATI Nutzer sich bei Berkeley melden - ATIs sind bei doubleprezi viel schneller als nV !!!

Das ist das Problem, BOINC kennt die ATIs nicht und meldet demzufolge rein gar nichts, kein Name, RAM oder Anzahl. Selbst wenn man das selber in der App alles feststellt, hilft das nicht viel, weil der Scheduler des Clients keinen Plan davon hat, daß man die GraKa benutzt. Da müssen wir mal ausprobieren, wie das dann läuft.

Daß die ATIs bei double precision Rechnungen deutlich schneller (schon HD4850 mehr als doppelt so schnell wie eine GTX280) sind, habe ich hier im Thread ja schon mehrfach erwähnt und war der ursprüngliche Grund dafür, mit ATIs anzufangen. Eine CUDA-Anwendung könnte man zwar in einer Stunde zusammenbekommen, die würde aber nur schwer mehr Durchsatz schaffen als ein schneller Quad.

 

[Crashtest]

Das ist das Problem, BOINC kennt die ATIs nicht und meldet demzufolge rein gar nichts, kein Name, RAM oder Anzahl.

deshalb habsch ja auch geschrieben, dass mein C-Wissen nicht reicht - sonst wäre schon längst in der coproc.cpp und coproc.h von Boinc\lib ein dritter Coproz Typ - AMD/ATI CAL ( & Brook+) mit dem was ich aus dem CAL SDK rausbekomme ...

aber evtl. kannst du dir mal den Quellcode der coproc.cpp & coproc.h anguggn die strucs usw. für AMD schreiben und nach Berkeley senden falls die's nicht auf de Reihe bekommen - wäre doch ne geile Werbung für Planet3Dnow! - CAL Support für Boinc by Planet3Dnow!

svn : http://boinc.berkeley.edu/svn/trunk/boinc

 

[AndreaHH]

so ... seit heute ist noch ein HOST bei MW tätig ... L@@K ...

gruß
FeuerKater

 

[JagDoc]

so ... seit heute ist noch ein HOST bei MW tätig ... L@@K ...

gruß
FeuerKater

Das ist meiner...
http://milkyway.cs.rpi.edu/milkyway/hosts_user.php?userid=7848

cu JagDoc

 

[AndreaHH]

Hey JagDog ... ist schon spaßig zu sehen wie das kleine Atömchen sich mit 4 MW WUs sich gleichzeitig beschäftigt ... wie braucht Mann denn überhaupt noch nen Quad ....

 

[TAL9000]

Welche App nutzt du jetzt? Irgendwie sind die Zeiten deutlich länger, sprich gut 1k Sekunden mehr^^

TAL9000

 

[AndreaHH]

die SSE3 von Gipsels Link ...

 

[TAL9000]

Probiere mal die MW opt App astronomy_ssse3_app.exe 888 KB (909.824 Bytes) Mittwoch, 17. Dezember 2008, 17:06:40 von Twodee, die brachte bei mir noch mal um die 100 Sekunden pro WU. http://www.file-upload.net/download-1321999/MW-update18.rar.html

Aber trotzdem braucht der 330 länger als der 270 mit einen Core

TAL9000

 

[AndreaHH]

dafür hat mein Atom 4 WUs am wickel ... dein 270´er hat ja nur einen + HT ... ich habe ja 2 + 2x HT

 

[TAL9000]

Trotzdem sind es eigenständige Cores, irgendwas bremst da dann, bin aber auch kein CPUSpezi
Weiß auch nicht wie es bei MW mit RAM Zugriffen usw. aussieht. So genau habe ich mir es damals nicht angeschaut.

TAL9000

 

[AndreaHH]

ja gut das stimmt natürlich das die 2 Kerne mit HT alle auf einen 2 GB DDR II Speicherriegel zugreifen ...

 

[JagDoc]

Bei mir laufen nur 3 Kerne mit MW. SSE3
Wenn alle 4 laufen wird Firefox sehr träge. Die Zeiten sind dann wie bei FeuerKater.
Das Problem ist auch das ich den Speicher im Bios nicht höher als 533 einstellen kann.
Da wird es bei einem 2GB Riegel etwas eng.
Der 270er läuft mit DDR666.

cu JagDoc

 

[AndreaHH]

naja solange noch die Remoteconsole gut funktioniert ist alles bestens ...

 

[Gipsel]

Ach Du liebe Güte. Wenn jetzt alle ihre Atoms rausholen, muß natürlich eine angemessene Applikation dafür her Habe deswegen das Ganze noch für ein paar mehr Befehlssätze kompiliert (das heißt fast alle).
Hier sollte jetzt so ziemlich jeder fündig werden. Die SSE1, SSE2 und SSE3-Versionen sind identisch zu den vorher verlinkten, aber es gibt jetzt zusätzlich SSE3_Atom, SSSE3 (65nm Core2), SSE4.1 (45nm Core2) und SSE4.2 (i7).
Performancetechnisch sollte das aber alles nicht mehr viel bringen, die SSE3_Atom-Variante könnte sogar langsamer sein als die normale SSE3 (dann eben mal die SSSE3 versuchen), weil irgendwie der Intel-Compiler der Meinung ist, ein Atom kommt besser mit skalarem Code zurecht

So aber jetzt mache ich mal der GPU-App Beine

 

[Ole]

3DNow!

*schnüff*

 

[indiana_74]

MAC OS X PPC *heul*

 

[heavy-Ions@boinc]

@Gipsel&2d
hat euch der travis eigentlich nun schon mal direkt angeschrieben wegen des codes?
In jedem Post von ihm kommt ja zur zeit ja die "aufforderung" den code mitzuteilen damit er die opt-apps zur standard-app machen kann.

 

[Opteron]

Performancetechnisch sollte das aber alles nicht mehr viel bringen, die SSE3_Atom-Variante könnte sogar langsamer sein als die normale SSE3 (dann eben mal die SSSE3 versuchen), weil irgendwie der Intel-Compiler der Meinung ist, ein Atom kommt besser mit skalarem Code zurecht

Naja, SSE Befehle brauchen auf den Atom halt ein "paar" Takte mehr, vielleicht deswegen.
Ansonsten wäre es wohl am Besten, wenn beide Apps pro (echten) Kern einsetzen könnte, da würden sich dann wohl die Recheneinheiten nicht so arg überschneiden und SMT somit effektiver sein.
WENN nicht eh schon der 533er SchmalspurFSB limitiert, was bei 4 Threads sicher schon der Fall ist ...

ciao

Alex