Der allgemeine Ryzenthread.

Richtig, habe ich beim überfliegen überlesen, für die Suchfaulen:

Linux handles this rather better: it actively prefers to keep threads on the same core for as long as there are no scheduling conflicts on that core. So, a single-threaded workload on Linux will usually stay on the same core for several seconds at a time, if not longer. This not only avoids the overhead of migrating the thread, but also avoids cache misses and inter-CCX traffic that would result from such a migration. This behavior is not Ryzen-specific, but has been standard on all SMP/SMT/CMT machines running Linux for several years.
 
Das kann ich bestätigen, der Linux Sheduler wechselt die Kerne sehr langsam durch.

Das Setup für die Taktung wird vom Bios übernommen. wenn man was optimieren will muss man alles im Bios machen. Ob es auch wärend des Betriebs geht, da hab ich mich noch nicht informiert. Ist eben für ein Server Betreibssystem wieder eine Angriffsfläche. Bei Athlon/Phenom musste man erst module laden um etwas anpassen zu können.

Beim AMDGPU-Treiber ist die Schnittstelle verhanden, man kann aber nur untervolten und untertakten. OC oder Überspannungen wird nicht zugelassen, ist von dem her abgesichert.
 
Ja gewöhne dich dran, ob man will oder nicht die Zeiten von Windows 7 gehen langsam vorbei

... und dann nimmt man Linux, statt sich Windows 10 anzutun. 8) (Für Anwendungen sowieso, aber auch für Spiele.)
 
Ist ie Agesa 1004B jetzt eig die finale Version? Oder kommt da noch 1004c usw?
 
... und dann nimmt man Linux, statt sich Windows 10 anzutun. 8) (Für Anwendungen sowieso, aber auch für Spiele.)
Inwiefern "anzutun"? Die Frage ist, in welchem Szenario ich mir mehr "antun" muss, wenn ich Anwendungen wie Capture One unter Linux zum Laufen bekommen möchte (als Anwender, der erwartet, dass man eine Anwendung mit einem Doppelklick installiert bekommt und sie läuft).
 
Inwiefern "anzutun"? Die Frage ist, in welchem Szenario ich mir mehr "antun" muss, wenn ich Anwendungen wie Capture One unter Linux zum Laufen bekommen möchte (als Anwender, der erwartet, dass man eine Anwendung mit einem Doppelklick installiert bekommt und sie läuft).
Wenn ich so in die Wine AppDB schaue, dann glaube ich du kannst dir das sparen, das wird unter Linux wohl nicht laufen (ok, die Ergebnisse sind recht alt, aber dennoch würde ich mir da keine großen Hoffnungen machen).
Höchstens in einer VM mit Windows, aber da wird dann vermutlich die Performance nicht sonderlich gut sein.

Es gibt z.B. mit darktable eine gute Alternative, aber ob die dem eigenen Workflow entspricht muss jeder selbst herausfinden.
 
Die Hardwar ist eben nur die halbe Miete. Da muss AMD die Compieler auch auf Zen abstimmen und das ganze drumherum. Noch einiges an Arbeit würde ich mal sagen.

Das da einiges am köcheln ist schon länger klar.

IBM hat RedHad übernommen, Stallman (der Begründer von GNU/LInux) ist geganen. Da ist einiges in Bewegung, Ich denke mal da kommt ein Generationenwechsel.
 
Das hat nichts mit Compiler zu tun (auch wenn sie dort ähnliches abgezogen haben). Die eingesetzte MKL hat seitens Intel einfach ein Fallback eingebaut. Entweder Intel CPU (d.h. nutze AVX) oder AMD (d.h. nutze SSE). Aber das erklärt ganz gut, warum AMD CPUs generell unter Matlab so schlecht performen. Werde mir mal das Script näher anschauen.
 
