Infernal 1.1

[Norman]

die entgültige release version 1.1 [24 October 2013] ist ja schon etwas draußen.
werden wir bald ein paar test-WU dieser version bereitstellen und wieviel schneller ist diese version tatsächlich.

Norman

[Michael H.W. Weber]

Die durchschnittlich 100-fache Geschwindigkeitszunahme nehme ich den Entwicklern durchaus ab - sie haben genug Material, um statistisch signifikante Aussagen diesbezüglich zu treffen.
Hinzu kommt, dass es mittlerweile unabhängig entwickelte FPGAs gibt, die nochmal den Faktor 2 drauf legen - also unterm Strich 200-fach schneller rechnen, als unsere aktuelle Version.

Was die RNA World Entwicklungen betrifft, so werden wir uns jetzt erst einmal darauf konzentrieren, dass wir das Checkpointing vollkommen wasserdicht am Start haben.
Anschließend sollen die zum Teil schon funktionellen Job Submission Interfaces komplettiert werden.
Wenn das beides läuft, möchte ich gerne die zusätzliche Implementierung der neuen Version angegangen sehen. Zusätzlich deshalb, weil wir parallel zu den Entwicklungsarbeiten eine laufende Plattform brauchen - es gibt wieder massenhaft Arbeit demnächst - und beide Versionen unterscheiden sich nach meinem Kenntnisstand lediglich in der Recheneffizienz (und einigen funktionalen Verbesserungen, wie die Behebung der "multi threading"-Problematik im DC-Umgebungen), nicht aber in den wissenschaftlichen Inhalten.

Noch dieses Jahr werden wir voraussichtlich einen weiteren RNA World Server an den Start schicken. Und zwar den im Rahmen des diesjährigen Thomas Krenn Open Source Contests gewonnenen (gut, dass wir in Berlin waren!). Standort wird erstmals Marburg sein. Sollte das alles laufen, kann evt. auch darüber nachgedacht werden, andere Serverhardware umzuziehen.

Ich bin derweil hier vor Ort dabei, GROMACS, AutoDock und Rosetta inhaltlich zu verstehen, damit wir auch im Bereich Molecular Dynamics, Docking und ab initio Strukturvorhersage aktiv werden können.
Ich denke, 2014 wird in Sachen RNA World Projektentwicklung spannend werden...

Michael.

[Norman]

mmh, da stellt sich mir die frage, daß wenn die neue version so schnell ist und ich statt 100 tage nur 1 tag für eine intron benötige,
warum diese version nicht einfach eingespielt wird um ordentlich arbeit weg zu putzen und derweil in ruhe an den anderen "baustellen" geschraubt wird.
oder verstehe ich da was falsch ?

Norman

[bbmz]

Vielen Dank für die Informationen zu MT - schön zu hören, dass MT noch nicht vollkommen aufgegeben wurde.

Ob solche MT-WUs auch Checkpinting betreiben können, ist eine weitere Frage. Allerdings ist diese für uns insofern zumindest vorläufig sekundär, als die neue Version in den Standardanwendungen ohenhin eine ca. 100-fache Geschwindigkeitserhöhung zur Folge haben wird (die meisten XXL WUs sind keine Standardparametrisierungen!).

Von welcher Beschleunigung sprechen wir denn ca. bei den XXLs? Erscheint es realistisch, dass die Rechenzeit unter 7 Tage fallen wird?

Die Science-Apps, die wir nutzen, liegen inzwischen aber in einer Version vor, die auf Basis unserer Rückmeldungen an den Originalentwickler MT erlaubt. Wir hatten zudem in einem "stand-alone" Ansatz mit den aktuellen Apps getestet, dass MT tatsächlich zumindest für einzelne Apps skaliert. Will heissen, dass konkret gesprochen 4 CMCALIBRATE WUs unter MT-Einsatz schneller fertig sind, als diese 4 WUs beim jetzigen ST-Ansatz. Für CMSEARCH scheint das allerdings nicht der Fall zu sein.

