News Threadripper 2990X: Neues Ryzen-Flaggschiff für 1.500 Euro gelistet

[Hill Ridge]

Ich will den CPU Kühler sehen der "sofern die bisherigen Angaben " den Threadripper x2990 mit 32 Kernen bei TDP von 250W beim "OC" noch passend kühlt.

Dann wart halt, bis welche auf den Markt kommen.

250W ist bei TR echt leicht zu kühlen, die Kontaktfläche ist einfach sehr groß.

 

[Piktogramm]

@new Account()

Jup außer man könnte mit der neuen Sprache eben den Algorithmus anders programmieren und so ein Vorteil erzielen aber das ist eher unwahrscheinlich.

Jain.
Algorithmen bei denen es möglich ist ohne Blockaden Kalkulationen zu vollführen werden bereits Parallelisiert. Einmal via SIMD und auch über multiprocessing. Algorithmen wo dies nicht möglich ist, lassen sich jedoch nicht beliebig umformulieren, sodass dein Ansinnen möglich ist. Dazu müsste ein neuer Algorithmus her. Typischerweise sind solche Algorithmen jedoch "nur" Verfahren zur Annäherung des exakten Ergebnis des ursprünglichen Lösungsverfahrens.

@Piktogramm
Ach sag bloss, Multitasking ist also nicht das parallele Ausführen des gleichen oder unterschiedlicher Programme bei dem jeders Programm auch einen anderen Kern nutzen kann (Verwaltung durch das Betriebssystem) und es an der Stelle herzlich egal ist ob das einzelne Programm nur einen Kern auslasten kann weil alle zusammen die Auslastung der CPU erhöhen?

Wie bereits geschrieben, du solltest dir die Definitionen von Multithreading und Multiprocessing anschauen und ich erweitere auf Multitasking. Du hast da einige Dinge derart durcheinander, dass man deine Äußerungen als irgendwie richtig und irgendwie falsch lesen kann.

Der Witz ist eher das es in dem Zusammenhang nicht stimmen kann wenn die parallelisierte Ausführung bei Programmen im laufe der Zeit dennoch steigt. Wenn also nicht mehr Kerne genutzt wurden dann weil man nicht bereit war mehr in die Software Entwicklung zu investieren und nicht weil nicht mehr möglich gewesen wäre.

Einfach nein! Das wäre lustig, wenn man sich im IT-Alltag nicht wirklich mit solchen Aussagen herumschlagen müsste.

Genau so wenig kann der Quadcore zu 400% ausgelastet werden denn wie will man auf mehr als 100% kommen? Wird nur ein Kern ausgelastet ist der Quadcore lediglich zu 25% ausgelastet also nicht die Kern und die CPU Auslastung durch einander würfeln denn sonst sind wir wieder genau dort was ich schonmal für Tests kritisierte. Man steckt immernoch im Singlecore Zeitalter fest.

Kommt drauf an wie man die Auslastung definiert.

 

[Pure Existenz]

Der Preis ist klasse. Wenn der dann weiter sinkt, geht der weg wie warme Semmeln.

 

[blackiwid]

Ob AMD sich da nicht vertut nur aufgrund Intel die Preise zu drücken? Die brauchen schon gewisse Gewinne um auch in Zukunft liefern zu können.

Was glaubst du warum Deutschland aktuell quasi nen 0 Zins zahlt auf ihre Schulden mit Inflation so die Schulden real abbaut und teilweise sogar nominal Minuszinsen zahlen musste?

Weil Schulden immer anhand des Umsatzes berechnet werden.

Sie haben aktuell soweit ich das sehe ca. 2Milliarden Schulden. (die zahl ist von 2015 wird schon bisschen anders sein aber mir gehts nur ums prinzip).

Letztes Jahr hatten sie nen Umsatz von 5 Milliarden und 40mio Dollar Gewinn.

