extrem optimierte Seti App für SSE2 und SSE3 CPUs

AndyK

Vice Admiral Special
Mitglied seit
07.01.2006
Beiträge
758
Renomée
18
Akosf, schon bekannt für seine handoptimierten Einstein@Home Apps, hat sich auch mal die von Crunch3r optimierte Seti App zur Brust genommen...

SETI has some very good optimised code.
I spent an afternoon to optimise it, and I could get just 10% improvement. (Crunch3r's Athlon XP SSE 2.09)
You mean, you had squeezed out another 10% out of a binary from Crunch3r? *wow*
Can I download that modified binary somewhere ;) ? Ten percent better is a good reason for me to try it :))
I upload to here. It was optimised to Duron (64+64kB cache), so don't rely on better time on other processors.
But, I think it will catch up the SSE3 code on A64 and P4.
Raistmer schrieb:
Message 29083 - Posted 28 Mar 2006 20:25:24 UTC
Some words about seti_K78 for SETI.
I upgraded 4 comps to this verion - 2 Athlon 64 with SSE2/SSE3 support - it seems seti_K78 faster than Crunch3r's dedicated verions for SSE2/SSE3 - very cool :)

Also..... Er hat die Anwendung eigentlich nur für SSE CPUs (Duron) ausgelegt. Auf Duron funktioniert es auch.
Auf AMD XP Prozessoren kommt es aber zu einem Absturz der App und innerhalb von zwei Sekunden sind alle Workunits mit Fehlern abgebrochen worden.
Auf AMD 64 (oder auch Intel) CPUs mit SSE2 oder SSE3 läuft diese App aber ohne Probleme und validiert die Results auch.

Dennoch wie immer: Vorher Backup vom BOINC Verzeichnis machen!!!

AndyK
 
Zuletzt bearbeitet:
Du beziehst Dich dabei aber auf die Einstein App, oder?

Schon die Seti App ausprobiert?

AndyK
 
Du beziehst Dich dabei aber auf die Einstein App, oder?

Schon die Seti App ausprobiert?

AndyK

Würde es probieren wollen aber der Link funktioniert leider nicht mehr.
Habt ihr noch einen anderen *noahnung*

Interessiert mich schon, ob mein A64 noch schneller kann, derzeit braucht er im Schnitt 39 Minuten ;D
 
hi!!

Kann es sein das sich die Zeiten immer weiter verschlechtern?

Hatte sonst ~35mins eine Wu jetzt sinds derweile schon 50mins.

wader
 
Würde es probieren wollen aber der Link funktioniert leider nicht mehr.
Habt ihr noch einen anderen *noahnung*

Interessiert mich schon, ob mein A64 noch schneller kann, derzeit braucht er im Schnitt 39 Minuten ;D
Ich habe ihn noch, aber bei mir ist er auf einem Pentium III-M, der mit Crunch3rs SSE-Version einwandfrei läuft, abgeschmiert. Eigentlich soll er auf der SSE-Version von Crunch3r basieren.

Also auf eigene Gefahr!
 
mal zur Info

wieso sollte dieser Client schneller als die Version von Crunch sein, er setzt die original Imhell Compiler ein, und auch alles was dazugehört...

und Akosf patched doch nur die Seti Apps...

werde sowas bei mir nicht installieren...

bei Crunch seiner Version weiss mann wo man ist, aber bei dieser Version...

mfg
Sir Ulli
 
Akos macht reverse engeneiring, so kommt er von einer exe wieder auf Quellcode.
Ob er durch die pdb Dateien wieder zu einem Hochsprachenquellcode (C++) kommt, oder alles in Assembler ausgespuckt bekommt weiss ich nicht.
Vermute aber mal Assembler, da er gerne auch HexPatches verwendet. ;)

Dann sucht er nach den Berechnungsroutinen und optimiert die, durch Assembler SSE/3DNow! Optimierungen, bzw. packt auch noch neue Algorhytmen in den Code, um den noch weiter zu beschleunigen.
Und was schnelleres als Assembler gibts nun mal nicht! ;D

AndyK
 