Dort wo keine Skalierung greift, ist es hinsichtlich Rechenleistung/Watt definitiv nicht sinnvoll, MT einzusetzen (man würde mehr Strom investieren für dasselbe Ergebnis). Es kann dennoch Sinn in anderer Hinsicht machen, wenn man beispielsweise eine extrem lange Rechenaufgabe auf einem Quadcore-System einfach mal in einem guten Vierteljahr statt in einem Jahr abgeliefert haben möchte und dafür bereit ist, etwas mehr Strom zu investieren.

Was bedeutet denn schlecht skalieren - 4 Kerne erledigen Arbeit von Zweien, oder eher 4:3? Ich kann für mich nur mitteilen, dass ich MT als mindestens genauso wichtig wie Checkpointing erachte, weil sich die Berechnungszeit wesentlich verkürzen ließe. Wenn ich so an die ganzen fehlerhaften Aufgaben denke, die trotz eines absolut stabil laufenden PCs entstanden sind, weil entweder die Internetverbindung zusammengebrochen ist, andere Programme BOINC zum Absturz gebracht haben, eine defekte WU die Anderen (noch laufenden) ebenfalls beendet hat, ? dann hätte sich ein großer Teil davon durch MT und daraus resultierend kürzeren Laufzeiten retten lassen, weil die Aufgaben bereits fertig gewesen wären. Aus meiner Sicht würde durch die kürzere Laufzeit die Chance diese fehlerfrei zu beenden wesentlich ansteigen. Ich würde jedenfalls ohne zu zögern, auch bei einer schlechten Skalierung von 1:2, die MT-Variante wählen, wenn ich die Wahl hätte ?

Nebenbei würden sich auch bei HDD und RAM evtl. weniger Probleme ergeben, weil sich nicht mehr mehrere Aufgaben die Ressourcen teilen müssten.

Ob solche MT-WUs auch Checkpinting betreiben können, ist eine weitere Frage. Allerdings ist diese für uns insofern zumindest vorläufig sekundär, als die neue Version in den Standardanwendungen ohenhin eine ca. 100-fache Geschwindigkeitserhöhung zur Folge haben wird (die meisten XXL WUs sind keine Standardparametrisierungen!).

Warum sollte sich MT dort von ST unterscheiden? Prinzipiell ist es doch kein Problem auch mehrere Kerne an eine VM durchzureichen. Evtl. sollte in diesem Zug nur darüber nachgedacht werden, dass man diese Anzahl vielleicht der Sicherheit halber manuell mittels Datei im RNA-Datenverzeichnis angeben muss, damit nicht BOINC wegen fehlerhafter Einstellungen plötzlich alle Kerne an die VM weiterreicht und das OS leer ausgeht.

BOINC sollte was MT angeht eigentlich recht wenig Probleme machen, da MT bereits vor Jahren ohne nennenswerte Probleme bei AQUA@home lief; auch bei BURP wird derzeit teilweise MT eingesetzt. Dass Einzige was sich in diesem Zusammenhang häufiger mal als problematisch erwiesen hat war, die Anzahl der belegten Kerne festzulegen bzw. einzuschränken oder dafür zu sorgen, dass Aufgaben anderer Projekte nicht starten und damit die Anzahl der verfügbaren Kerne unter die Anzahl der angeforderten Kerne rutscht.



P.S.: Mein gesamter Beitrag bezieht sich auf die XXL-WUs bzw. WUs mit Laufzeiten von 10 bis 20 (und mehr) Stunden. Dass bei WUs mit Rechenzeiten unter 5 Stunden eine weitere Verkürzung mittels MT keinen wirklichen Vorteil (außer Nachteilen aus der Skalierung) bringt, ist mir bewusst.

[Michael H.W. Weber]

mmh, da stellt sich mir die frage, daß wenn die neue version so schnell ist und ich statt 100 tage nur 1 tag für eine intron benötige,
warum diese version nicht einfach eingespielt wird um ordentlich arbeit weg zu putzen und derweil in ruhe an den anderen "baustellen" geschraubt wird.
oder verstehe ich da was falsch?

Ja, da verstehst Du etwas falsch. Erstens ist die finale Version von Infernal erst seit kurzer Zeit fertig. Zweitens - und das ist der springende Punkt, den ich oben aber schon erwähnte - sind die laufenden WUs von mir mit Spezialparametern versehen, die die Filteralgorithmen abschalten. Gerade diese aber sind meines Wissens Kern der verbesserten Beschleunigung in der neuen Version. Will heißen, egal welche Version wir einsetzen, die Laufzeiten würden bei diesen WUs nach meinem Kenntnisstand auch in der neuen Version nicht beschleunigt.