Nun stellen wir uns mal vor amd schafft es durch gute Preise ihren Umsatz zu verdoppeln die naechsten 2 Jaher 10 Milliarden oder sie koennen den Gewinn auf 300mio erhoehen.

Sagen wir mal sie zahlen momentan 5% Zinsen bei doppeltem Umsatz wuerde die Verschuldungsquote sich halbieren.

bei 2millarden Schulden und 5% Zinsen waeren das aktuelle Zinszahlungen pro Jahr 100 Millionen. Nun koennte amd her gehen 2 Jahre 300mio Verdienen *2 und die Schulden auf 1.4mio senken, dann wuerden sie im 3. Jahr nur noch 70 Mio Schulden pro Jahr zahlen.

Oder sie verdoppeln ihren umsatz und muessen dann weil die Schuldenquote gesenkt ist nur noch 3% Schulden zahlen nach 2 Jahren nur noch 60mio Schulden.

Also man spart da dann schon 10mio pro Jahr Zinsenzahlungen ab dann. Ab dem 3. Jahr wirds interessant, ab da koennte AMD ja wenn sie schon wollten deine Taktik fahren und hoehere Preise ab rufen. Bei Doppeltem Umsatz dann tendenziel doppelter Gewinn. also 600 mio Dollar pro jahr.

Man hat dann 3 Kennzahlen ab dann veraendert nach 2 Jahren:
1. 600mio Dollar statt 300 mio Dollar Gewinn
2. Zinszahlungen reduziert um 10mio im Vergleich.
3. Schuldenquote

Dafür hat man noch 600 Mio mehr ABSOLUTE Schulden. (ungefähr).

Das macht natürlich nur Sinn wenn man auch nach den 2 Jahren den höheren Marktanteil auch mindestens halten kann.

Wenn das alles nur ein Strohfeuer ist und danach AMD so zurück fällt das sie absolut unkaufbar werden wie es vor Ryzen war, dann bringt das nichts. Aber dann wäre AMD eh tot unabhängig von ihrer jetzigen Preispolitik, die Schuldner würden nur auf weniger Schulden hängen bleiben das wäre alles oder der Untergang würde bisschen länger dauern.

Die zahlen sind recht wild an den Haaren herbei gezogen hab ein paar zahlen recherchiert den Rest nur ganz wild geschätzt und sicher mit sehr großem Fehler.

Mir gings ums Prinzip. Das ist btw auch warum unsere Politik in Griechenland ne Katastrophe war. sie hatten schon ne hohe Verschuldung von vielleicht (bitte auch hier die zahlen nicht zu genau nehmen) 100% zum Staatsumsatz (heißt da nicht Umsatz ist aber mehr oder weniger das selbe) dann haben wir durch Sozialkürzungen deren Umsatz reduziert um sagen wir mal 50% dadurch hat sich ihre Schuldenquote verdoppelt, obwohl die Zahl sich nicht großartig geändert hat. Um das jetzt zurück zu zahlen müssen sie doppelt so viel % "Gewinn" machen. Staaten tendieren aber eigentlich gar nicht Gewinn zu machen.

Daher brauchen sie dadurch einfach doppelt so lang ne Schwarze 0. Es ist Wahnsinn volkswirtschaftlich und Betriebswirtschaftlich in ne Kriese hinein zu sparen. Und ich rede von echtem Wahnsinn Geisteskrank. Schäuble hätte man in die Klappsmühle einsperren müssen. (der gefährlichste Mann Europas, und Olaf Schäuble ist ja leider kein deut besser)

Aber ja komm vom Thema ab.

Sind btw auch keine Überlegungen von AMD spezifisch, so machen das fast alle großen, habe irgendwelche Steuern auf Gewinne da noch nicht mal eingerechnet. Amazon fuhr auch Ewigkeiten mit Minus weil man den Umsatz (Marktmacht) erweitern will.

 

[powercf]

Muss das wirklich immer noch diskutiert werden oder fragst du aus ernstem Interesse?

