BOINC Performance auf AMD Ryzen

Wäre die Situation um die Boards besser, dann müsste ich jetzt auch bestellen.
Aber ich warte lieber bis mitte/ende April um beim Pentadings mit 16 Freds antreten zu können.
Bis dahin ist sicher noch das eine oder andere Board auf dem Markt und bzw die jetzigen besser lieferbar.
Zum Glück gibts bei mir etliche PCs, die langsam 10 Jahre alt werden.
Und darum greife ich auch zu einem µATX-Board, das kann dann notfalls mit einer noch kommenden APU in den HTPC wandern, wenn es nicht das Grüne vom Ei ist.
 
Da kommt bei mir: "Verarbeitung der Anfrage nicht möglich" *noahnung*


Wie sieht's denn bei Ryzen aus, wenn die FMA4-App verwendet wird?

Gruß,
Ritschie

Zum Thema FMA4-App. Bei mir im Test hat Bulldozer bei Asteroids mehr Credits mit der SSE2-App abgeworfen als mit FMA4 *noahnung*
 
Das war immer etwas komisch, zb hat SSE2 meist auch mehr als AVX gerissen. Da ging es erst mit AVX2 ab.
 
Zum Thema FMA4-App. Bei mir im Test hat Bulldozer bei Asteroids mehr Credits mit der SSE2-App abgeworfen als mit FMA4 *noahnung*
Hm, also das hatte ich seinerzeit mit allen Buldozer-basierenden CPUs druchgespielt. Immer das selbe. Gegenüber SSE APP gut 10 bis 15 % schneller.
Man muss nat. mehrere WUs rechnen, da die Laufzeiten schon merklich schwanken können.
 
Vielleicht haben sie die SSE-App ja verbessert in der Zwischenzeit. Ich hab bestimmt jeweils 30 WUs durchgeknuspert.
 
Hmm, habe mir dann doch mit einer app_info.xml für Asteroids auch die bereits fertigen WUs ins Nirvana befördert, schade. Die werden online nicht auftauchen.
Die AVX WUs laufen schon seit >78 Minuten und sind erst bei ~60%, die werden länger laufen als die SSE3 zuvor... Wenn die (morgen?) hochgeladen sind, ziehe ich nochmal eine Ladung SSE3 :-(
 
Sehr schade. Dachte, dass ZEN da besser wird. Das ist dann halt die Stärke der Intels

@Onkel: Nee, die App haben sie seit 2014 nicht mehr angefasst.

--- Update ---

Mir fällt noch ein, dass der Ersteller der FMA4 App meinte, unter Linux sei die App nochmal ein wenig schneller, da weniger Overhead.
 
Wie es aussieht, wäre mir wurscht - rechnet es denn auch besser?

Da müsste man diese WU mal morgen betrachten: https://einsteinathome.org/task/618140367. Die lief jetzt von Anfang an unter Lasso; mal sehen ob die den Linux-Ergebnissen näher kommt...

--- Update ---

Auf jeden Fall sind jetzt einige Einstein-WUs mit ca. 78% Fortschritt auf einmal fertig geworden.

--- Update ---

z.B.

https://einsteinathome.org/workunit/278669685
https://einsteinathome.org/workunit/278669647
https://einsteinathome.org/workunit/278669604

machen sich schon besser gegen Linux. Und sind nur die letzten paar Stunden unter Lasso gelaufen.

--- Update ---

Nochmal ein Update: Wenn man die 8 Einstein WUs auf die physischen Kerne festnagelt, zieht das System 90-100 W aus der Steckdose.

Ich lasse die Einsteins jetzt noch durchlaufen und dann überlasse ich wieder Profi-BOINCern das Feld. Burn-In hat das System ja dann erfolgreich abgeschlossen ;D.
 
Zuletzt bearbeitet:
Die AVX sind jetzt durch (~2:10h), ich schummel dem mal die SSE3 app unter für den Rest der schon geladenen WUs...
Davon ab mal über Nacht WCG ZIKA, OET, FAH und SCC rechnen. Die lassen sich dann schwer vergleichen, aber ich kann sie wenigstens mit meinem i7 in Relation setzen.

Multi-Directed Continuous Gravitational Wave search CV will Einstein mir nicht rausrücken, obwohl der Server genug hat. Schade.

Davon ab noch jemand Testwünsche?

--- Update ---

MilkyWay@Home N-Body Simulation v1.62 (mt) lohnt sich nicht, 4 WUs (16 threads) berechnet in je 172-221 Sekunden. Dafür gibt es "magere" 22-50 Punkte. Eine Einheit wurde noch nicht validiert (Fertig, Bestätigung nicht eindeutig).
 
Zuletzt bearbeitet:
Ja, die N-Body haben wenig Credits. Wenn man die aber trotzdem rechnen will: mehr als 8 Threads machen keinen Sinn. Also eine app_config anlegen und das einstellen:
Code:
<app_config>
 <app>
        <name>milkyway_nbody</name>
        <max_concurrent>4</max_concurrent>
 </app>
 <app_version>
        <app_name>milkyway_nbody</app_name>
        <platform>x86_64-pc-linux-gnu</platform>
        <plan_class>mt</plan_class>
        <avg_ncpus>8</avg_ncpus>
        <cmdline>--nthreads 8</cmdline>
 </app_version>
</app_config>
 
Milkyway war noch nie so meins, das lasse ich lieber ;-)
 