Da wir auch in Zukunft solche Parameter zusätzlich zu den Voreinstellungen analysieren werden, wird es auch in der neuen Infernal Version XXL Monster-WUs geben. Das Abschalten der Filter hat zur Folge, das Dinge gefunden werden, die wir mit aktivierten Filtern sonst erfahrungsgemäß übersehen.

Michael.

[Michael H.W. Weber]

Von welcher Beschleunigung sprechen wir denn ca. bei den XXLs? Erscheint es realistisch, dass die Rechenzeit unter 7 Tage fallen wird?

OK, nochmal etwas ausführlicher.
Es gibt zwei Sorten XXL WUs: Die einen sind solche, die mit Standardparametern laufen (Filtermechanismen aktiviert), aber sehr komplexe Rechnungen darstellen, d.h. große Genome und große (bzw. komplex strukturierte) RNAs enthalten. Diese werden in der neuen Version - auch ohne MT (!) - ca. 100-fach beschleunigt.
Die andere Sorte ist die, die ich oben schon erwähnte: Sie enthalten letztlich dieselbe Aufgabe, aber in einer Weise gesteuert, dass die Filtermechanismen nicht greifen. Deren Laufzeiten dürften sich daher nicht verkürzen - weshalb wir auch bei der neuen Version trotz der massiven Beschleunigung bei Standardaufgaben unbedingt das Checkpointing brauchen.

Was bedeutet denn schlecht skalieren - 4 Kerne erledigen Arbeit von Zweien, oder eher 4:3?

Hier mal ein konkretes Beispiel aus unserem Labor:

Code: Alles auswählen

OpenMPI: searching DsrA in M. tuberculosis on a Quad-Opteron/2.6 GHz/Linux-32:
------------------------------------------------------------------------------
# of cores: 1, total actual time for CMCALIBRATE: 02:18:27, CMSEARCH: 00:28:08
# of cores: 2, total actual time for CMCALIBRATE: 01:33:18, CMSEARCH: 00:28:08 
# of cores: 3, total actual time for CMCALIBRATE: 00:39:50, CMSEARCH: 00:14:05 
# of cores: 4, total actual time for CMCALIBRATE: 00:26:45, CMSEARCH: 00:09:41

Wie man sieht skaliert CMCALIBRATE, CMSEARCH hingegen nicht.

Ich kann für mich nur mitteilen, dass ich MT als mindestens genauso wichtig wie Checkpointing erachte, weil sich die Berechnungszeit wesentlich verkürzen ließe.

So ist es.

Wenn ich so an die ganzen fehlerhaften Aufgaben denke, die trotz eines absolut stabil laufenden PCs entstanden sind, weil entweder die Internetverbindung zusammengebrochen ist, andere Programme BOINC zum Absturz gebracht haben, eine defekte WU die Anderen (noch laufenden) ebenfalls beendet hat, ? dann hätte sich ein großer Teil davon durch MT und daraus resultierend kürzeren Laufzeiten retten lassen, weil die Aufgaben bereits fertig gewesen wären. Aus meiner Sicht würde durch die kürzere Laufzeit die Chance diese fehlerfrei zu beenden wesentlich ansteigen.

Ich verstehe die Argumentation, aber eigentlich muss das Checkpointing bei völlig korrektem Verhalten genau dieses Problem lösen, nicht die Verkürzung der Laufzeit.

Ich würde jedenfalls ohne zu zögern, auch bei einer schlechten Skalierung von 1:2, die MT-Variante wählen, wenn ich die Wahl hätte ?

...was uns darin bestärkt, es verfügbar zu machen.

Nebenbei würden sich auch bei HDD und RAM evtl. weniger Probleme ergeben, weil sich nicht mehr mehrere Aufgaben die Ressourcen teilen müssten.

Bezüglich des RAM-Bedarfs wird in der Zukunft ohnehin einiges leichter werden, da die neue Infernal-Version pro WU nur 2 GB RAM benötigt - egal wie komplex die Aufgabe ist. So jedenfalls teilte es mir der Entwickler mit. Wie das erreicht werden konnte, ist mir unklar, allerdings ist der Code wohl auch komplett überarbeitet worden...