Akos macht reverse engeneiring, so kommt er von einer exe wieder auf Quellcode.
Ob er durch die pdb Dateien wieder zu einem Hochsprachenquellcode (C++) kommt, oder alles in Assembler ausgespuckt bekommt weiss ich nicht.
Vermute aber mal Assembler, da er gerne auch HexPatches verwendet. ;)

Dann sucht er nach den Berechnungsroutinen und optimiert die, durch Assembler SSE/3DNow! Optimierungen, bzw. packt auch noch neue Algorhytmen in den Code, um den noch weiter zu beschleunigen.
Und was schnelleres als Assembler gibts nun mal nicht! ;D

AndyK

ich weiss schon was reverse engeneiring bedeuted, aber wie schon gesagt vertraue ich lieber auf verlässlichen Qiuellen....

mfg
Sir Ulli
 
hi!!

Kann es sein das sich die Zeiten immer weiter verschlechtern?

Hatte sonst ~35mins eine Wu jetzt sinds derweile schon 50mins.

wader
Ja, das ist so.

@AndyK:

Gibt's dazu nun einen Link? Wäre ja mal auszuprobiren.
 
Ich habe ihn noch, aber bei mir ist er auf einem Pentium III-M, der mit Crunch3rs SSE-Version einwandfrei läuft, abgeschmiert. Eigentlich soll er auf der SSE-Version von Crunch3r basieren.

Also auf eigene Gefahr!

Also ich hab die app mal auf meinem A64 getestet und ihn dann nach drei Stunden wieder runter geschmissen.
Das Verhalten war etwas merkwürdig, sprang ziemlich schnell auf 50% fertig und crunchte dann ewig weiter und der Output war definitiv geringer als mit dem app von Crunch3r.

Und ich kann derzeit keinen Einbruch beim RAC gebrauchen ;D
 
Ja, das ist so.

@AndyK:

Gibt's dazu nun einen Link? Wäre ja mal auszuprobiren.

Hier ist die Seti_K78
Die seti_k78b findest Du etwas weiter oben im Post von UliBär.

Bei der k78b hat akosf versucht die App zum AMD XP (SSE) kompatibel zu machen, was aber wohl nicht so ganz funktioniert hat.
Da Akosf nicht sonderlich an seti interessiert ist, hat er auch kein weiteres Interesse den/die Fehler zu suchen und eine weitere Version herauszubringen.
Wie schon gesagt: Backup vorher machen!! Und vielleicht auch den Netzwerkverkehr unterbinden, damit wenns nicht funktionieren sollte die abgebrochenen WUs nicht als Fehler zurückgemeldet werden.

Auf meinem AMD64 3000+ hab ich eine durchschnittliche Verbesserung von knapp 3 Minuten, auf dem P4 3,2Ghz HT von meinem Vater ca. 6 Minuten schneller pro WU.

AndyK
 
Hier ist die Seti_K78
Die seti_k78b findest Du etwas weiter oben im Post von UliBär.

Bei der k78b hat akosf versucht die App zum AMD XP (SSE) kompatibel zu machen, was aber wohl nicht so ganz funktioniert hat.
Da Akosf nicht sonderlich an seti interessiert ist, hat er auch kein weiteres Interesse den/die Fehler zu suchen und eine weitere Version herauszubringen.
Wie schon gesagt: Backup vorher machen!! Und vielleicht auch den Netzwerkverkehr unterbinden, damit wenns nicht funktionieren sollte die abgebrochenen WUs nicht als Fehler zurückgemeldet werden.

Auf meinem AMD64 3000+ hab ich eine durchschnittliche Verbesserung von knapp 3 Minuten, auf dem P4 3,2Ghz HT von meinem Vater ca. 6 Minuten schneller pro WU.

AndyK

OK, mit einer für den XP optimierten Version kanns natürlich Probleme geben.
Also auf ein neues ;)

Blöde Frage ..... die*.pdb schmeiß ich raus oder *noahnung*
 
Zuletzt bearbeitet:
Hallo,

ich hab mir jetzt mal den Spaß gemacht und hab das selber mal getestet.

CPU: A64 3200+ @ 2.2 GHz 1MB cache
WU: Joe Segurs quick Reference WU

Akosf app.
<wu_cpu_time>59.609375</wu_cpu_time>

meine app.
<wu_cpu_time>59.546875</wu_cpu_time>