Ich frage aus ernstem Intresse, und ich denke es sollte noch diskutiert werden. Schöne Prozessoren sind sinnlos ohne Software, die sie völlig benutzen kann.

Wurden noch nicht genug Anwendungsgebiete hier beschrieben? Kleine Liste gefällig? Die können auch noch viiiieeel mehr Kerne auslasten, man muss das Problem nur ordentlich skalieren.

Zu viele Anwendungen. Viele können 32 Kerne nicht „gut belasten“, wie gefragt. Wenn ich „gut belasten“ schreibe, meine ich, dass die Kerne benutzt wird um Programmfortschritt zu machen. Wir können nicht von „gut belasten“ reden, wenn
a) die Software skaliert auf die Anzahl der Kerne nicht, wegen zu viel synchronisierten Codes, zwischen-Thread-Kommunikation, usw.
b) die Leistung der Software wird von anderswo begrenzt (Speicher, Festplatte, Netzwerk, …)

OpenFOAM

https://www.cfd-online.com/Forums/hardware/198378-openfoam-benchmarks-various-hardware.html
Xeon Gold 6148 (20-Kern-Prozessor) - Laufzeit mit 8 Threads: 136 Sekunden, 20 Threads: 98 Sekunden ⇒ 56% die Leistung pro Thread von 8 ⇒ 20 Threads. Ein Thread der letzten 12 ist im Schnitt 39% so nützlich als ein der ersten 8.

2x Epyc 7301 (16-Kern-Prozessor) - Laufzeit mit 16 Threads: 66,5 Sekunden, 32 Threads: 42,6 Sekunden ⇒ 78% die Leistung pro Thread von 16 ⇒ 32 Threads. Ein Thread der letzten 16 ist im Schnitt 56% so nützlich, als ein der ersten 16.

AcuSolve

ich habe keine gute Benchmarks gefunden, aber auf Seite 10 hier: https://altairatc.com/na/2012Presentations/PDFs/HPC Advisory Council.pdf
3,75 Jobs pro Tag mit sechs Kerne, 4,75 Jobs pro Tag mit 12 Kerne ⇒ 63% die Leistung pro Kern von 6 ⇒ 12 Kerne. Ein Kern der letzten 6 ist im Schnitt 27% so nützlich, als ein der ersten 6.

Fluent

https://www.cfd-online.com/Forums/hardware/196400-amd-epyc-cfd-benchmarks-ansys-fluent.html
ich benutze nur die erste Ergebnisse
2x Epyc 7301 - 24 Threads: 92,6 Sekunden, 32 Threads: 74,4 Sekunden ⇒ 93% die Leistung pro Thread von 24 ⇒ 32 Threads. Ein Thread der letzten 8 ist im Schnitt 73% so nützlich, als ein der ersten 24.

andere Ergebnisse hier:
https://www.ansys.com/solutions/sol...-spray-guided-gasoline-direct-injection-model
16 Kerne: 133,5910; 32 Kerne: 197,1477 ⇒ 74% die Leistung pro Kern von 16 ⇒ 32 Kerne. Ein Kern der letzten 16 ist im Schnitt 48% so nütlich, als eir der ersten 16.

PowerFlow, XFlow

nichts gefunden

Palabos

Benchmarks gefunden, aber sie sind alle mit Vier-Kernern durchgefürt. Nützlos.
http://wiki.palabos.org/plb_wiki:benchmark:cavity_n100

Ateles

Seite 5: https://pop-coe.eu/sites/default/files/pop_files/pop-ar-ateles.pdf
Cray XC40. Der Computer is sehr specialisiert, und ich denke diese Ergebnisse sind nicht für Threadripper relevant.
24 Kerne: 15, 16 Kerne: 10 ⇒ 100% der Leistung pro Kern von 16 ⇒ 24 Kerne
Sehr gute Skalierbarkeit. Die Software muss gut geschrieben werden.

StarCCM+, ICEM, Polyflow

nichts gefunden