Warum sollte sich MT dort von ST unterscheiden? Prinzipiell ist es doch kein Problem auch mehrere Kerne an eine VM durchzureichen.

Nun, es sieht in der Praxis ja nun mal so aus, dass andere Projekte angeblich den Versuch aufgegeben haben MT unter BOINC zu nutzen. Die Hintergründe dafür sind mir allerdings nicht ausreichend bekannt. Da würde uns eine genaue Recherche helfen.

Michael.

[Beorn]

Hier mal ein konkretes Beispiel aus unserem Labor:

Code: Alles auswählen

OpenMPI: searching DsrA in M. tuberculosis on a Quad-Opteron/2.6 GHz/Linux-32:
------------------------------------------------------------------------------
# of cores: 1, total actual time for CMCALIBRATE: 02:18:27, CMSEARCH: 00:28:08
# of cores: 2, total actual time for CMCALIBRATE: 01:33:18, CMSEARCH: 00:28:08 
# of cores: 3, total actual time for CMCALIBRATE: 00:39:50, CMSEARCH: 00:14:05 
# of cores: 4, total actual time for CMCALIBRATE: 00:26:45, CMSEARCH: 00:09:41

Wie man sieht skaliert CMCALIBRATE, CMSEARCH hingegen nicht.

Ist das ein Opteron der aktuellen Generation? Also 'Bulldozer'-ähnliche Architektur mit 'Core Multithreading' (= Module mit zwei Integerkernen und einer gemeinsam genutzten 256bit FPU)? Die Skalierung bei 2 oder 3 Kernen ist frappierend unterschiedlich und hier skaliert CMSEARCH nach den genannten Werten durchaus. Bei CMCALIBRATE ist die Skalierung bei 3 und 4 Kernen sogar besser als eigentlich im optimalen Fall zu erwarten (?!), wenn ich mich nicht verrechnet habe (29% statt 33% und 19% statt 25%).

Ich würde jedenfalls ohne zu zögern, auch bei einer schlechten Skalierung von 1:2, die MT-Variante wählen, wenn ich die Wahl hätte ?

...was uns darin bestärkt, es verfügbar zu machen.

Der übliche BOINC-User mag das etwas anders sehen und es durchaus kritisch beäugen wenn sein Mehrkerner nur suboptimal ausgenutzt wird. Nicht falsch verstehen, nach dem was ich hier lese halte ich eine MT-Version für sehr sinnvoll (und spannend), aber es könnte Kritik geben. Ich jedenfalls würde auch sagen: bring 'em on.

Nun, es sieht in der Praxis ja nun mal so aus, dass andere Projekte angeblich den Versuch aufgegeben haben MT unter BOINC zu nutzen. Die Hintergründe dafür sind mir allerdings nicht ausreichend bekannt. Da würde uns eine genaue Recherche helfen.

Milkyway@home bietet für eines der Unterprojekte eine MT-Version an. Diese lastet die CPU insgesamt aber nur zu 60 bis 80% aus und bringt regelmäßig das Scheduling von anderen parallel laufenden CPU-Projekten durcheinander... also von der Userseite aus nicht so prickelnd. Und wenn ich mich an AQUA früher erinnere war das da auch nicht anders.

Gruß

[Michael H.W. Weber]

Hier mal ein konkretes Beispiel aus unserem Labor:

Code: Alles auswählen

OpenMPI: searching DsrA in M. tuberculosis on a Quad-Opteron/2.6 GHz/Linux-32:
------------------------------------------------------------------------------
# of cores: 1, total actual time for CMCALIBRATE: 02:18:27, CMSEARCH: 00:28:08
# of cores: 2, total actual time for CMCALIBRATE: 01:33:18, CMSEARCH: 00:28:08 
# of cores: 3, total actual time for CMCALIBRATE: 00:39:50, CMSEARCH: 00:14:05 
# of cores: 4, total actual time for CMCALIBRATE: 00:26:45, CMSEARCH: 00:09:41

Wie man sieht skaliert CMCALIBRATE, CMSEARCH hingegen nicht.

