SMP2 / A3-Core bzw. neuer Client 6.29

**Uwe64LE** · 03.02.2010, 21:30

Die dynamische Anzeige ist echt lustig.
Hab gestern ein P6015 angefangen. Erste Anzeige: 4279 PPD und 2328 Punkte.

Über Nacht hat er wohl doch nicht so schnell gerechnet, wie geschätzt.
Bevor ich zur Arbeit bin, wurden 4169 PPD und 2282 Punkte angezeigt:

Da ich die Kiste nicht wieder den ganzen Tag rechnen lassen wollte, hab ich den PC ausgeschaltet,
bevor ich zur Arbeit bin und war mal gespannt, wie sich der Zeitverlust bemerkbar macht:

Heute abend waren es nur noch 2881 PPD (logisch) und auch nur noch 1637 Punkte-
obwohl ich noch fast 2 Tage bis zur deadline hab:

noxit · 05.03.2010, 07:29

Achtung, nur für i7-Nutzer interessant:

Ich wollte kurz was zur Problematik "PPD-Verlust bei SMP+GPU-Nutzung" schreiben, und bitte Uwe, nicht so streng mit mir zu sein, weil ich aus Zeitgründen keinerlei Screenshots beifüge.

Bekannt ist dem ein oder anderen das Problem, dass das gleichzeitige Nutzen von SMP und GPU clients die PPD-Leistung eines oder aller clients beeinträchtigen kann, weil der (oder die) GPU-client(s) ebenfalls CPU-cycles benötigen und damit den SMP-client ausbremsen können. Umgekehrt kann auch der SMP den/die GPU verlangsamen. Allgemein bekannt ist der Kniff, die CPU Priorität des SMP auf "idle" zu lassen, und die der GPU auf "low" zu erhöhen (innerhalb der client-config). Programme wie PriFinity erlauben eine umfassendere Änderung von Prioritäten und Affinity, habe ich aber noch nicht ausprobiert.

Während in meiner Erfahrung der SMP-client mit A1-core fast gar nicht unter GPU-client-Nutzung gelitten hat, ist dies mit dem neuen A3-core wesentlich stärker der Fall. Das verwundert auch nicht, weil die CPU wesentlich besser genutzt wird. Nun kursieren in einschlägigen FAH-Foren die wildesten Vorschläge, wie man den Gesamt-PPD-Ausstoß maximieren kann: PriFinity o.ä., Umgebungsvariablen etc.

Allerdings spielt, wie ich in den letzten Tagen gesehen habe, die wichtigste Rolle welche WU die GPU bekommt! Ein Beispiel: welche A3-WU man hat, spielt kaum eine Rolle, aber mit einer 472er-GPU-WU gibt es praktisch keine Beeinflussung der SMP-PPD, ich erhalte ca.: SMP: 10.500, GPU 7.800.
Bekomme ich aber andere GPU-WUs wie 353er, 587er o.ä., so leidet der SMP-client stark. Sprich: SMP: 8.500, GPU 8.500. Festzuhalten ist, dass genau diejenigen GPU-WUs problematisch sind, die eine hohe GPU-Auslastung bewirken, während die 472er-WUs kaum GPU-Last erzeugen.

Als mögliche Gegenmaßnahme zu den PPD-Schwankungen habe ich einiges ausprobiert und das am ehesten geeignete ist, dem SMP-client als Argument -smp 7 anstatt -smp 8 mitzugeben und den SMP auf die ersten 7 cores zu binden, den GPU-client auf den 8ten core (z.B. via Taskmanager oder PriFinity). So kommen sich beide nicht mehr so stark ins Gehege und die PPD-Werte bleiben tatsächlich bei mir konstant, sind bei der GPU etwas höher als vorher, beim SMP auch etwas höher als vorher aber immer noch niedriger als ohne GPU-Nutzung, weil natürlich nur 7 statt 8 Threads genutzt werden.

Das Problem ist natürlich, dass man bei Erhalt einer "leichten" GPU-WU wie 472er wieder nur 7 Threads nutzt und damit ca. 1.000 PPD weniger in Summe bekommt, als mit -smp 8.

Ich habe das alles eine Weile verfolgt und für mich im Endeffekt doch wieder entschieden, auf -smp 8 umzusteigen. Dann schwanken die PPD-Werte je nach WU zwar stärker, aber in der Summe landet man auch nicht niedriger als mit -smp 7, je nach WU-Bezug aber ne ganze Ecke höher (wenn man z.B. 10 472er-GPU-WUs am Stück bekommt).

Mein Gesamtfazit wäre also: vergesst alles, was ich oben geschrieben habe, und macht normal weiter. Trotzdem wollte ich meine Erfahrungen hier schildern. Danke für's lesen!