Ich habe nicht versucht, Benchmarks für Ihre andere Beispiele zu finden. Es ist unwahrscheinlich, dass es Software gibt, die besser als solche Simulationen skaliert.

Keiner skaliert gut auf 32 Kerne (ich ignoriere den Supercomputer). Sogar Fluent gibt nur 24% mehr Leistung für 33% mehr Kerne - von 24 Kerne zu 32 ist es, als ob 30 Kerne effizient arbeiten, während die andere zwei nichts machen. Das ist mit einem acht-Speicher-Kanal EPYC. Es würde schlechter auf Threadripper aussehen.

Das ist so stark von der Anwendung abhängig, dass die Aussage wenig wert besitzt. Natürlich können 32 Kerne vom Speicherinterface begrenzt werden, genau so gut kann das auch mit vier Kernen passieren.

Mit jedem zusätzlichen Kern wird die Belastung des Speicherinteraces größer, und die Nützlichkeit des Kerns weniger (außer theoretische Anwendungen, die Speicher nicht zugriffen).

Also auch falls man jetzt keine super optimierte Software hat und man nun mit Mulithreading bei einer Anwendung vielleicht "nur" 8 Kerne auslastet, besteht bei 32 Kernen immer noch die nette Möglichkeit, mehrere andere Anwendungen parallel (=Multitasking) laufen zu lassen (wenn nicht sogar die besagte 8-Kern-Anwendung gleich mehrfach auszuführen)

Derzeit laufen 215 threads auf meinem billigen 4-Kern-Laptop. Man braucht viele Kerne nicht, um viele Threads laufen zu lassen. Der Vorteil 32 Kerne zu haben, ist wenn man sie belasten kann. Aber mehr Kerne hinzuzufügen ohne den Rest des Computers schneller zu machen, macht nur einen Flashenhals.



Was AMD gerade macht, gefällt mir. Ich bin Computer-Enthusiast, und bin froh, dass 8, 16, 32 und 64 Kern-Computer jetzt kaufbar (oder fast kaufbar) sind. Ich sehe klar, dass Multithread-Programmierung die Zukunft (und Gegenwart tatsächlich) ist. Trotzdem denke ich, dass der 2990X eine sehr sehr begrenzte Benutzung haben wird. Es gibt wenig Software, das gut genug geschrieben wird um diese Kerne effizient zu benutzen. Sogar im Bereich Simulationen, wo es (wahrscheinlich) gute Software gibt, kann man einen 32-Kern Computer nicht „gut belasten“ - wahnscheinlich wegen des Speicherinterfaces.

Wir müssen warten bis die neue Threadrippers verfügbar sind, aber ich erwarte nicht, dass der 2990X ein Segen für den Mittlestand sein wird. Für Simulationen wäre EPYC die bessere Wahl.

 

[cool and silent]

Nur 1500€ für 32 Cores / 64 Threads - das sind gute Nachrichten, das Teil steht definitiv auf der Shopping-Liste.

An alle, die Zweifel haben, aus der Performance auch einen Nutzen ziehen zu können - nicht blind kaufen! Wer entsprechende technisch-mathematisch-naturwissenschaftliche Anwendungen nutzt, die von so vielen Kernen profitieren, wird das entweder selbst einschätzen können oder aus der entsprechenden Community für seinen Anwendungen Erfahrungsberichte bekommen.

 

[dynastes]

Mann, Mann, Mann ... diese CPU macht schon Lust auf mehr. Ich liebäugele gerade ernsthaft mit der Idee, einen TR anzuschaffen. Aber das wäre für mich einfach Habenwill ... äh, Overkill xD

Bin trotzdem gespannt, was TR2 samt 32-, 24- und 16-Kerner leistet, auch mit Blick auf die Zen+-Optimierungen.

 

[Piter73]

@fox40phil Pixinsight z.Bsp., schau mal das Bild im 1. Beitrag an mit der Auslastung. So viel ich weiss, benutzt es alle CPU-Kerne, die zur Verfügung stehen, sollte auch bei 32/64 so sein.