Ist das ein Opteron der aktuellen Generation?

Das wurde im September 2009 von uns vermessen.

Bei CMCALIBRATE ist die Skalierung bei 3 und 4 Kernen sogar besser als eigentlich im optimalen Fall zu erwarten (?!), wenn ich mich nicht verrechnet habe (29% statt 33% und 19% statt 25%).

Ja. So etwas gibt es und es läßt sich auch technisch erklären.

Der übliche BOINC-User mag das etwas anders sehen und es durchaus kritisch beäugen wenn sein Mehrkerner nur suboptimal ausgenutzt wird. Nicht falsch verstehen, nach dem was ich hier lese halte ich eine MT-Version für sehr sinnvoll (und spannend), aber es könnte Kritik geben. Ich jedenfalls würde auch sagen: bring 'em on.

Ja sicher. Die Kritik wird von unseren Stats-Freunden kommen...

Michael.

[bbmz]

Vorab: Vielen Dank für die ausführlichen Informationen! Nur selten erhält man als Nutzer so ausführliche Informationen von Projekt-Seite.

Hier mal ein konkretes Beispiel aus unserem Labor:

Code: Alles auswählen

OpenMPI: searching DsrA in M. tuberculosis on a Quad-Opteron/2.6 GHz/Linux-32:
------------------------------------------------------------------------------
# of cores: 1, total actual time for CMCALIBRATE: 02:18:27, CMSEARCH: 00:28:08
# of cores: 2, total actual time for CMCALIBRATE: 01:33:18, CMSEARCH: 00:28:08 
# of cores: 3, total actual time for CMCALIBRATE: 00:39:50, CMSEARCH: 00:14:05 
# of cores: 4, total actual time for CMCALIBRATE: 00:26:45, CMSEARCH: 00:09:41

Wie man sieht skaliert CMCALIBRATE, CMSEARCH hingegen nicht.

Ist das ein Opteron der aktuellen Generation?

Das wurde im September 2009 von uns vermessen.

Bei CMCALIBRATE ist die Skalierung bei 3 und 4 Kernen sogar besser als eigentlich im optimalen Fall zu erwarten (?!), wenn ich mich nicht verrechnet habe (29% statt 33% und 19% statt 25%).

Ja. So etwas gibt es und es läßt sich auch technisch erklären.

Dass CMSEARCH nicht skaliert, halte ich angesichts der Daten für eine sehr gewagte Aussage - um nicht zu sagen: ich finde die Quote von 09:41 Minuten statt idealer 07:02 Minuten nicht sonderlich schlecht. Ich habe schon deutlich schlechtere Skalierungen gesehen ? (von meinem Eindruck her dürfte die bereits erwähnte Milkyway-Anwendung auch nicht besser sein, was die geringe Auslastung ja bereits andeutet).
Zumal Skalierung teilweise auch sehr plattformabhängig sein kann. Es ist ja schon derzeit so, dass zwischen Intel und AMD ein deutlicher Laufzeitunterschied auftritt. Dass bei einem Opteron keine "schöne" Skalierung auftritt muss bspw. nicht unbedingt heißen, dass bei Intel ebenfalls keine Skalierung auftritt (kann aber natürlich ?).

Rein aus Interesse: Wie sieht es den bei mehr als 4 Kernen aus? Existieren da Versuchsdaten?

Mit dem Problem der MT-Wus und Wus anderer Projekte: An das Problem erinnere ich mich auch, neben dem Problem der Festlegung der Anzahl der benutzten Kerne. Ich würde aber behaupten, dass das Problem nicht von so großer Bedeutung ist. Bei den kurzen Wus von RNAWorld würde das Problem (wegen fehlendem MT) nicht auftreten, sodass jeder der zwingend mehrere Projekte parallel berechnen will, auf diese ausweichen könnte. Bei den XXL-Wus ist auch derzeit schon ein Auge auf mehrere parallel laufende Projekte zu richten, weil auch bei hoher Priorität ja so manches WU-Chaos angerichtet wird, sodass ein Großteil der XXL-WU-Rechner wahrscheinlich das Problem kennt bzw. sowieso nur ein Projekt zeitgleich rechnet.
Falls MT auch für große Kernanzahlen umgesetzt wird, löst sich das Problem sowieso in Luft auf, weil die komplette Maschine mit der einer WU und daraus folgend einem Projekt beschäftigt wäre ?
Wer das nicht will, würde den Vorteil der kurzen Laufzeit der MT-Anwendung sowieso nicht ausnutzen und hätte mit den "normalen" Wus eh eine Alternative.