Ach ja: die starke Beeinflussung der SMP-PPD-Werte rührt natürlich daher, dass der A3-core stark auf kommunizierende Threads setzt. Wenn also ein Thread/core warten muss aufgrund Fremdbeanspruchung, müssen alle anderen Threads/cores ebenfalls warten. Das schlägt wesentlich stärker rein, als man naiv vermuten würde, weil ja nur einer von acht Kernen beschäftigt ist.

**Uwe64LE** · 05.03.2010, 22:18

Wie du richtig schreibst, ist das (im Moment) nur für i7 Falter von Bedeutung.
Ich kann mir also gar nicht anmaßen, streng zu sein- ich hab leider keinen i7 und kann deine Schilderungen somit nicht praktisch nachvollziehen.

Mein Primärprodukt ist jedoch immer die GraKa, da die in meinem System ja die doppelte bis vierfache PPD-Leistung der CPU aufbringt.
Das sieht bei dir ja ganz anders aus.

Ich lese deine Beiträge trotzdem mit großem Interesse.

sp · 06.03.2010, 09:18

Obwohl mich noxit's Beitrag nicht Betrifft hab ich ihn ebenfals mit großem Interesse gelesen.
Weiter hin hab ich ebenfalls die Feststellung gemacht, dass die Puntkte (gutschrift) selbst beim einhalten der DL bzw. 80% schon zimmlich eingebrochen sind. Kleines Beispiel, mein SMP(4) startet mit ca. 3800 Punkten, nach ca. 2 Tagen sind nur noch 1300 Punkte übrich.
Ich schlussfolgere daraus das es sich damit um ein generelles Problem handelt und nicht Prozessormarken abhängig ist.

chrisr15 · 06.03.2010, 13:51

Schaltest du den PC zwischendurch ab? Dann ist es logisch, denn es werden die PPD aufgrund der Punkte berechnet, welche du bekommen würdest, wenn du durchgehen weiterfolden würdest. Jedes Unterbrechung kostet Punkte und somit PDD.

chrisr15 · 15.04.2010, 21:24

Es gibt wieder gute Nachrichten: Gestern wurde GCC* 4.5 released und dieser soll beim A3 Core auf Linux (Windows nutzt einen Intel Compiler) einiges an Leistung bringen.
(FAH-Addict redet von bis zu 180% keine Ahnung wo das herkommt)

*) GNU Compiler Collection

**Uwe64LE** · 18.04.2010, 18:13

Ich hab seit fast 2 Tagen ein neues Projekt in Bearbeitung, was mich fast zur Verzweiflung bringt: P6040 ... dauert ewig, läuft nur mit 3000 PPD-
bringt aber auf einen Schlag über 5000 Punkte.

Da hab ich doch glatt übersehen, dass meine GPU-WU die deadline überschritten hat.

Das wäre sicher für einen i7 die optimale Spielwiese.

sp · 18.04.2010, 20:27

die p6040 kommen mir unangenhem bekannt vor. Aber die Punkte aus beute ist selbst auf einem Phenom I extrem. Aber wie Uwe schon gesagt hat, dauert ein Ehwigkeit.

noxit · 19.04.2010, 05:23

Ah, eine 6040er hatte ich auch schon einmal. Brachte bei mir etwa 9300 Punkte, aber der PPD-Wert lag bei normalen 11000. Also kein Unterschied zu den anderen A3-WUs. Mal sehen, wann die bigadv-WUs für A3 kommen - ist ja in Planung, aber "soon" heisst bei der Pandegruppe ja soviel wie irgendwann dieses oder nächstes Jahr.

chrisr15 · 23.04.2010, 20:55

Und es gibt wieder neue Projekte (nur mit -advmethods erhältlich):
P6050 bis P6064: soll 481 Punkte bringen, bei einem Bonus von 2.1

sp · 23.04.2010, 21:13

Zitat:

Zitat von chrisr15

Und es gibt wieder neue Projekte (nur mit -advmethods erhältlich):
P6050 bis P6064: soll 481 Punkte bringen, bei einem Bonus von 2.1

was soll das denn jetzt bedeuten? Freu mich aber schon mal wieder meinen PC an zu schmeisen.

chrisr15 · 23.04.2010, 22:01

Bonus ist vielleicht der falsche Begriff, heißt korrekt f-Faktor (siehe zweites Post)

hoyy · 24.04.2010, 08:28

Ich arbeite im Moment an genau so einer.
Leider ist es meine erste SMP-Unit, daher leider keinen Bonus.

chrisr15 · 13.05.2010, 13:45

So, nun ist es so weit, die A1 und A2 laufen aus und der A3 verlässt den "advmethods" Bereich und wird zum Standard.
Bei bigadv soll es noch etwas brauchen.