https://www.cloudynights.com/topic/...ormance-using-an-amd-threadripper-ryzen-chip/

Hier mehr zu 1700 und weiter unten Threadripper:
https://www.cloudynights.com/topic/590837-amd-ryzen-1700-8-core-16-thread-pixinsight-performance/

Wie es bei z.Bsp. Deepskystacker oder Fitswork aussieht müsste ich mal nachforschen.

 

[Müs Lee]

Zu viele Anwendungen. Viele können 32 Kerne nicht „gut belasten“, wie gefragt. Wenn ich „gut belasten“ schreibe, meine ich, dass die Kerne benutzt wird um Programmfortschritt zu machen. Wir können nicht von „gut belasten“ reden, wenn
a) die Software skaliert auf die Anzahl der Kerne nicht, wegen zu viel synchronisierten Codes, zwischen-Thread-Kommunikation, usw.
b) die Leistung der Software wird von anderswo begrenzt (Speicher, Festplatte, Netzwerk, …)

Du hast gefragt, welche Programme 32 Kerne gut auslasten können. Das kann prinzipiell jedes, das einfach 100% Last auf jeden einzelnen Kern knallt wie Prime95, ohne dass etwas nützliches mit der Leistung angefangen wird. Dass bei sinnvollen Anwendungen, die von anderen Faktoren abhängig sind wie Speicherdurchsatz (RAM, Festplatte...) oder Netzwerk zwingend irgendwo irgendwann ein Engpass entsteht, wenn der Prozessor die Aufgabe schnell genug abfertigt, ist klar.

https://www.cfd-online.com/Forums/hardware/198378-openfoam-benchmarks-various-hardware.html
Xeon Gold 6148 (20-Kern-Prozessor) - Laufzeit mit 8 Threads: 136 Sekunden, 20 Threads: 98 Sekunden ⇒ 56% die Leistung pro Thread von 8 ⇒ 20 Threads. Ein Thread der letzten 12 ist im Schnitt 39% so nützlich als ein der ersten 8.

2x Epyc 7301 (16-Kern-Prozessor) - Laufzeit mit 16 Threads: 66,5 Sekunden, 32 Threads: 42,6 Sekunden ⇒ 78% die Leistung pro Thread von 16 ⇒ 32 Threads. Ein Thread der letzten 16 ist im Schnitt 56% so nützlich, als ein der ersten 16.

Die kleinen Tests haben wenig Aussagekraft über die allgemeine Skalierbarkeit, vor allem bei (sehr) großen Problemen. Wie gut ein Modell skaliert ist erstens abhängig vom zu lösenden Problem und vom Lösungsalgorithmus, zweitens vom Aufbau des Rechners.

Beispiel zum ersten Punkt: Ich habe eine Weile viskoelastische Fluide mit OpenFOAM simuliert, die Modelle lagen bei 500k (meistens) bis 2M (selten) Zellen und wurden auf einem Cluster mit lediglich 24 Kernen berechnet. Der verwendete Lösungsalgorithmus war PCG, der in OpenFOAM ab 10k Zellen pro Thread gut skaliert. Andere wie GAMG skalieren erst bei 100k gut, können darüber aber andere Algortihmen locker in die Tasche stecken. Das erkauft man sich dagegen mit höherer Instabilität, also muss man ggf. das Verfahren etwas bändigen und wieder Performance aufgeben. Darüber hinaus spielt die Zerlegung des Rechengebietes eine tragende Rolle. So ist beispielsweise eine Zerlegung eines dreidimensionalen Gebiets in parallele Scheiben nicht optimal. Eine Zerlegung in annähernd gleich große Würfel schon eher, weil somit die Kommunikation zwischen den Threads minimiert wird.