[Michael H.W. Weber]

Vorab: Vielen Dank für die ausführlichen Informationen! Nur selten erhält man als Nutzer so ausführliche Informationen von Projekt-Seite.

Jederzeit gerne wieder.

Dass CMSEARCH nicht skaliert, halte ich angesichts der Daten für eine sehr gewagte Aussage - um nicht zu sagen: ich finde die Quote von 09:41 Minuten statt idealer 07:02 Minuten nicht sonderlich schlecht. Ich habe schon deutlich schlechtere Skalierungen gesehen ? (von meinem Eindruck her dürfte die bereits erwähnte Milkyway-Anwendung auch nicht besser sein, was die geringe Auslastung ja bereits andeutet).

Nun, ich hatte oben ja schon angedeutet, was ich formal unter skalieren verstehe: Dass beim Einsatz von 4x MT (auf vier Kernen) nämlich keine Energie mehr verbraucht wird, als bei 4x ST (auf einem Kern). Dass man auch mit weniger glücklich sein kann, ist sicherlich einzusehen. Insbesondere, wenn Zeit eine Rolle spielt. Aber das hatten wir oben ja schon "seziert".

Zumal Skalierung teilweise auch sehr plattformabhängig sein kann. Es ist ja schon derzeit so, dass zwischen Intel und AMD ein deutlicher Laufzeitunterschied auftritt. Dass bei einem Opteron keine "schöne" Skalierung auftritt muss bspw. nicht unbedingt heißen, dass bei Intel ebenfalls keine Skalierung auftritt (kann aber natürlich ?).

Da möchte ich keineswegs widersprechen.
Wir haben allerdings bislang nur Daten für AMD vorliegen und da ich mich hier bemühen möchte nur über Dinge zu sprechen, die wasserdicht sind, beziehe ich mich hier auch nur auf die Messungen, die wir selbst duchgeführt haben.

Rein aus Interesse: Wie sieht es den bei mehr als 4 Kernen aus? Existieren da Versuchsdaten?

Nein, noch nicht.

Mit dem Problem der MT-Wus und Wus anderer Projekte: An das Problem erinnere ich mich auch, neben dem Problem der Festlegung der Anzahl der benutzten Kerne. Ich würde aber behaupten, dass das Problem nicht von so großer Bedeutung ist. Bei den kurzen Wus von RNAWorld würde das Problem (wegen fehlendem MT) nicht auftreten, sodass jeder der zwingend mehrere Projekte parallel berechnen will, auf diese ausweichen könnte. Bei den XXL-Wus ist auch derzeit schon ein Auge auf mehrere parallel laufende Projekte zu richten, weil auch bei hoher Priorität ja so manches WU-Chaos angerichtet wird, sodass ein Großteil der XXL-WU-Rechner wahrscheinlich das Problem kennt bzw. sowieso nur ein Projekt zeitgleich rechnet.
Falls MT auch für große Kernanzahlen umgesetzt wird, löst sich das Problem sowieso in Luft auf, weil die komplette Maschine mit der einer WU und daraus folgend einem Projekt beschäftigt wäre ?
Wer das nicht will, würde den Vorteil der kurzen Laufzeit der MT-Anwendung sowieso nicht ausnutzen und hätte mit den "normalen" Wus eh eine Alternative.

Tjo, das sehe ich sehr ähnlich.

Michael.

[Thomas R]

[quote=]Rein aus Interesse: Wie sieht es den bei mehr als 4 Kernen aus? Existieren da Versuchsdaten?[/quote]
[quote=]Nein, noch nicht.[/quote]

Solange ich ihn noch habe könnt ihr das gerne auf meinem testen.
Falls das möglich und nötig sein sollte.

[Michael H.W. Weber]

Danke Thomas. Aber ich habe inzwischen einen i7 Quad, sodass ich dort HT testen kann.

Michael.