POEM

Analyse und Vorhersage von Struktur und Faltungsweg (Folding@home, GPUGRID, Rosetta@home, ...)
Nachricht
Autor
Felix2015

Re: POEM

#73 Ungelesener Beitrag von Felix2015 » 25.07.2016 13:57

Yep - das geht natürlich auch. @Kolossus handhabt das genauso meines Wissens.

Das Projekt floatet quasi über alle Core und zieht sich das Quenten am Power, wo er es dann aktuell findet.

In der Variante mit der app. Zuordnung werden die Core zugewiesen - da braucht das Projekt nichts zu suchen, wo er Rechenzeit findet.

Entscheidend ist für mich, dass ich so dauerhaft 100% gewiss (Controllfreak) Zugriff an die dann als frei definierten Core habe;
z.B. für Musik und Filme, Bildbearbeitung, Surfen und Email usw.

Es wäre ein Experiment wert, zu gucken, ob die Core-Limitierung (hier: 25%) durch das "freie floaten" aufgehoben wird über alle Cores hinweg.



Edit: Gefunden im SG-Forum ([ETA]MrSpadge am 30.6.2015)
Inzwischen hab ich bei POEM im Forum gelesen, dass die aktuelle App für AMD GCN Chips (also alles ab der 7000'er Serie) optimiert ist und dort ca. 50% Effizienz erreicht. Also 50% der theoretischen Leistung können auch praktisch genutzt werden, was ein exzellenter Wert ist. Maxwell tun diese Optimierungen auch sehr gut, trotzdem liegen diese Chips bei nur ca. 30%. Alles ältere (Kepler, Fermi, AMD VLIW) ist weit abgeschlagen. Aber zumindest wohl nicht schlechter als vor der Optimierung.

@Marcel: die app_config.xml kann man in jedem Projekt benutzen, Das ist ein Mechanismus, den BOINC selbst mitbringt. Verschiedene Projekte zugleich auf einer GPU laufen zu lassen kann man schief gehen, funktioniert aber häufig.

Ansonsten fehlt dir (soweit ich dich richtig verstehe) noch dieser Baustein: mit diiesen Angaben von "x CPU" und "y GPU" beeinflusst du in keinster Weise die App direkt. Die merkt davon gar nichts. Was du änderst ist, wie viele Ressourcen (CPUs & GPUs) BOINC für diese Aufgaben einplant und wie viele es davon startet, um die Ressourcen auszulasten.

Bei den GPUs ist das recht klar: BOINC startet so viele Aufgaben, dass die Summie der "y GPUs", die im BOINC Manager angezeigt wird, die Summe der physikalisch vorhandenen GPUs nicht übersteigt. Diese Aufgaben teilen sich die GPUs dann sehr einfach: jeder ist abwechselnd dran und kann die GPU so lange haben, wie er mag.

Bei den CPUs ist es ähnlich, mit (mindestens) 2 Unterschieden:
- das BS kann seinen Scheduler einsetzen, was deutlich besseres Multitasking mit Prioritäten etc. erlaubt
- bei z CPU-Kernen iim Rechner startet BOINC Aufgaben, so dass die Summe der zugehörigen CPU-Werte z+1 nicht übersteigt

D.h. bei 4 Kernen und 1 GPU würden bei "0.5 CPU, 0.5 GPU" für POEM insgesamt 1 CPU-Kern reserviert werden, um auf genau 1 GPU zu kommen. Damit bleiben 3 Kerne für andere Aufgaben. Da POEM@AMD nur ca. 10% eines Kerns nimmt, bleiben also 80% eines Kerns von BOINC unangetastet. Würdest du jedoch "0.3 CPUs, 0.3 GPUs" einstellen, würden 3 POEM GPU-Tasks laufen (um unter 1 GPU zu bleiben). Dazu würde BOINC jedoch 4 CPU-Tasks starten, 4+3*0.3 = 4.9 < 5.

MrS
Offenbar hat AMD bei Poem auch einen OCL-Vorteil, weil der Zugriff auf die CPU rund 10 % beträgt - und damit quasi "Core-los" (wie GPUGRID).
Das spricht auf jeden Fall für eine AMD-Karte...und ich werde mal meine Meinung dazu nochmal überdenken. :roll:

Edit 2: Lösch ich die app_config.xml bzw. setze den CPU-Wert ebenfalls auf 0,1 - dann arbeitet das System trotzdem mit 25% Core = 100% Limit.
Vielleicht kann jemand einen Vergleich machen?


Edit 3: Bei GPUGRID ist es so, dass bei meinem i5 ohne die app_config.xml die CPU-Auslastung wie gewohnt bei 0,1 ~ 0,2 % liegt; jedoch bei meinem AMD A4-4000@3.2 Ghz steigt die CPU-Auslastung auf 25%-30% (bei Duo-Core).
Also floating hin und her, ein Core zieht sich den WU und füttert ihn.
[auch beim Limit ruckelt und zuckelt nichts (nur die maximale mögliche Fütterung leidet) - solange das System insgesamt Reserven hat.
Den Task-Manager befragen).


Edit 4: Ich bin jetzt stolzer baldiger Besitzer einer HIS Radeon HD 7970!
Hoffe sehr, dass die Graka mich auch erreicht und ich die entsprechend prüfen kann.
Dann werde ich sehen, was bei Poem rum kommt.


Edit 5: Auch ohne app_config.xml ist die Auslastung bei 25% Core = 100% Limit.
Dazu noch eine Betrachtung:
Der Compi hat viele Aufgaben zu erledigen; teilweise PC-generierte Dienste im Hintergrund oder bestimmte vom User gestartete Programme / Anwendung.
Das können dann schon mal 30 - 50 - 100 task sein, die da alle auf die Computer-Rechenzeit zugreifen.
Bei mir also auf den 4-Core-CPU.
Wenn man den Dingen ihren Lauf läßt, dann organisiert das BS die jeweiligen Zugriffe entsprechend der Priorisierung, die die jeweiligen Anwendungen zugeordnet bekommen.
Ist wenig wenig Trubel im Compi dann sind alle Programme ganz relaxe.
Problematisch wird es dann, wenn etliche leistungsstarke Anwendung ihren Zugriff geltend machen.
Dann erfolgt die Rangfolge nach der Priorisierung.
Poem hat z.B. die Priorisierung "niedriger als normal".
Wenn mensch also unvernünftig ist und Videobearbeitung macht bei gleichzeitigen Crunchen und noch irgednwas leistungsfressenden, dann "knallt" es;
entweder kommt es zum einfrieren und Absturz bzw. oder die Bearbeitung wird zäh und langsam, weil die Computerzeit für jeden task nur noch verkürzt zur Verfügung steht.
Die maximale Auslastung eines task wäre dann maximal ein core.

Indem Moment wo ich eine app_config.xml anlege definiere ich bereits eine Zuordnung auf 0,5 oder 1,0 CPU wie auch immer
und habe damit vorsorglich mit dieser Einstellung eine manuelle Priorisierung vorgenommen.
Alle anderen laufenden task müssen sich jetzt noch um die verbliebenen 3 Core balgen,
während Poem priviligiert 1 Core für sich hat.
Wie gesagt: das muss man nicht machen, wenn sowieso alle task in ausreichender zeit sich die Compi-zeit (in ms) teilen.
Nur wenn es bei unvernüftigerexzessiver Nutzung verschiedener Anwendungen zum Streit um die Computerzeit geht und damit zum objektiven Reibungsverlust des optoimalen Durchsatz ist eine app_config.xml sehr hilfreich.
Hinzu kommt natürlich sowieso, wenn man mehrere WUs auf eine Graka laufen lassen will; womöglich noch von unterschiedlichen Projekten -
das regelt sich nicht von alleine.
Soweit mein Verständnis - ich lese mir gerne andere Ansichten dazu durch.

Felix2015

Re: POEM

#74 Ungelesener Beitrag von Felix2015 » 26.07.2016 09:56

Ich habe mir heute mal die Datenbank zu der Beteiligung des Team RKN am Subprojekt: Cancerpeptide angeschaut von Poem angeschaut.
Seit Oktober 2007 - und der DB-Auszug ist ziemlich groß ...
:wink:

Hier also die ersten 2000 Positionen:
Bild
Bild
:roll:
:roll:
Bild

... Fortsetzung folgt.
:wave:

Edit: @Michael, die Beteilung / crunchen an der jeweiligen Peptide-Unit ist leider nicht gleich mit eindeutige "Erfolge" - das gibt die DB nicht wirklich her.
Die DB hat einen Umfang von über 20.000 Einträge, den speziellen RKN-bezug poste ich hier nach und nach.
Aber einen entsprechenden Eintrag (sofern dieser sinnvoll erscheint?) in die Wiki trau ich mir icht zu.
Demzufolge werde am Ende diese aufbereitete Excel-Tabelle gerne jemand zusenden, der dieses machen möchte.
Zuletzt geändert von Felix2015 am 26.07.2016 13:48, insgesamt 3-mal geändert.

Benutzeravatar
Kolossus
TuX-omane
TuX-omane
Beiträge: 4277
Registriert: 26.10.2014 14:51

Re: POEM

#75 Ungelesener Beitrag von Kolossus » 26.07.2016 10:56

Felix2015 hat geschrieben:Yep - das geht natürlich auch. @Kolossus handhabt das genauso meines Wissens.

Das Projekt floatet quasi über alle Core und zieht sich das Quenten am Power, wo er es dann aktuell findet.
Genau so isses. Bei 20 Threads komme ich damit auch gut parat, da ist genügend Freiraum. Ich weiß nicht, wie das bei einem Vier-Kerner klappt, da könnte es möglicher Weise doch schon eng werden.

Im Moment sind die kürzesten Zeiten für die kleine WU 14 Minuten und die größere 29
Gruß Harald

Bild

Benutzeravatar
Michael H.W. Weber
Vereinsvorstand
Vereinsvorstand
Beiträge: 22419
Registriert: 07.01.2002 01:00
Wohnort: Marpurk
Kontaktdaten:

Re: POEM

#76 Ungelesener Beitrag von Michael H.W. Weber » 26.07.2016 12:20

@Felix2015: Wenn Du Dir die Mühe machen möchtest, bitte immer gleich hier eintragen: https://www.rechenkraft.net/wiki/Verein:Erfolge

Die Seite benötigt dringend eine Update. Auch die zig gefundenen Primzahlen von unserem Team siind nicht verzeichnet.

Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.

http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B

Bild Bild Bild

Felix2015

Re: POEM

#77 Ungelesener Beitrag von Felix2015 » 26.07.2016 16:01

Poem-Testreihe

Bild
*in den oberen Abschnitt bei 2 Wu lang muss noch geteilt durch 2 erfolgen - dann ist es auch nit so arg :oops:

Der Verkäufer der AMD HD 7970 hat mich informiert, dass er das Päckchen heute abgeschickt hat.
Toi - Toi - Toi - das dieses auch bei mir ankommt.
Dann den Zustand prüfen und im Anschluß diese mit Poem-WUs quälen... :evil:
Ergebnisse werden dann aktualisiert. :wink:

Edit 1:
Was ich jetzt nicht gemacht habe ist die beiden Graka zu tauschen und so unter den jeweiligen anderen CPU-Bedingungen laufen zu lassen.
Weil so ist: Die starke CPU mit der schwächeren Graka und die schwächere CPU mit der starken GPU.
Vermutlich würde die GTX 970 im AMD-setting - zumindest mit 2 WU - deutlich weniger Performence haben;
während die GTX 980 TI im Intel-setting - auch mit 2 WU - noch ein bissel mehr Performence haben.

Edit 2: Beide Graka sind mit 1.400 Mhz getaktet!
Beide Compis haben den Treiber 368.22
Zuletzt geändert von Felix2015 am 27.07.2016 11:02, insgesamt 2-mal geändert.

Felix2015

Re: POEM

#78 Ungelesener Beitrag von Felix2015 » 27.07.2016 06:20

Fortsetzung 2001 - 4000

Bild

:wink:

Bild

Felix2015

Re: POEM

#79 Ungelesener Beitrag von Felix2015 » 27.07.2016 17:13

Poem - Testreihe / Update

Bild
Bild

So, damit habe ich weitgehend meine POEM-Testreihe abgeschlossen.

Heute habe ich auch die HD 7970 erhalten und somit auch gleich im Test mit einbezogen.

Für mich hat sich einerseits bewiesen, dass laut Task-Manager die NV immer einen vollen Core sich zieht - egal ob mit app_config oder ohne.
Erstaunlich jedoch, dass die HD 7970 dieses nicht macht, sondern sich mit 2 bis 10 % begnügt.
Daraus resultiert, dass die CPU gleichzeitig beim Poem faktisch volle Leistung für CPU-Projekte freihält, was ein bemerkenswerter Gewinn ist.
Allerdings die GPU selber keineswegs irgendwelche besondere Performence gegenüber der GTX hat.

Nun ist es so, dass ich die "frische" AMD-Graka ja erst vorsichtig testen muss - und so unfairerweise den regulären Basistakt von 1050 Mhz nutze -
während die GTX alle auf 1400 Mhz deutlich übertaktet sind.
Also das will ich bei Gelegenheit noch hochschrauben.

Die HD 7970 hat auf jedenfall einen Knacks weg, den wenn ich zwei Seiten bewege, dann kommt es zu deutlichen Bildstreifen und Artifakte.
Wenn ich eine Aufgabe nach der andere am Monitor erledige - nicht. Auch natürlich - das Wichtigste - auch beim Crunchen nicht.

Ich hatte mich auch in den letzten zwei Tagen mal im SG-Forum durchs Poem-Thread gegraben.
Unter anderem bin ich da auf die Debatte gestoßen, dass bei Erweiterung von Poem auf GPU-crunchen zuerst nur AMD "liefern" konnte;
und unter diesen Bedingungen (2009/2010) die Poem-App von den Programmierer auf AMD-Graka optimiert wurde.
Also: nicht unbedingt die AMD-Graka sind gut, sondern die spezielle optimierten Apps von Poem.
Später ist dann NV hinzugestoßen und muss mit den Gegebenheit klar kommen, was natürlich ein Nachteil für Cuda war.
Eine weitere Anpassung erfolgte 2015 - womit NV nun deutlich Boden gewinnen, aber letztlich AMD nicht einholen konnte.

Fazit:
Die HD 7970 ist keine Superkarte - jedoch bezogen auf ihr Alter und vor allem ihre bemerkenswerte Resourcenschönung der CPU ist Radeon/AMD tatsächlich die 1. Wahl.
Ist es also so, dass wegen SP/DP AMD bei MW und PG sowieso eindeutig zu bevorzugen ist, ist selbst bei einer formalen Gleichhalte (SP) auch hier AMD vorzuziehen.
Damit bleibt eigentlich nur noch GPUGRID als NV-Unikat-Einsatz (was ich ja mit meiner GTX 980TI abgedeckt habe).
Und es gilt auf die neuen Vega-Karten zu hoffen, dass diese einen Leistungsschub bringen, der an die HD 7970 anschließen kann.
Da ich neben GPUGRID im wesenlichen Poem crunche, wechsel ich ins AMD-Lager.
:wave:

Benutzeravatar
Michael H.W. Weber
Vereinsvorstand
Vereinsvorstand
Beiträge: 22419
Registriert: 07.01.2002 01:00
Wohnort: Marpurk
Kontaktdaten:

Re: POEM

#80 Ungelesener Beitrag von Michael H.W. Weber » 27.07.2016 17:23

Eine Beobachtung, die ich ebenfalls gemacht habe:
Grundsätzlich gilt, dass die AMD GraKas wesentlich weniger CPU-Last erfordern, als NVIDIA-Karten. Was ich noch nicht auseinander dividiert habe ist, ob es an Abweichungen bezügl. CUDA / OpenCL liegt. Mein Verdacht ist, dass CUDA mehr CPU-Last fordert. Habe es aber nicht systematisch ausgelotet.

Was ist denn nun die 280X? Du nennst die anders... :roll2:
Meine kam heute an. Ich bin aber erstmal weg bis Montag zum Campen und dann brauche ich zum Testen erstmal Brett & vor allem Netzteil mit SAFFFFFFT. Wollte mir da selbst mal ein Seasonic 1050er gönnen, da ich plane, mittelfristig daran ein ATX-Brett mit mehreren GPUs zu betreiben, um Tim irgendwann ins Bockshorn zu jagen, mit seinem GPU-Maschinenpark (Tim, melde Dich, falls Du irgendwann mal der Titan Black überdrüssig werden solltest...). :lol:

Angenehm überrascht bin ich, dass die AMD die 970er weghaut. Hätte ich nicht erwartet. Gefällt mir, vor allem, wenn man sich den Preis der Karten im Vergelich dann noch reinzieht. Allerdings: Verbrauch auf Dauer nicht übersehen...

Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.

http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B

Bild Bild Bild

Tim
Vereinsvorstand
Vereinsvorstand
Beiträge: 931
Registriert: 05.04.2013 16:22
Wohnort: Wildau

Re: POEM

#81 Ungelesener Beitrag von Tim » 27.07.2016 17:27

Michael H.W. Weber hat geschrieben:[..] um Tim irgendwann ins Bockshorn zu jagen, mit seinem GPU-Maschinenpark (Tim, melde Dich, falls Du irgendwann mal der Titan Black überdrüssig werden solltest...). :lol:

Michael.
Dieses Jahr noch nicht, aber ich denke im nächsten Jahr fliegen die beiden R9 290x erstmal raus.

Felix2015

Re: POEM

#82 Ungelesener Beitrag von Felix2015 » 27.07.2016 17:43

@Michael -
die Radeon HD 7970 als "Tahiti" ist im Dezember 2011 auf den Markt gekommen.
Die Radeon R9 280X ist als Rebrand "Tahiti" im Oktober 2013 erneut auf den Markt gekommen.
Es ist ein und die gleiche Graka nur unter anderem Verkaufsnamen.

Benutzeravatar
Michael H.W. Weber
Vereinsvorstand
Vereinsvorstand
Beiträge: 22419
Registriert: 07.01.2002 01:00
Wohnort: Marpurk
Kontaktdaten:

Re: POEM

#83 Ungelesener Beitrag von Michael H.W. Weber » 27.07.2016 18:25

Ah, OK - Danke. :wink:

Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.

http://signature.statseb.fr I: Kaputte Seite A
http://signature.statseb.fr II: Kaputte Seite B

Bild Bild Bild

Felix2015

Re: POEM

#84 Ungelesener Beitrag von Felix2015 » 28.07.2016 06:37

Fortsetzung: 4001 - 6000

Bild

:roll2:

Bild

Edit: Die Machen von Poem erklären dazu:
Mittlerweile gibt es viele Datenbanken mit Peptidsequenzen (Peptide sind kleine Proteine), welche manchmal mehr, manchmal weniger aktiv gegen Krebszellen eingesetzt werden koennen. Sie koennen zum Beispiel entweder das Krebswachstum oder die Vervielfachung im Koerper unterbinden. Auch wenn diese Peptide natuerlich sehr aktiv biologisch studiert werden ist die 3D Struktur oder die Art, wie sie funktionieren noch nicht bekannt. Wir wollen daher die 3D Struktur erfahren, um hoffentlich zu verstehen, wie genau die Funktion der Peptide ist um sie hoffentlich zu modifizieren und zu verbessern. Auf dieser Seite werdet ihr die momentanen 100 energetisch favorisierten Strukturen finden.
Die vollständige (sofern diese auch vollständig hier veröffentlicht worden ist!) Datenbank enthält über 20.000 Peptidesequenzen - an deren Analyse das Team Rechenkraft mitgewirkt hat!

Nach meiner Einschätzung wurde dieses Sub-Projekt in den Anfangszeiten von POEM gestartet - und zwar weitesgehend als CPU-basierendes crunchen,
wo die einzelnen WUs noch langsam kamen, oft fehleranfällig waren und meist 1 bis 2 Stunden dauerten.
Sollte die veröffentliche DB das sein, was es ist - also nichts mehr nachgereicht wird -, dann stellt dieses wiederum die Basis für nachfolgende Sub-Projekte da,
die sich nach und nach die einzelnen Peptide vornimmt. Gegenwärtig sind es rund 500 Einheiten! Diese liegen als DB kaum der Öffentlichkeit vor (ca 5 !), weil vermutlich noch gänzlich im "wissenschaftlichen Prozeß".

Antworten

Zurück zu „Protein- und Nukleinsäureforschung“