Zum zweiten Punkt: Ein Prozessor ist nur so gut wie die ihn umgebende Infrastruktur, sobald er darauf angewiesen ist (dh quasi immer). Reicht der RAM nicht aus, muss auf die Festplatte/SSD ausgelagert werden, was die Rechenzeit massiv beeinträchtigt. Passt das Problem ganz in den Cache, erreicht man einen superlinearen Speedup, dh das Verhältnis zwischen Speedup und dem Faktor von verwendeten Kernen erreicht einen Wert größer als eins. Fiktives Beispiel: 32x mehr Kerne ergeben einen Speedup von 33. Ist die Kommunikation zwischen CCX, Prozessoren auf einem Node oder zwischen verschiedenen Nodes/Blades zu lahm, krankt die gesamte Berechnung. Wird ein Thread schneller fertig als andere, muss er trotzdem auf die anderen warten, bis alle fortfahren können.

Cray XC40. Der Computer is sehr specialisiert, und ich denke diese Ergebnisse sind nicht für Threadripper relevant.
24 Kerne: 15, 16 Kerne: 10 ⇒ 100% der Leistung pro Kern von 16 ⇒ 24 Kerne
Sehr gute Skalierbarkeit. Die Software muss gut geschrieben werden.

Ich habe nicht versucht, Benchmarks für Ihre andere Beispiele zu finden. Es ist unwahrscheinlich, dass es Software gibt, die besser als solche Simulationen skaliert.

Keiner skaliert gut auf 32 Kerne (ich ignoriere den Supercomputer). Sogar Fluent gibt nur 24% mehr Leistung für 33% mehr Kerne - von 24 Kerne zu 32 ist es, als ob 30 Kerne effizient arbeiten, während die andere zwei nichts machen. Das ist mit einem acht-Speicher-Kanal EPYC. Es würde schlechter auf Threadripper aussehen.

Wie oben geschrieben: Diese Tests zeigen nur einen punktuellen Ausschnitt des Programmverhaltens. Die Rahmenbedingungen haben einen sehr starken Einfluss auf die Performance, sodass man daraus nur einen begrenzte Aussagekraft ziehen kann. Man kann problemlos eine Simulation dergestalt aufbauen, dass sie perfekt auf 32 Kernen skaliert. Wie gut bspw. OpenFOAM unter bestimmten Bedingungen skalieren kann, zeigt der folgende Link:

https://www.hpc.ntnu.no/display/hpc/OpenFOAM+-+Performance+on+Vilje

Die Tests über eine große Bandbreite haben schon mehr Aussagekraft, aber eben auch wieder nur für den Solver, das Modell und den Rechner/Cluster. Prinzipiell gilt natürlich: je mehr Prozessortakt, Speichermenge und -durchsatz, desto besser. Kerne bringen nur bis zu einem gewissen Punkt einen Mehrwert, über den hinaus die Kommunikation zwischen einzelnen Threads zu viel Zeit beansprucht und die Rechendauer wieder in die Höhe treibt.

Ganz allgemein lassen sich sehr viele Vorgänge mittels eines linearen Gleichungssystems darstellen, diskretisieren und durch ein direktes Verfahren lösen oder durch ein iteratives Verfahren approximieren. Diese sind inhärent sehr gut parallelisierbar, abgesehen von sequentiellen Vorgängen wie Initialisierung, Speichern etc. Für Struktursimulationen mittlerer Größe (Größenordnung 1-2M Elemente) wäre ein Threadripper mit 32 Kernen schon geeignet. Mit 200k Elementen kann man prinzipiell auch mit 4-8 Kernen gut auskommen, sofern die Vorgänge nicht zuuu komplex werden (Kontakt, Bruchmodellierung etc, dann wirds lustig). Die allermeisten Mittelständler handhaben es so für die meist relativ überschaubaren Simulationen, zumal die Lizenzen für mehr Kerne massiv Geld kosten. Für Strömungssimulationen größeren Ausmaßes ist der TR zugegebenermaßen nicht perfekt, aber nicht prinzipiell ungeeignet. Sofern der Speicherbedarf/-durchsatz halt passt, das ist wiederum individuell.

 

