Archiv verlassen und diese Seite im Standarddesign anzeigen : Hmmer Laufzeittest auf AMD-MS Systemen, bitte mitmachen
Hiho,
wie vielleicht einige bemerkt haben, sind die Ausführungszeiten der HMMer-Applikation auf K8 Windows Maschinen etwas mager. Alte P4 Systeme sind schneller als neue A64. Anscheinend gibts ein Problem mit der Windows .exe, denn die Zahlen unter Linux sind laut "Project scientist" rattei auf den Opterons schneller:
Pentium 4: 2,66GHz: 1m12.073s
Opteron 248, 2,2 GHz: 1m6.816s
Ich hab die jetzt bei mir unter Windows auf meinem Opteron @2,2 GHz rechnen lassen und komme dabei leider auf 2m10s. :(
Wäre schön, falls noch mehrere Leute messen könnte, dauert nicht lange, insgesamt gehen wohl max. nur 5 min drauf.
Und so gehts:
1. Test WU in ein Verzeichnis runterladen unter:
http://boinc.bio.wzw.tum.de/boincsimap/download/testwu
2.die hmmr 5.08 exe in dasselbe Verzeichnis kopieren, oder der einfachheithalber auch runterladen:
http://boinc.bio.wzw.tum.de/boincsimap/download/hmmer_5.08_windows_intelx86.exe
3. Dos Fenster aufmachen und in das Verzeichnis wechseln
4. Priorität der cmd.exe im Taskmanager auf Echtzeit stellen
(bin mir nicht sicher, ob es das braucht, aber sicher ist sicher :) )
5. Zum Zeitmessen die Systemuhr neben das Dos Fenster bugsieren.
(falls einer ne einfachere Methode kennt, um die Laufzeit zu messen, nur her damit)
6. Das Programm aufrufen mit:
hmmer_5.08_windows_intelx86.exe -r result -w testwu.htm -n
7. Warten und auf die Uhr schauen ;-)
8. Ergebis hier im Thread Posten (CPU-Typ, Takt und Laufzeit)
9. Viele Dank ;-)
ciao
Alex
Hi Opteron,
sehr gerne:
*Athlon 64 X2 3800+ Manchester E4 @2,2GHz
*Speicher 1:1 / 2,5-3-3-7 Dual-Channel
*2min 3 sec
Deine Hypothese würde ich allerdings auch auf Intel-Systeme allgemein, nicht nur P4s, erweitern: Ein Kumpel von mir mit einem 2GHz Dothan (Laptop, also nicht übertaktet) erreicht die letzten Tage mit ca 4000s im Schnitt nahezu die halbe WU-Laufzeit wie mein X2.
Die beiden Hosts der Vollständigkeit halber:
http://boinc.bio.wzw.tum.de/boincsimap/results.php?hostid=36412
http://boinc.bio.wzw.tum.de/boincsimap/results.php?hostid=38661
MfG
Storm
Die Wus sind auch unterschiedlicher als sie es nicht sein können bei Hmmer - laufzeien zwischen 1:30h und 3:45h sind vertreten bei meinen beiden X2ern - trotzdem liefer ich gleich mal benchmarks meiner 3 Systeme (Wenn das Encoding hier fertig ist).
Was immer noch auffällt: die Page-Faults sind immer noch extremst ausgeprägt - hier 2 Screenshots von meinen beiden X2-Systemen (jeweils 2 HMMER 5.05 WUs am Rechnen).
Auf dem Centrino schauts aber auch nciht besser aus (8 Millionen Faults bei 18 Minuten CPU Time - (Gesamtzeit geschätzr knapp 1:50h - HMMER 5.08)
Eventuell sind hier die Intels wegen der längeren Pipelines / Sprungvorhersagen im Vorteil und man sollte hier den Hebel ansetzen?
Zeit am Taskmanager an echter CPU-Zeit abgelesen (also einfach gewartet bis der HMMER 5.08 Task verschwindet.)
System 1) X2 3800+ @ 2x 2500 MHZ, 2 GB Ram. 1:50 Min - knapp 660.000 Pagefaults (Unbenannt-1.gif)
System 2) X2 3800+ @ 2x 2000 Mhz, 512 MB Ram. 2:27 Min - knapp 660.000 Pagefaults
System 3) Dothan 1.6 Ghz, 1 GB Ram. 1:33 Min Knapp 670.000 Pagefaults. Erstaunlich: die ersten 50% der WU brauchen knapp 1 Minute, der Rest nur noch 33 Sekunden.
Was Wieder auffällt: Sys1) und Sys3) erreichen nach 1 Minute die 50 % ziemlich exakt - dann zieht der Intel Dothan aber gnadenlos davon und bläst die letzten 50% in 33 Sekunden durch während der AMD X2 50 Sekunden dafür braucht.
Habt ihr irgendeinen 2-Pass-Algo implementiert?
Eventuell sind hier die Intels wegen der längeren Pipelines / Sprungvorhersagen im Vorteil und man sollte hier den Hebel ansetzen? Na, der Witz ist ja, das die AMDs unter Linux schneller sind, d.h. es muss ein Compiler Problem sein, vielleicht sind es auch die page faults, förderlich sind sie der Performance auf alle Fälle nicht ... In letzerem Fall stellt sich dann aber die Frage, wieso die Pentiums davon nicht betroffen wären ... *kopfkratz
Aja, ein paar Vergleichswerte mit Pentiums 3/4/M wären vielleicht auch interessant :)
ciao
Alex
Update.
Habe alle 3 Rechner jede WU 2x rechnen lassen und immer brav die tempfiles und results gelöscht.
@Opteron: find ich gut dass du dich hierfür engagierst - postest du den Thread oder das dann alles fein im SIMAP forum? hab kein bock mich da selbst anzumelden.
Hi Opteron,
brauch mit meinem X2 4600 mit 2,4 GHz 2m03s.
mfg
Ali
@Opteron: find ich gut dass du dich hierfür engagierst - postest du den Thread oder das dann alles fein im SIMAP forum? hab kein bock mich da selbst anzumelden. Erst mal danke an die Einsender der bisherigen Ergebnisse.
Falls noch jemand auf einen System testen kann, das bisher hier noch nicht erwähnt wurde (z.B. Athlon XP, P4) bitte testen & posten. 2 Quellen pro Architektur wäre optimal, um Fehler auszuschließen.
Im Simap Forum gibts schon einen thread (http://boinc.bio.wzw.tum.de/boincsimap/forum/viewtopic.php?t=507&postdays=0&postorder=asc&start=0), Sir Ulli hat ihn gestartet. Im Moment scheint die WIndows "Problematik" da aber nicht bekannt zu sein, da die Projektleute nur unter Linux testen, und da alles ok scheint.
Naja je mehr Ergebnisse wir hier sammeln, desto überzeugender wird es :)
ciao & nochmal Danke
Alex
Athlon XP-M 2600+ (Barton, 2GHz, FSB266)
*2min 56sec
Sir Ulli
19.09.2006, 22:51
Athlon64 3.200+ S754 2:20
Athlon64 X2 4.400+ S939 2:05
beides Rechner 4 aus meiner sig, der P4 3.2 den ich gerne testen möchte liegt hier leider nur in einzelteilen...
mfg
Sir Ulli
Pentium D940 @4200MHz 53sec
brauch mit meinem X2 4600 mit 2,4 GHz 2m03s.
Gleiche Zeit mit X2 3800+ @ 2.4 GHz. Laut Taskmanager paar Sekunden weniger (so um 1m50s).
Cherry
hab mal ne Frage am Rande, was hat die WU für ne Endung?
kann das nicht ausführen, glaube der Fehler liegt in der falschen/fehlenden Endung
EDIT:
hab's gefunden.
1min 33sek
X2 3800 @ 3GHZ
die endung ist egal --> rechtsklick speichern unter.. dann sollte ne .htm bei rauskommen
die einfach wie oben erwähnt in der commandline ausführen und berechnen lassen.
Sir Ulli
19.09.2006, 23:28
hab mal ne Frage am Rande, was hat die WU für ne Endung?
kann das nicht ausführen, glaube der Fehler liegt in der falschen/fehlenden Endung
du musst in dem Verzeichniss 2 Dateien haben
testwu.htm und
hmmer_5.08_windows_intelx86.exe
und dann mit diesem Befehl
hmmer_5.08_windows_intelx86.exe -r result -w testwu.htm -n
ausführen...
@JagDoc
das sagt wohl alles, die P4s scheinen ja nur so zu fliegen, doppelt so schnell wie mein X2 4.400...
mfg
Sir Ulli
hab es schon gefunden, stand ja in der Befehlszeile, ohne Endung geht es nicht.
-----------------------------------------------
X2 3800 @ 3,0GHZ
1min 33sek
------------------------------------------------
X2 3800 @ 3,1GHZ
1min 30sek
--------------------------------------------------
du musst in dem Verzeichniss 2 Dateien haben
testwu.htm und
hmmer_5.08_windows_intelx86.exe
Nicht unbedingt. Da die TestWU ohne Endung ausgeliefert wird setzen verschiedene Browser scheinbar verschiedene Standardendungen dafür ein.
Opera z.b. macht ne .txt draus.
Cherry
indiana_74
20.09.2006, 12:53
Beteilige mich nächste Woche, bin im Augenblick leider nicht bei meiner Farm *noahnung*
Beteilige mich nächste Woche, bin im Augenblick leider nicht bei meiner Farm *noahnung* Kein Problem, es wird sich hoffentlich noch der ein oder andre in Zwischenzeit finden ;-) 1-2 P4 Ergebnisse wären noch schön, ansonsten könnte man JagDocs Ergebnis ja alleine dem hohen Takt zurechnen.
Danke wieder an allen weiteren Einsendern!
ciao
Alex
Na denn will ich mal.
3,2 GHz P4 Prescott HT enabled 1:16 RAM @DDR2 400 :( 3-3-3 9
3,2 GHz P4 Prescott HT disabled 1:11 RAM @DDR2 400 :( 3-3-3 9
Athlon 64 2,4 GHz 1:55 RAM @ DDR 400 2,5-3-3 7
1. Athlon XP 2400+ @ 2 GHz 2:38 Ram @PC333 2,5-3-3 6
2. Athlon XP 2400+ @ 2 GHz 2:43 Ram @PC266 n/a
Ich hoffe wir kommen an der Stelle weiter.
Reguläre WU's brauchen auf meinem A64 so ca. 2 h im Durchschnitt...
So long
Dusty
hoffentlich wird da bald was optimiert, man muss doppelt soviel Rechenaufwand investieren, bekommt aber nur die gleichen Punkte wie bei Simap
CPU time (sec).....claimed credit........granted credit
6,905.50...............85.32....................17.94
5,932.59...............73.30....................9.29
:] :] :] :] :] :] :]
so macht das keinen Spaß und man verliert den Ansporn.......
Sir Ulli
20.09.2006, 23:37
hoffentlich wird da bald was optimiert, man muss doppelt soviel Rechenaufwand investieren, bekommt aber nur die gleichen Punkte wie bei Simap
:] :] :] :] :] :] :]
so macht das keinen Spaß und man verliert den Ansporn.......
damit ich nicht der einzige bin
http://boinc.bio.wzw.tum.de/boincsimap/forum/viewtopic.php?t=507
immer schön posten...
mfg
Sir Ulli
Na denn will ich mal.
P4 Prescott HT enabled 1:16
P4 Prescott HT disabled 1:11
Athlon 64 2,4 GHz 1:55
1. Athlon XP 2400+ @ 2 GHz 2:38 Ram @PC333
2. Athlon XP 2400+ @ 2 GHz 2:43 Ram @PC266
Ich hoffe wir kommen an der Stelle weiter.
Reguläre WU's brauchen auf meinem A64 so ca. 2 h im Durchschnitt... Hi Dusty, danke für Deine Tests, bitte füge der Vollständigkeit halber noch die Taktfrequenz des P4 Prescotts und den Ramtakt/Speichertimings beim Athlon64 hinzu. :)
damit ich nicht der einzige bin
http://boinc.bio.wzw.tum.de/boincsimap/forum/viewtopic.php?t=507
Jo, für den thread mache ich das ja auch. Erst mal hier die Daten sammeln, dann können wir Ihnen das auf einmal schreiben, und dann sollen sie das bitte mal erkären ;-)
ciao
Alex
Habs editiert aber hier nochmal in Kürze
3,2 GHz P4 Prescott HT enabled 1:16 RAM @DDR2 400 3-3-3 9
3,2 GHz P4 Prescott HT disabled 1:11 RAM @DDR2 400 3-3-3 9
Athlon 64 3200+ @ 2,4 GHz 1:55 RAM @ DDR 400 2,5-3-3 7
1. Athlon XP 2400+ @ 2 GHz 2:38 Ram @PC333 2,5-3-3 6
2. Athlon XP 2400+ @ 2 GHz 2:43 Ram @PC266 n/a
Stand eigentlich auch in meinem System. Aber irgendwie nimmt er den Eintrag im Profil nicht so ernst und zeigt mein System nicht unter meinem Avatar an. :(
So long
Dusty
Edit: Toll jetzt stehts wieder da!!! *freu*
godless.prayer
21.09.2006, 12:11
A64 3500+ 2,2GHz - 2:15Minuten
Celeron 335 2,8GHz - 1:40Minuten *chatt*
Stephan G.
21.09.2006, 14:58
So, dann ich auch mal.
A64 X2 3800, 1024 MB Ram - 2:14 Min.
Das ganze dann nochmal auf der selben Maschine unter SuSE 10.1:
1:11 Min
Wenn nicht schon alle meine Crunchmaschinen Linuxboxen wären, dann würd ich jetzt aber umsteigen. ;D
Nein, Spass beiseite, da ist doch eindeutig was an der Windows App. völlig faul.
Unter Linux laufen die Hmmer WU's nur unwesentlich länger als die Simap WU's.
http://www.linux-einblick.de/simap.jpg
Hi,
hier schon einmal vorab meine XP Ergebnisse (just for reference):
1. Athlon XP2600+ @ 2153 MHz, FSB 172 MHz, Ram 1 GB (Dual Channel) @ 3-3-3-7 : 2:36 min
2. Sempron 2800+ (Mobile) @1600 MHz, FSB 200, Ram 512@160MHz MB @2.5-3-3-7: 3:06 min
(können die Daten vomSempron stimmen ?, habe ich aus SiSoft Sandra)
Gruß
Joe
So, dann ich auch mal.
A64 X2 3800, 1024 MB Ram - 2:14 Min.
Das ganze dann nochmal auf der selben Maschine unter SuSE 10.1:
1:11 Min
Wenn nicht schon alle meine Crunchmaschinen Linuxboxen wären, dann würd ich jetzt aber umsteigen. ;D
Nein, Spass beiseite, da ist doch eindeutig was an der Windows App. völlig faul.
Unter Linux laufen die Hmmer WU's nur unwesentlich länger als die Simap WU's.
Vielen Dank für deinen Doppeltest, deutlicher kann mans nicht mehr beweisen, ich poste das jetzt mal im Simap Forum, das sollte reichen :)
ciao
Alex
.
EDIT :
.
So, wie immer sofort ne Antwort bekommen, die Jungs sind dran ;-)
Wir werden zunächst verschiedene compiler testen denn der Compiler ist ja das einzige was die Linux- und Windows-Applikationen unterscheidet. Alle Compilerflags etc. waren sonst gleich.
Ich denke dass wir da eine Lösung finden und als 5.09 hoffentlich bald online stellen können. Dann schauen wir mal, was passiert :)
ciao
Alex
Riddler82
21.09.2006, 22:24
na hoffentlich...
Die hmmer-app ist echt furchtbar auf AMD-MS Systemen.
über 4h ist einfach inakzeptabel.
Der Vorteil von WUs die ca. 50-80 minuten dauern, mal schnell zwei drei WUs durchzuhauen, ist einfach weg.
Ich werd SIMAP solange stoppen bis ich weiss das die neue 5.09er app auf AMD-MS wieder schneller ist.
Wenns ja wenigstens nach dem alten Creditsystem abgerechnet würde - Credits nach aufwand und nicht nach WU-Größe....
Sir Ulli
21.09.2006, 23:40
Vielen Dank für deinen Doppeltest, deutlicher kann mans nicht mehr beweisen, ich poste das jetzt mal im Simap Forum, das sollte reichen :)
ciao
Alex
.
EDIT :
.
So, wie immer sofort ne Antwort bekommen, die Jungs sind dran ;-) Dann schauen wir mal, was passiert :)
ciao
Alex
eines muss man den Leuten von SIMAP, lassen sie geben sich echt Mühe, was man nicht von allen BOINC Teams sagen kann, habe gerade bei Seti@home wieder WUs von 1999 bekommen, da fragt man sich doch ob man das nicht lieber lässt...
mfg
Sir Ulli
Die Simapler wissen wenigstens, dass Ihre Daten auch nützlich sein werden...
Bei Seti ist es leider so, dass nicht genug Daten da sind und dann einfach wieder mal alte recycled werden bevor bald das neue Teleskoparray daten liefert.
Danke erstmal an alle fuer die Tests und die Unterstuetzung. Wir testen die Apps normalerweise unter Windows nur auf Intel-PCs, waehrend wir fuer fuer die Linux-Tests P4s, Athlons und Opterons zur Verfuegung haben. Daher sind wir nicht selbst drauf gekommen. Durch Eure Tests ist klar: es gibt ein Problem mit der Windows-App auf AMD-CPUs.
Ich habe nun heute den ganzen Abend nach der Ursache gesucht. Die Vermutung war klar: Compiler bzw. Compileroptionen. Aber: Das Performance-Problem entsteht nicht durch den verwendeten Compiler und auch nicht durch die Compileroptionen. Es spielt keine Rolle, ob mit Visual Studio 2005 oder MINGW compiliert wird. Es ist auch egal ob man fuer Athlon-XP oder Pentium3 optimiert: stets ist mein Centrino-Notebook fast doppelt so schnell wie ein Athlon64, den ich zum Vergleich verwendet habe. Es ist frustrierend, aber ich denke das Problem liegt tiefer, irgendwo im Zusammenspiel zwischen Windows und den AMD-CPUs. Kennt jemand von Euch aehnliche Schwierigkeiten mit Windows-Applikationen die auf AMDs zu langsam laufen? Unsere Entwickler und ich haben so was noch nie erlebt, daher sind wir momentan etwas ratlos...
beste Gruesse
Thomas
Sir Ulli
22.09.2006, 00:10
das ist wirklich höchst seltsam
ich war ja damals sogar BOINC BETA Terster, before BOINC nach diversen Test online ging, aber dieses Prob ist nicht bekannt, nutzt schon immer AMD CPUs, und ein Tipp von mir an Windows liegt es nicht, denn ich setze es schon immer ein, und habe auch schon immer gute Vergleiche gehapt,
ein Rechner mit P4 3.2
ein Rechner mit AMD 3.200+
und neu ein Rechner mit AMD X2 4.400+
deswegen wäre es mir schon früher aufgefallen.
mfg
Sir Ulli
Ich habs mal spasseshalber durchlaufen lassen...
1:28 min
Aber sagt mal, da ist doch was verkehrt, wenn da ein Fehler angezeigt wird???
Gut es ist ne .txt aber *suspect*
http://img213.imageshack.us/img213/1913/zwischenablageud6.jpg (http://imageshack.us)
Sir Ulli
22.09.2006, 00:19
Ich habs mal spasseshalber durchlaufen lassen...
1:28 min
Aber sagt mal, da ist doch was verkehrt, wenn da ein Fehler angezeigt wird???
Gut es ist ne .txt aber *suspect*
http://img213.imageshack.us/img213/1913/zwischenablageud6.jpg (http://imageshack.us)
der Fehler ist normal, den hatte ich auch, aber mit was für einem System, das wäre interessant...
mfg
Sir Ulli
<----mein Sys ;)
.
EDIT :
.
Hab mir eure Ergebnisse mal angeschaut, das relativ schnell für nen A64 SC ne :)
Grad nochmal durchlaufen lassen 1:32min*noahnung*
Wichtige Frage an alle zum Untermauern einer Theorie:
bitte schaut mal nach wieviel L2 Caches eure AMDs haben (meine sind z.B. beides Toledos mit 512 KB)
Wenn meine Theorie stimmt, müßte ein AMD mit 1 MB schon DEUTLICH schneller SIMAPPEN als einer mit 512 Kb.
(Wenn meine Quellen stimmen, haben den nur der 4400+ und der 4800+)
Sir Ulli
22.09.2006, 01:05
Wichtige Frage an alle zum Untermauern einer Theorie:
bitte schaut mal nach wieviel L2 Caches eure AMDs haben (meine sind z.B. beides Toledos mit 512 KB)
Wenn meine Theorie stimmt, müßte ein AMD mit 1 MB schon DEUTLICH schneller SIMAPPEN als einer mit 512 Kb.
nein mein Toledo
Athlon64 3.200+ S754 2:20
Athlon64 X2 4.400+ S939 2:05 der toledo mit 2 x 1024 KB
beides Rechner 4 aus meiner sig, der P4 3.2 den ich gerne testen möchte liegt hier leider nur in einzelteilen...
mfg
Sir Ulli
mfg
Sur Ulli
Dann langt das eine MB L2 Cache wohl doch noch nicht aus ;)
.
EDIT :
.
Ich hab ernsthaft überlegt schnell n virtuelles Linux aufzusetzen.. die paar % Performance die verloren gehen hol ich beim crunchen locker wieder rein...
Ich hab ernsthaft überlegt schnell n virtuelles Linux aufzusetzen.. die paar % Performance die verloren gehen hol ich beim crunchen locker wieder rein... Hm ja, hab ich auch mal drangedacht, könnte man vielleicht hmmer mal für cygwin compilieren ? Vielleicht reicht das ja schon ;-)
Ansonsten fällt mir bei dem seehr komischen Problem nur noch der Gang zu AMD oder M$ selbst ein. Nachdem da nur AMD und nur Windows betroffen ist, schauen sie sich das vielleicht an ...
Da ja schon Visual Studio benützt wurde, wurde auch der Intel Compiler mal ausprobiert ? Vielleicht hilfts ja .
Anderer Versuch wäre noch eine Win64 Version, vielleicht, vielleicht ... *noahnung*
Aber ich gebe zu, ich rate auch nur wahllos :(
ciao
Alex
P.S: Mein Opteron 146 hat auch 1 MB Cache ...
Riddler82
22.09.2006, 10:52
Kann mir nicht vorstellen das es am L2 Cache liegt, es sind ja auch Celerons teilweise um welten schneller *suspect*
Ansonsten fällt mir bei dem seehr komischen Problem nur noch der Gang zu AMD oder M$ selbst ein.
Ja, das mache ich gerade, es ist sinnvoller als endlos selbst rumzuprobieren ohne die noetige Expertise zu haben. Ich versuche AMD und M$ fuer das Problem zu interessieren und arbeite mich gerade zu den entsprechenden Leuten durch.
Beste Gruesse
Thomas
Ja, das mache ich gerade, es ist sinnvoller als endlos selbst rumzuprobieren ohne die noetige Expertise zu haben. Ich versuche AMD und M$ fuer das Problem zu interessieren und arbeite mich gerade zu den entsprechenden Leuten durch. Tja, dann mal viel Glück. Kleiner Diskussionstipp:
Bei MS betonen, dass es unter Linux läuft, bei AMD, dass es mit Intel keine Probleme gibt ;D
Im Ernst, AMD legt ja auch ein Augenmerk auf HPC, ich hoffe Du bekommst da dann auch Unterstützung, auch wenn Superrechner wohl nur selten unter Windows laufen :)
ciao & viel Erfolg
Alex
affenkopf
25.09.2006, 17:35
Wie ich ja gelesen habe, bekommt man das selbe Ergebnis auch unter Linux raus, wenn dort WINE benutzt wird.
Wie ich ja gelesen habe, bekommt man das selbe Ergebnis auch unter Linux raus, wenn dort WINE benutzt wird. Hab ich auch gelesen, aber wer sagt mir, dass das nicht wegen der Emulation ist, sondern wegen des "AMD-Windows Bugs" ?
ciao
Alex
affenkopf
25.09.2006, 21:05
Kennt denn jemand ähnliche Projekte, wo dieser Effekt auch auftritt?
Sir Ulli
25.09.2006, 23:06
Kennt denn jemand ähnliche Projekte, wo dieser Effekt auch auftritt?
nein
in anderen, mir bekannten Projecten, tritt dieser Fehler nicht auf.
mfg
Sir Ulli
So, dann ich auch mal.
A64 X2 3800, 1024 MB Ram - 2:14 Min.
Exakt den gleichen wert hab ich auch...
Ok 2:13 *g*
Mal schaun wo der fehler liegt
indiana_74
27.09.2006, 11:18
Also jetzt aber ..... ;D
AMD FX60
2.613GHz / FSB 201MHz / 2.048MB Speicher Dual-Channel 3-3-3-8-11
Laufzeit: 1:50 Min
Intel Core2Duo 6600
3.555GHz / FSB 395MHz / 512MB Speicher Single-Channel 3-5-5-18
Laufzeit: 0:35 Min:o
Beide Tests unter Windows XP SP2
Sir Ulli
29.09.2006, 01:14
und dann dieses
habe ich da was verpasst, oder hat der User einfach nur Müll gepostet
FWIW, running two instances of the client, one the 32-bit client, the other, the 64-bit client, on the same 4-core system, but limiting each client to 2 cores, I can compare the relative performance of 32-bit and 64-bit SIMAP's HMMER: the 64-bit version is about 7% faster.
http://setiathome.berkeley.edu/forum_thread.php?id=33041
http://www.planet3dnow.de/images/zusatz/p3d_simap.png
einen 64 Bit Client den es noch gar nicht gibt... *noahnung*
mfg
Sir Ulli
einen 64 Bit Client den es noch gar nicht gibt... *noahnung* Ruhig Ulli, mal keine Panik. Postest da in allen Forum kreuz und quer ... klar gibts nen 64bit client, aber für Linux ... steht doch nirgends, dass er windows meint ;-) simap_5.11_i686-pc-linux-gnu Signature AMD Opteron CPUs that run Linux kernels < 2.6.9 should use this default i686 binary x86 and x86_64 Linux http://boinc.bio.wzw.tum.de/boincsimap/appdownloads.php
hmmer gibts natürlich auch ...
Wieso es nichts für Windows gibt ... *noahnung*
Im einfachsten Fall, weil sie keine Plattform, i.e. Windows Lizenz zum compilieren haben :)
ciao
Alex
ZentrumDesChaos
29.09.2006, 12:00
Hi,
hab grad mal getestet
x2 4400+ @ 2,6GHz
1:46min
MfG
Hi allerseits,
der aktuelle Stand des Profilings ist folgender:
1. Compilertests:
Getestete Compiler bislang:
- Microsoft Visual C++ 8 (Visual Studio 2005)
- PGI Workstation 6.2.3
- Intel C++ Compiler 9.1
- GCC 3.4.2, 3.4.5 (MINGW)
Mit allen compilern wurden logischerweise native Windows-Konsolenanwendungen erstellt, also ohne CYGWIN-Umfeld o. dgl.
Getestet wurde sowohl mit dem code unserer hmmer app rc-5.09 sowie mit dem Original HMMer code 2.3.2 (open source). Die von mir verwendete Test-Hardware ist ein Centrino-Notebook sowie ein Athlon64-PC, mit der simap-app zeigen diese Maschinen das in etwa zu erwartende Performance-Verhaeltnis (Centrino 25% langsamer als A64).
Zu langsam auf AMD sind sowohl unsere hmmer app als auch HMMer 2.3.2. Bei der Berechnung von Testworkunits bzw. Testdateien auf den oben genannten Testsystemen schafft der Centrino die Arbeit in ca. 2/3 der Zeit des Athlon64. Schlussfolgerung: Das Performanceproblem entstammt nicht unserem Workunit-/Resultmanagement oder unserem Modelcache, sondern liegt im verwendetet HMMer-Code.
Die builds aller compiler sind von aehnlicher performance. Es gibt kleinere Unterschiede, im Mittel erzeugt der Intel-Compiler den schnellsten code, jedoch dicht gefolgt von den anderen. Aber der Abstand Intel-AMD bleibt jeweils derselbe, da halfen alle CPU-spezifischen Optimierungen nichts.
2. Profiling mit AMD Code Analyst
Sowohl auf Intel- als auch AMD-CPUs verbringt die CPU die meiste Zeit in der Funktion P7Viterbi() aus fast_algorithms.c des HMMer 2.3.2 packages. Interessant: Intel-CPUs verbrauchen hier ca. 2/3 der Rechenzeit, AMD-CPUs hingegen mehr als 90%. Ich denke, dass hier die Ursache des Problems liegt. Schaut man genauer, so sind die Wertezuweisungen in der Dynamic Programming (DP)-Matrix diejenigen Anweisungen, die in P7Viterbi() die meiste Zeit brauchen. Konkret ist das dieser Bereich in fast_algorithms.c:
...
for (i = 1; i <= L; i++) {
...
for (k = 1; k <= M; k++) {
mc[k] = mpp[k-1] + tpmm[k-1];
if ((sc = ip[k-1] + tpim[k-1]) > mc[k]) mc[k] = sc;
if ((sc = dpp[k-1] + tpdm[k-1]) > mc[k]) mc[k] = sc;
if ((sc = xmb + bp[k]) > mc[k]) mc[k] = sc;
mc[k] += ms[k];
if (mc[k] < -INFTY) mc[k] = -INFTY;
dc[k] = dc[k-1] + tpdd[k-1];
if ((sc = mc[k-1] + tpmd[k-1]) > dc[k]) dc[k] = sc;
if (dc[k] < -INFTY) dc[k] = -INFTY;
if (k < M) {
ic[k] = mpp[k] + tpmi[k];
if ((sc = ip[k] + tpii[k]) > ic[k]) ic[k] = sc;
ic[k] += is[k];
if (ic[k] < -INFTY) ic[k] = -INFTY;
}
}
...
}
...
Die beiden Schleifen laufen bis zur Laenge der Sequenz (L) bzw. der Laenge des Models (M). Typische Sequenzlaengen sind 300, typische Modellaengen 500. Es gibt aber einzelne Sequenzen und Models die mehr als 10mal laenger sind. Dann wird durch ResizePlan7Matrix() weiterer Platz fuer die DP-Matrix dynamisch alloziert.
Vermutlich ist der Zugriff auf diese DP-Matrix das Problem. Warum Intel- und AMD-CPUs sich da so unterschiedlich verhalten kann eigentlich nur durch die L2-Cache-Groesse erklaert werden. Unklar bleibt dann aber, warum auch AMD-CPUs mit grossen L2-Caches langsam sind. Unklar bleibt auch, warum unter Linux weniger Zeit zum Zugriff auf die Matrix benoetigt wird als unter Linux.
An diesem Punkt waere es interessant, wenn C-Experten unter Euch sich die Implementierung von ResizePlan7Matrix() in core_algorithms.c des HMMer anschauen koennten. Der sourcecode ist frei verfuegbar: hmmer.janelia.org
Gibt es bessere Wege diese Matrix zu implementieren? Man koennte diesen Teil im HMMer relativ leicht austauschen, das wurde wie im code zu erkennen fuer Altivec-CPUs bereits getan.
Beste Gruesse
Thomas
Nachtschicht
03.10.2006, 03:19
Auf den ersten Blick sind eine Reihe überflüssiger Arrayzugriffe mit einem Index in dem Code. Statt dessen sollte so lange wie möglich mit lokalen Variablen gearbeitet werden.
/* Ausgangspunkt */
mc[k] = mpp[k-1] + tpmm[k-1];
if ((sc = ip[k-1] + tpim[k-1]) > mc[k]) mc[k] = sc;
if ((sc = dpp[k-1] + tpdm[k-1]) > mc[k]) mc[k] = sc;
if ((sc = xmb + bp[k]) > mc[k]) mc[k] = sc;
mc[k] += ms[k];
if (mc[k] < -INFTY) mc[k] = -INFTY;
/* Der untenstehende Code müßte das Gleiche machen, ist aber effizienter
* Unsinnige Arrayzugriffe wurden eliminiert
*/
int k1 = k -1;
int mc_k = mpp[k1] + tpmm[k1];
if ((sc = ip[k1] + tpim[k1]) > mc_k) mc_k = sc;
if ((sc = dpp[k1] + tpdm[k1]) > mc_k) mc_k = sc;
if ((sc = xmb + bp[k]) > mc_k) mc_k = sc;
mc_k += ms[k];
if (mc_k < -INFTY) mc_k = -INFTY;
mc[k] = mc_k;
Ein möglicher nächster Schritt wäre dann, statt mit Array+Index über Pointer zuzugreifen und am Ende der Schleife den Pointer zu inkrementieren
der Fehler ist normal, den hatte ich auch, aber mit was für einem System, das wäre interessant...
mfg
Sir Ulli
Fehler sind nie normal.
Der Compiler findet erstens eine Funktion nicht.
Zweitens wird ein anderes (Speicher-??)Modell genommen.
Da scheint etwas im argen zu liegen, obwohl das Programm läuft. Habt ihr schon den grund für diese Fehlermeldungen überprüft und abgecheckt, welche Auswirkungen diese Fehler und Änderungen auf die Laufzeit eures Programmes haben?
Fehler sind nie normal. Doch in dem Fall schon. Rattei hatte eine Test-Wu zur Verfügung gestellt, die ursprünglich zum Testen der 5.08er Version gedacht war. In der Version wurden das Error Handling ausgebaut, da zuvor ein paar Fehler nicht behandelt wurden. Der Fehler in der Test-Wu ist somit "gewollt", zum testen eben :)
@Nachtschicht:
Danke für dir Tipps, hast Du schon mal etwas davon gehört:
http://www.microquill.com/index.html ?
Ist mir aufgefallen, als ich in der aktuellen c't den Spec2006 Artikel gelesen habe. Die schreiben da, dass ein Benchmark ohne den Smartheap total einbrach, unter Linux allerdings nicht so stark, wie unter Windows.
Das hört sich ja bekannt an ...
ciao
Alex
Nachtschicht
03.10.2006, 13:04
hast Du schon mal etwas davon gehört:
http://www.microquill.com/index.html ?
Nein, aber ich habe mich kurz mal reingelesen. So wie ich es verstehe, hat Smartheap die Speicherzugriffe für multithreaded Programme optimiert. Dass das vorlegende Programm davon profitieren könnte, bezweifle ich aber.
DIe bessere Linux-Performance könnte man einfach mit besseren (Gnu-) Compilern erklären als derjenigen, die in Windows verwendet werden. Vielleicht wird auch in Windows eine Multithreaded-Option verwendet und in Linux nicht.
Aber wie bereits gesagt, hat der jetzige Code noch ziemlich viel Potential für Verbesserungen. Ein guter Compiler für ein single-threaded Programm sollte das auch allein hinbekommen, aber man muss es ihm ja nicht unnötig schwer machen.
tomturbo
03.10.2006, 14:28
DIe bessere Linux-Performance könnte man einfach mit besseren (Gnu-) Compilern erklären als derjenigen, die in Windows verwendet werden. Vielleicht wird auch in Windows eine Multithreaded-Option verwendet und in Linux nicht.
Nein so einfach kann man das nicht, weil unter Windows der selbe gcc Kompiler verwendet wurde als bei Linux. Aber offensichtlich ist das Speichermanagement von Linux im Vorteil, sodass pagefaults besser/schneller verarbeitet werden.
lg
__tom
Exakt den gleichen wert hab ich auch...
Ok 2:13 *g*
Mal schaun wo der fehler liegt
Das war ein X2 3800+ mit 2048 Ram
Ich hab jetzt mal einen
XP2400@ 2.25 Ghz (13.5x166) laufen lassen, da braucht das ganze so 2:20-2:25.
Müsste die CPU nicht eigentlich doch etwas langsamer sein, als ein K8 ?
tomturbo
06.10.2006, 13:16
Das war ein X2 3800+ mit 2048 Ram
Ich hab jetzt mal einen
XP2400@ 2.25 Ghz (13.5x166) laufen lassen, da braucht das ganze so 2:20-2:25.
Müsste die CPU nicht eigentlich doch etwas langsamer sein, als ein K8 ?
Die Designunterschiede bei 32-bit sind so gering dass ein gleich getakteter K7 nicht wirklich langsamer als ein K8 ist, solange die bessere Speicheranbindung nicht ins Spiel kommt.
lg
__tom
Hat das mal jemand mit einem VIA Prozessor ausprobiert?
Aus:
http://boinc.bio.wzw.tum.de/boincsimap/forum/viewtopic.php?t=516&start=15
Ja, so wie es aussieht sind wir recht dicht an einer Loesung -
bzw. erste Tests mit einer Loesung sehen sehr vielversprechend aus...
Im besten Fall gibts dazu dann morgen schon die neue Version,
wenn noch Probleme auftauchen wird die noch ein bisschen auf sich warten lassen...
Aber zumindest die Probelaeufe fuer die Patches sehen fuer die AMDs wesentlich besser aus als alles was wir vorher mit Compiler-Optionen und Compilern allgemein erreichen konnten...
Soweit
-Jonathan
Frage mich nur wieso angeblich der L2 daran Schuld sein soll, unter Linux ist der ja auch nicht größer ...
Naja Hauptsache das Problem wird/wurde behoben :)
ciao
Alex
Ich hab die jetzt bei mir unter Windows auf meinem Opteron @2,2 GHz rechnen lassen und komme dabei leider auf 2m10s. :( So, hmmer 5.09 ist draussen, jetzt braucht mein Opteron 1m40s. Noch nicht optimal, aber besser als nichts :)
Falls noch jemand testen will, aber die 5.09er noch nicht hat, download hier:
http://boinc.bio.wzw.tum.de/boincsimap/download/hmmer_5.09_windows_intelx86.exe
Für die Leute, die Ihre Caches noch voll haben und die Editierarbeit nicht scheuen, noch der Tipp, dass man auch alte 5.08er mit der 5.09er rechnen lassen kann, analog zu meinem alten Tipp beim 5.04->5.05 Übergang:
http://www.planet3dnow.de/vbulletin/showpost.php?p=2885414&postcount=61
Laut Simap thread hier (http://boinc.bio.wzw.tum.de/boincsimap/forum/viewtopic.php?t=507&start=90) profitieren davon auch alte Pentium4 und P3, es lohnt sich also auch damit. Neuere P4s profitieren im einstelligen Prozentbereich.
ciao
Alex
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.