So, die ersten komplett unter Lasso sind durch:

1, 2, 3, 4, 5

Fazit: Entweder taugt Ryzens SMT nix oder ein Windows-Scheduler-Patch ist fällig. Ein wenig wundert ja schon, dass AMD nach Bulldozer wieder in dieses Fettnäpfchen tritt. :P
 
@koschi: weiß jetzt gar nicht, ist's auch unter Linux möglich, Threads so auf Kerne festzunageln? Eigentlich bräuchte es da Anpassungen am Scheduler...
 
Du hattest aber nur 8 Threads Einstein laufen lassen? Die Zeiten sind natürlich gut, nur mit 16 Threads sollte die dann doch wieder zwischen 30-40000 Sekunden liegen, oder?


Unter Linux lässt sich mit taskset -a -p -c 0 $PID ein Prozess (-a = inkl. aller Threads) auf die CPU 0 festnageln. BOINC könnte man durch Vorranstellung von "taskset -a -p -c 0,2,4,6,8,10,12,14" vor dem eigentlichen Startbefehl auf die Kerne limitieren. Sollten die dann noch wechseln, kann man das sonst auch über ein kleines Skript einsortieren.

--- Update ---

Code:
03ap10ac.15454.25024.12.39.11_0 2456174450 5 Mar 2017, 8:12:30 UTC 5 Mar 2017, 9:59:13 UTC 4,415.10 	4,302.03 45.04 	SETI@home v8 v8.05
i686-pc-linux-gnu
03ap10ac.15454.25024.12.39.5_1 2456174444 5 Mar 2017, 8:12:30 UTC 5 Mar 2017, 9:52:46 UTC 4,436.26 	4,332.96 44.26 	SETI@home v8 v8.05
i686-pc-linux-gnu
18se10ae.11977.889.5.32.142_1 2456205094 5 Mar 2017, 8:40:31 UTC 5 Mar 2017, 14:28:17 UTC 10,209.17 	9,103.92 108.57 	SETI@home v8 v8.00
x86_64-pc-linux-gnu
18se10ae.11977.889.5.32.215_1 2456205167 5 Mar 2017, 8:40:31 UTC 5 Mar 2017, 12:39:39 UTC 9,645.20 	8,939.81 117.26 	SETI@home v8 v8.00
x86_64-pc-linux-gnu
18se10ae.3455.21748.3.30.140_0 2456174323 5 Mar 2017, 8:12:30 UTC 5 Mar 2017, 12:45:29 UTC 13,393.48 	12,700.02 111.63 	SETI@home v8 v8.05
i686-pc-linux-gnu
18se10ae.3455.21748.3.30.146_0 2456174329 5 Mar 2017, 8:12:30 UTC 5 Mar 2017, 12:50:17 UTC 13,364.16 	12,720.26 95.37 	SETI@home v8 v8.05
i686-pc-linux-gnu
18se10ae.3455.21748.3.30.152_1 2456174335 5 Mar 2017, 8:12:30 UTC 5 Mar 2017, 13:39:29 UTC 13,255.33 	12,656.98 ausstehend 	SETI@home v8 v8.05
i686-pc-linux-gnu
29mr10ad.12606.15613.10.37.57_2 2455710999 5 Mar 2017, 8:12:30 UTC 5 Mar 2017, 16:29:19 UTC 15,241.93 	13,926.03 126.80 	SETI@home v8 v8.05
i686-pc-linux-gnu