Ich bin kein Entwickler oder Progammierer aber es gibt da schon Unterschiede zweischen den einzelnen Distributionen was die Kernelabstimmung und optimierungen betrifft. Das bei mir z. B. PCLinuxOS bei Univers@home so gute Rechenzeiten abliefert als andere Distries. hat denke ich mal damit zu tun. Genaueres kann ich dazu nicht sagen.

Da ich schon Jahre lang Linux nutze bekomm ich vll mehr mit als mir lieb ist. Ich kann mir auch vorstellen das sich die Entwicklung von oben source generell verschiebt. Von Amerika weck in andere Länder wo man aufgeschlossener ist.
 
Ich bin kein Entwickler oder Progammierer aber es gibt da schon Unterschiede zweischen den einzelnen Distributionen was die Kernelabstimmung und optimierungen betrifft. Das bei mir z. B. PCLinuxOS bei Univers@home so gute Rechenzeiten abliefert als andere Distries. hat denke ich mal damit zu tun. Genaueres kann ich dazu nicht sagen.
Das dürfte zumindest teilweise an den Optimierungen liegen, welche aktiviert bzw. deaktiviert sind.
d.h. welche CPUs noch unterstützt werden und welche Optimierungen man aktiviert hat bzw. voraussetzt.
Zudem kann man auch bei den Schedulern noch wählen, wobei es für den CPU Scheduler ja nur einen intree Scheduler gibt und keine ernsthafte Distribution einen externen eingepflegt hat, soweit mir bekannt.
Auch von Kernel Version zu Kernel Version kann es etwas Unterschiede geben, die sind aber meistens eher klein.

Generell ist auf Binärdistributionen die meiste Software nicht wirklich optimiert gebaut.
Das ist für die meiste Software herzlich egal, aber in manchen Fällen kann es schon einen signifikanten Unterschied machen, gerade wenn es um wissenschaftliche Software geht.
 
Habe mal auf meinem Kaveri unterschiedliche Debug CPU Types getestet. Am schnellsten ist es ohne irgendwelche Optimierung, d.h. MKL_DEBUG_CPU_TYPE=0 (entspricht der Standardeinstellung). 5 und 1 (SSE2) gehen nicht, ersteres liegt am 64Bit. Generell performt Kaveri ziemlich mies (fehlender L3?), muss mal schauen, ob man die MKL wechseln kann. Es sind hier Unterschiede beim CPU Type zwischen 32Bit und 64Bit zu beachten:
http://publicclu2.blogspot.com/2013/05/intel-complier-suite-reference-card.html

Die größten Änderungen gibt es bei der LU Faktorisierung und bei Sparse Matrix Operationen (schnellste Werte aus 4 Läufen, Matlab 2016b):
CPU_TYPELUFFTODESparse
4 (AVX)0,74420,35120,10350,1906
3 (SSE4.2)0,66930,36220,10830,1908
2 (SSE3)0,70840,35010,10320,4035
0 (SSE)0,40800,34320,10420,2316

SSE3 scheint hier bei Sparse recht schlecht abzuschneiden. MKL_ENABLE_INSTRUCTIONS=AVX(128,256) scheint keine Auswirkung zu haben. Andere Optionen wie MKL_NUM_THREADS und MKL_DYNAMIC bringen auch nur eine Verschlechterung.
 
Moin suchen alle noch den neuen TR oder den neuen 3950x hier ist ja mal wenig los?
Ich musste mich heute sogar bei CB 2 mal lesen als ich den TR test gelesen hatten .

lg
 
Scheinbar sind alle noch geflasht.*buck*
 
Ja hier ist es zum Glück ruhig, wo anderes geht der Punk ab und sie hauen sich die Köpfe ein (sehr unterhaltsam wenn man dazu Zeit verbrennen will).

Nun die Reviews bringen das was zu erwarten war, 3900x und 3950x haben ja schon gezeigt was bei TR3 raus kommen sollte.

Bis hier einer mit so einer CPU auftaucht könnte halt noch etwas dauern.
 
Bis hier einer mit so einer CPU auftaucht könnte halt noch etwas dauern.