[Wadenbeisser]

Wie bereits geschrieben, du solltest dir die Definitionen von Multithreading und Multiprocessing anschauen und ich erweitere auf Multitasking. Du hast da einige Dinge derart durcheinander, dass man deine Äußerungen als irgendwie richtig und irgendwie falsch lesen kann.

Kommt drauf an wie man die Auslastung definiert.

Ähm ja, da du in dem Zusammenhang mit Multiprocessing ins Spiel bringst tippe ich darauf das du dich auf die Hardware beziehst, dummer weise sind wir aber bei der Software. An der Stelle ist auch doll das du auf das Multitasking erweiterst um das es die ganze Zeit schon geht.

Die Auslastung kann man auch definieren wie man will, ist etwas ausgelastet dann liegt dessen Auslastung bei 100%. bezieht man sich auf den Kern ist es eben dessen Auslastung und bezieht man sich auf den Prozessor sind es alle Kerne zusammen.

Das ist das Gleiche wie mit einem 5 Minuten Ei.
Ein 5 Minuten Ei kocht 5 Minuten bis es fertig ist. Wie lange brauch man für 4 Stück?

 

[Taxxor]

5 Minuten Ei.
Ein 5 Minuten Ei kocht 5 Minuten bis es fertig ist. Wie lange brauch man für 4 Stück?

Ich würde hier sogar mal behaupten, um es auf die Kernskalierung zu beziehen, dass man länger braucht, je mehr Eier man benutzt.

Jedes Ei im Topf nimmt Wärme des Wassers auf. Bei einem zu 4 Eiern fällt das wohl nicht ins Gewicht, aber wenn ich jetzt ein Ei gegen 16 Eier in einem Topf habe, würde ich vermuten, dass die 16 Eier etwas länger brauchen, da sie dem Wasser 16x so viel Wärme entziehen und so die Wassertemperatur über die erste Minute(je nach Leistung der Herdplatte) nach dem Hineinlegen niedriger ist, als wenn nur ein Ei drin liegt.
Hier macht es zeittechnisch dann vielleicht mehr Sinn, 16 Töpfe mit jeweils einem Ei anzustellen, das angesprochene Multitasking eben. Die 16 in einem Topf wäre dann das Multithreading.

 

[Wadenbeisser]

Das ist aber das Problem des Wasser/Eierkochers und das er für die Anzahl nicht leistungsfähig genug ist um die Temperatur zu halten.

 

[new Account()]

Könnt ihr bitte aufhören? Das zu lesen tut echt weh ...

 

[Taxxor]

Was denn? Ist doch mal was anderes als Autovergleiche

 

[Piktogramm]

Ähm ja, da du in dem Zusammenhang mit Multiprocessing ins Spiel bringst tippe ich darauf das du dich auf die Hardware beziehst, dummer weise sind wir aber bei der Software. An der Stelle ist auch doll das du auf das Multitasking erweiterst um das es die ganze Zeit schon geht.

Um was es dir geht ist kaum nachvollziehbar, da du Begrifflichkeiten durcheinander wirfst / falsch verwendest.

Bei deinem Geschreibsel rund um die Auslastung bewegst du dich einfach nur in deiner kleinen Welt.

 

[Taxxor]

@Piktogramm
Dann erläutere doch mal, was Multitasking für dich ist, wenn nicht das gleichzeitige Ausführen mehrerer Tasks/Anwendungen.
Denn nichts anderes hat @Wadenbeisser gesagt.

Multithreading = n Threads = Einen Task auf mehrere Threads aufteilen, um den Task zu beschleunigen.
Multitasking = n Tasks = Mehrere Tasks auf einmal ausführen, um die Threads auszulasten.

Wenn eine Anwendung durch Multithreading keine 32 Kerne auslasten kann, weil sie nicht so programmiert ist, dann kann man 32 Kerne trotzdem durch Multitasking auslasten indem man eben 4 Anwendungen laufen lässt, die jeweils nur 8 Kerne nutzen.

 