hmm, ~12500 Credits am Tag, wie ist das einzuschätzen?
http://setiathome.berkeley.edu/workunit.php?wuid=2456174323 ist der R7 so schnell wie ein C2 Q9650.

--- Update ---

https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=1434775960
Ein i7-6700 benötigt für das gleiche Paket (bei mir 173s) 1023 Sekunden. Laut Stderr Ausgabe nutzt er 8 Threads.

https://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=715362
Ein i7-4790 benötigt 343 Sekunden (bei mir 221s), wieder 8 Threads... Warum ist der soviel schneller als der 6700er?
 
Zuletzt bearbeitet:
Milkyway oder N-Body App? (MW macht gerade mysql Fehler)
 
Sind Resultate der n-body Anwendung...
 
Wenn du nicht auf 8 Threads begrenzt hast, dann sind es mehr und dann ist der Vorteil auch klar.
 
Ich finde das ist schon ein gewaltiger Unterschied.
R7 1700: 173 Sekunden * 16 Threads = 2768 Sekunden total
i7 6700: 1023 Sekunden * 8 Threads = 8184 Sekunden total

Kann nun auch gerade nicht schauen welches OS der hatte, vielleicht war es Windows und die Implementierung ist einfach nur Grotte ;-)

--- Update ---

https://www.cosmologyathome.org/results.php?hostid=123978

Immernoch knauserig die Bande (~8k/d), selbst SETI gibt 50% mehr :-D
 
N-Body wurde glaube mit OpenMP erstellt. Da war das OS nachrangig.
Stimmt schon, ist bedeutend schneller. Zumal ja die Skalierung ab 8 Threads drastisch nach unten ging, bisher.

Und die Camp App bei Cosmo ist von 2009 ;)
 
hmm, ~12500 Credits am Tag, wie ist das einzuschätzen?
Mit einer WU kommt meine GTX970 auf ca. 14k cr/d, mit 2 parallel auf ca. 18k (Linux, bei Windows gibts deutlich mehr). Bei ca. 100W zusätzlich + das, was die 1-2 CPU-Kerne noch brauchen.
Also da lohnt es sich definitiv, zur Racetime auch die CPU mitrechnen zu lassen.
 
Hi

in progs sind ausser ´übertacktete I5 ohne HT merklich schneller den rest hab ich in griff gehabt.
Aber der eine I5 hatte schon heftig wenig sek benötigt, ich liege so um 6,2k er lag bei 2,3k o_O hat aber scheinbar doch etwas getacktet wenn ich
mir seine Werte anschaue.

lg
 
Zuletzt bearbeitet:
Du hattest aber nur 8 Threads Einstein laufen lassen? Die Zeiten sind natürlich gut, nur mit 16 Threads sollte die dann doch wieder zwischen 30-40000 Sekunden liegen, oder?
Ohne Lasso waren auch 8 Threads schnarchlahm und haben sich gegenseitig irgendwie die Füße plattgetreten.
 
Zurück
Oben Unten