Hmmer Laufzeittest auf AMD-MS Systemen, bitte mitmachen
- Ersteller Opteron
- Erstellt am
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
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 meinteinen 64 Bit Client den es noch gar nicht gibt...
http://boinc.bio.wzw.tum.de/boincsimap/appdownloads.php
hmmer gibts natürlich auch ...
Wieso es nichts für Windows gibt ...
Im einfachsten Fall, weil sie keine Plattform, i.e. Windows Lizenz zum compilieren haben
ciao
Alex
ZentrumDesChaos
Captain Special
Hi,
hab grad mal getestet
x2 4400+ @ 2,6GHz
1:46min
MfG
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:
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
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:
Code:
...
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
Admiral Special
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.
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
PHP:
/* 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;
wori
Commander
- Mitglied seit
- 06.05.2005
- Beiträge
- 161
- Renomée
- 0
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?
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
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
Admiral Special
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
Technische Administration, Dinosaurier
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
der2of6
Vice Admiral Special
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
Technische Administration, Dinosaurier
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
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Aus:
http://boinc.bio.wzw.tum.de/boincsimap/forum/viewtopic.php?t=516&start=15
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
http://boinc.bio.wzw.tum.de/boincsimap/forum/viewtopic.php?t=516&start=15
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
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
So, hmmer 5.09 ist draussen, jetzt braucht mein Opteron 1m40s. Noch nicht optimal, aber besser als nichtsIch hab die jetzt bei mir unter Windows auf meinem Opteron @2,2 GHz rechnen lassen und komme dabei leider auf 2m10s.
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 profitieren davon auch alte Pentium4 und P3, es lohnt sich also auch damit. Neuere P4s profitieren im einstelligen Prozentbereich.
ciao
Alex