CPU liegt schon hier - ich warte nur noch auf das passende X570 Board, den RAM und das AM4-Mountingkit für den NH-D15 (kommt hoffentlich alles in den nächsten beiden Tagen) :]

Edit: defense hat seine CPU auch schon - so langsam werden die hier schon eintrudeln (wie auch bei den X3900 vor ein paar Monaten?)...
 
Zuletzt bearbeitet:
Nein - ich meinte den X3950 - der war ja auch erwähnt...
Bei TR sieht die Versorgungslage wohl nicht ganz so mager wie beim 3950 aus...
 
Ich meinte schon den eine TR3 CPU. Das sich genug versuchen auf den 3950x zu stürzen wurde ja schon angekündigt.
 
Meiner Meinung nach sind die DIEs bei AM4 einfach viel zu klein für 16-Kerner. Wie soll das auch gehen, wenn selbst bei 8-Kernern das Power-Target der Flaschenhals ist? 16 Kerne schön und gut, aber man kann sich denken, wie stark da die Pro-Kern-Leistung runter gehen muss, wenn man parallel 16-Kerne bei Vollauslastung für längere Zeit über den kleinen DIE kühlen muss.
Bei Anwendungen, die nur kurzfristig alle Kerne nutzen (also immer kurzfristig das Power Target überschreiten) oder für einen Cinebench-Lauf zum Angeben... alles kein Problem. Aber längere Vollauslastung von 16 Kernen parallel? Kann mir nicht vorstellen, dass das irgendwo sinnvoll ist. Ohne fette Wakü sowieso nicht.

Beim Threadripper sieht's natürlich ganz anders aus mit dem großen DIE, da kann man ja ordentlich was weg kühlen.
 
Meiner Meinung nach sind die DIEs bei AM4 einfach viel zu klein für 16-Kerner. Wie soll das auch gehen, wenn selbst bei 8-Kernern das Power-Target der Flaschenhals ist? 16 Kerne schön und gut, aber man kann sich denken, wie stark da die Pro-Kern-Leistung runter gehen muss, wenn man parallel 16-Kerne bei Vollauslastung für längere Zeit über den kleinen DIE kühlen muss.
Bei Anwendungen, die nur kurzfristig alle Kerne nutzen (also immer kurzfristig das Power Target überschreiten) oder für einen Cinebench-Lauf zum Angeben... alles kein Problem. Aber längere Vollauslastung von 16 Kernen parallel? Kann mir nicht vorstellen, dass das irgendwo sinnvoll ist. Ohne fette Wakü sowieso nicht.

Beim Threadripper sieht's natürlich ganz anders aus mit dem großen DIE, da kann man ja ordentlich was weg kühlen.

???
Die Dies sind doch alle gleich groß?
Oder meinst Du das Package, bzw. Heatspreader?
 
Beim 3900x ist das schon kein Problem dann wird das auch beim 3950x gehen.

Und die Chiplets sind überall die selben.
 
Zuletzt bearbeitet:
Beim Threadripper sieht's natürlich ganz anders aus mit dem großen DIE, da kann man ja ordentlich was weg kühlen.
Man könnte jetzt Milchmädchenrechnungen aufmachen, dass beim 3990X die 280W ja auf 9 dies aufgeteilt werden und beim 3950X 105W auf 3 dies - dann sieht man den nur geringen Unterschied.
 
Meiner Meinung nach sind die DIEs bei AM4 einfach viel zu klein für 16-Kerner. Wie soll das auch gehen, wenn selbst bei 8-Kernern das Power-Target der Flaschenhals ist?

Wie kommst da drauf?
Der 3700x mit seinen mageren 65Watt......SoC mit rund 20Watt,da bleibt nicht mehr so viel für die Kerne Übrig,wobei ohne Drossel haben die ja auch mehr Luft nach oben,aber der 3800x kann sich doch mit Männerkühlung (AiO) und Anständigem Mainboard richtig Austoben.
 
Zurück
Oben Unten