[Wadenbeisser]

@Piktogramm
Es ging die ganze Zeit schon um die Auslastung des Multicore Prozessors durch die Software und die verschiedene Möglichkeiten der Software Basis die Rechenleistung abzurufen.
Des weiteren ging es meinerseits darum das die Möglichkeiten durch die Software bei Tests ignoriert werden, eben wie zu Zeiten wo das keine sonderliche Relevanz hatte. Dem Singlecore Zeitalter.
Im übrigen ist Multitasking heute eher die Regel anstatt die Ausnahme.
Das angesprochene Streaming Beispiel wo das Spiel und die Video Berechnung parallel laufen => Multitasking
Arbeiten, nebenher den Browser offen haben und im Hintergrund werkeln Update, Virenscanner und Co => ebenfalls Multitasking
Immer wieder traurig anzusehen wieviele bis heute noch in den alten Denkstrukturen fest hängen aber auch nicht wirklich verwunderlich.

Ergänzung (30. Juni 2018)

@Taxxor
Eine schöne Zusammenfassung deinerseits.
Um mal ein Beispiel der damaligen Test zu liefern, der berüchtigte iTunes Konvertierungstest.
Ja das Programm konnte nur einen Kern nutzen und entsprechend lange dauerte es die Titelliste abzuarbeiten aber was hindert einen daran die Liste bei einem Quadcore auf 4 Instanzen des Programms aufzuteilen und die Konvertierung so nicht unerheblich zu beschleunigen? Hier sind wir wieder beim Punkt Multitasking.
Der sture Tunnelblick auf die Parallelisierung des Codes und die Einzelkern Leistung lässt die Leute jegliche weitere Möglichkeiten ignorieren.

 

[Taxxor]

auf 4 Instanzen des Programms aufzuteilen und die Konvertierung so nicht unerheblich zu beschleunigen?

"nicht unerheblich" ist aber noch nett umschrieben, der Prozess läuft genau viermal schneller.

 

[Hotstepper]

Man muss sich nichts vor machen. Die meisten gängigen Aufgaben am PC sind eben low Thread lastig.

Wirst du dann zu den Überraschten zählen, wenn Adobe und co mit der nächsten Version ihrer Softwares deutlich verbesserten Multicore support liefern werden, weil jetzt endlich die Hardwarebasis da ist, oder siehst du das auf breiter Front kommen?

Ich frag nur weil ich mich an Deine Posts erinnere, in denen du geklagt hast, dass man die 12 Threads deines Test Ryzen nicht ausgelastet bekommt, kurz bevor du, offensichtlich aus Prestige Gründen wie du oben durchscheinen lässt zum 18 Kern Flagschiff gegriffen hast.

 

[Krautmaster]

ne ich hab offensichtlich hauptsächlich wegen meinem mehrfach erwähnten FFMPEG UseCase zum 18C gegriffen - und wegen einem verhältnismäßig guten Angebot (<1500 für den 18C).

Mir solls recht sein wenn Adobe (Lightroom) mal endlich mit mehr Kernen was anfangen kann - aber bezweifle ich irgendwie imho gibts mehr als 2 Kerne nicht erst erst seit Gestern.

Edit: Mein Ryzen hat 16 Threads und war für denselben FFMPEG Usecase da (da sind 16T Auslasten auch nicht das Problem). Mit Lightroom schaffst das aber nicht, selbst Premiere wird schwer bzw nur nen Bruchteil der Funktionen da (zb Export) nutzt das wirklich aus...
Klar wäre es schön wenn eine Trendwende stattfindet und gerade auch Profitools wie CAD Programme endlich mal bei der normalen Konstruktion, laden von BGs usw mal alle Kerne nutzen und nicht nur einen.

Ich sehe es aber wie der 8auer. 8 Kerne würden im Normalfall reichen, von schnelleren Kernen und mehr Takt profitiert jede App, nicht nur eine von 100.