Also alles in allem null effekt *noahnung*
 
Auf meinem AMD64 3000+ hab ich eine durchschnittliche Verbesserung von knapp 3 Minuten, auf dem P4 3,2Ghz HT von meinem Vater ca. 6 Minuten schneller pro WU.

Solche "Verbesserungen" sind definitiv innerhalb der "Messtoleranz". :]

Ich habe im moment auch SETI Wu`s die statt 1 Stunde,"nur" 54 Minuten im Durchschnitt laufen.
So hat die Crunch3r App auf Wundersame Weise 6 Minuten (!!) zugelegt *suspect*

Also. Solche "Test`s" müssen und können nur langfristig zeigen ob sich tatsächlich was getan hat.
Um es nun mit den worten des Heise Forum`s zum abschluss zu bringen:

"Ich vertraue weiterhin......den bewährten Marken Produkten des Marktführers "©Crunch3r ®&#8482;"

:]
 
Akos macht reverse engeneiring, so kommt er von einer exe wieder auf Quellcode.
Ob er durch die pdb Dateien wieder zu einem Hochsprachenquellcode (C++) kommt, oder alles in Assembler ausgespuckt bekommt weiss ich nicht.
Vermute aber mal Assembler, da er gerne auch HexPatches verwendet. ;)

Das Resultat ist Assembler-Code. In eine Hochsprache bekommt man sowas nicht wieder, schon garnicht bei C++, wo exzessiv mit Templates gearbeitet wird.

Dann sucht er nach den Berechnungsroutinen und optimiert die, durch Assembler SSE/3DNow! Optimierungen, bzw. packt auch noch neue Algorhytmen in den Code, um den noch weiter zu beschleunigen.
Und was schnelleres als Assembler gibts nun mal nicht! ;D

Grundsätzlich sagt mir das ganze, das der Gutste nicht wirklich weiß, was er da macht. Wenn man schon den Quellcode hat, sollte man an dem ansetzen, um zu optimieren. Reverse Engineering ist nur dann Mittel zum Zweck, wenn man den Code nicht hat. Wenn man aber Zugriff auf den Quellcode hat, wie bei SETI, dann sollte man dort direkt die Algorithmen optimieren. Eine Grundregel beim Programmieren lautet, versuche nie schlauer zu sein, als der Compiler. Genau das versucht Akos, und sowas geht meistens in die Hose. Schon einzelne Bereiche mit inline assembler sind problematisch. Bei größeren Codebereichen verliert ein Programmierer sehr schnell den Überblick.
 
Moin Cheeky *bye2*
Schön mal wieder was von Dir zu hören.

Ich muss ja zugeben, dass mein AMP XP mit Crunch3rs optimierter App auch vereinzelte Ergebnisse hat, die nicht ihre 2:07 brauchen sondern nur 1:57, aber der Schnitt hat sich nicht sonderlich verändert.
Da einige Results aus Berkeley zur Zeit aber eh ein wenig anormal sind, muss ich Euch soweit Recht geben und die Verbesserung relativieren.
Auf meinem AMD64 hab ich auch wieder Crunch3rs App laufen, da sich keine wirklich messbare Verbesserung einstellte.
Die Zeiten auf dem P4 werde ich im Auge behalten und bei Gelegenheit hier posten, ob sich doch was getan hat...

AndyK
 
Also ich hab auch wieder die app von Crunch3r laufen.
Ich konnte keine Verbesserung feststellen und die Merkwürdigkeiten bei der %-Anzeige bzgl. der Fertigstellung hat auch die nicht Athlon XP optimierte Version gezeigt.

Die app von Crunch3r ist auf jeden fall die bessere Wahl.
Wenn er sie jetzt noch besser an den AMD Opteron anpassen könnte, wäre ich überglücklich ;D
 
Schön mal wieder was von Dir zu hören.

Moin Andy.
Allerdings!
verliebt041.gif


Die Zeiten auf dem P4 werde ich im Auge behalten und bei Gelegenheit hier posten, ob sich doch was getan hat..

Wir sind gespannt :)



(Bis dahin natürlich weiterhin Crunch3r&#8482; *fg* ;D )
 
Zurück
Oben Unten