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

[Humptidumpti]

Die Hardwarebasis war im professionellen Bereich (dem haupt Einsatzbereich von Adobe und Co.) schon seit min. 10 jahren da. Wenn jetzt etwas noch nicht großartig Multi Core optimiert ist bringt es entweder nix oder es lohnt sich schlichtweg nicht. (Sei es aus User Sicht oder monetär dem Programmierer über)

Es ist ja nicht so als seien Mehrkerner erst dieses Jahr plötzlich aufgeploppt. Klar ist es gut das immer mehr Software auf n+ Kerne optimiert wird, aber hier jetzt irgend eine Revolution zu erwarten ist m.E. nach übertrieben.

 

[Krautmaster]

ich denke wer schon mal Software entwickelt hat oder gar täglich selbiges tut kann man sich da auch etwas hineinversetzen. Kaum ein UseCase bietet sich da wirklich an den Aufwand zur Parallelisierung zu treiben. Wenn dann noch Kostendruck da ist...

Zudem macht man selten eine komplette Neuentwicklung die da meist nötig wäre. Die Basis wird oft nicht weiter angefasst sondern nur Code drum rum fabriziert. Oft ist die Basis dann schon an die 20 Jahre alt.

Fakt ist aber auch dass es auf lange Sicht nicht mehr viel schneller pro Kern werden kann. Da müsste mehr Takt her. Ergo muss man in die Breite gehen und wenn es nun günstig 16 und mehr Kerne gibt dann wird das natürlich lukrativer auch für die Softwareentwicklung. Aber kaum eine Entwicklungsumgebung nimmt das dem Entwickler ab. Multithread bedeutet man muss sich schon deutlich mehr überlegen bei dem was man tut, wann es sich anbietet, wann nicht. Es wird nie so wenig Aufwand sein wie stumpf seine Funktionalität runterzuprogrammieren.

Edit. Man muss sich nur mal überlegen wie groß der gefühlte Geschwindigkeitsboost beim Wechsel von HDD auf SSD war. Weil ein Flaschenhals, die Platte, plötzlich quasi eliminiert war. Das hat kein Dualcore oder Mehrkern CPU geschafft, was gut zeigt wie sehr generell Software über einen Thread limitiert wird. Würden neue Transistoren und neues Material plötzlich 100Ghz ermöglichen gäbe es ggf auch so einen Boost.

 

[pipip]

Wieso müssen Optimierungen immer im Bereich High-Level Sprachen passieren ?
Software basiert nicht nur aus Java, C und Co. Im Bereich Compiler und Betriebsystem wäre es interessant. Wer sagt dass man aus 2 oder mehr Cores nicht ein Thread machen könnte. Ein Corr berechnet zB, ein anderer holt die Befehle, addressiert ect. Bisher macht eine CPU viele Operationen. Wieso das zB nicht eventuell aufteilen.

Wenn man immer mit den selben Ausagen kommt, geht nicht, wird sich im Bereich Software nie was ändern.

PS der Beitrag ist nur ein Impuls zum Weiterdenken.

 

[new Account()]

Ein Corr berechnet zB, ein anderer holt die Befehle, addressiert ect. Bisher macht eine CPU viele Operationen. Wieso das zB nicht eventuell aufteilen.

Das wird innerhalb der einzelnen Cores schon möglichst effizient via Pipes gemacht.
Glaubst du CPU- und Software-Entwickler benutzen Multithreading nur zum Spaß, weil ihnen das besser gefällt?
Genau weil da sehr starke Optimierungen stattfinden, gibt es auch Sicherheitslücken wie man eben die letzten Monate mitbekommen hat.

 

[Piktogramm]

@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.

Du wirst dich nicht damit zufrieden geben wenn ich für dich die entsprechenden Wikipediaartikel suche und verlinke? Würdest du und @Wadenbeisser sicher selber tun..

Multitasking beschreibt die Fähigkeit mehrere Prozesse (*) quasi (!!) gleichzeitig auszuführen. Genau genommen nicht wirklich gleichzeitig sondern über zeitliches Multiplexing. Dieses Multiplexing ist normalerweise für die Echtzeitanforderungen von Menschen schnell genug, sodass von gleichzeitg gesprochen werden kann. Das Fass um die Anforderungen "harter Echtzeit" mache ich jetzt nicht auf.
Multiprocessing hingegen beschreibt die Fähigkeit mehre Prozesse / Tasks wirklich gleichzeitig, daher auf je dedizierter Hardware auszuführen. An sich will man mit modernen Mehrkernprozessoren genau das erreichen. Sehr häufig kann man jedoch die Lösung einzelner Probleme nicht derart aufspalten, dass die resultierenden Prozesse voneinander unabhängig sind. Selbst bei augenscheinlichen einfachen Problemen wird das Ganze daher auch sehr schnell extrem komplex(**).
Multithreading ist auf Hardwareebene Fähigkeit auf einem Prozessorkern mehrere Prozesse gleichzeitig(***) auszuführen. Auf ebene von Software bezeichnet es in der Regel das Konzept, dass ein Prozess sich aus mehreren Threads zusammensetzen kann. Wobei die Threads innerhalbs ihres Prozesses auf gemeinsame Ressourcen zugreifen können. Prozesse haben normalerweise keine Möglichkeit der gemeinsamen Ressourcennutzung, entsprechend wird Interprozesskommunikation notwendig (da sind sie wieder, die Probleme vom Multiprocessing)

(*) Prozess und Task werden sprachlich analog verwendet. Typischerweise ist die Bezeichnung in der Windowswelt Task und alles was nur ansatzweise ausschaut wie Unix bezeichnet den Spaß meist als Prozess. Multitasking und Multiprocessing wird dennoch fachlich getrennt..

(**) Gern wird die optimale Strategie um das Problem maximal verteilt rechnen zu können auch komplexer als das die Lösung des eigentlichen Problems. An der Stelle rückt man dann von maximal verteiltem Rechnen ab und schwenkt auf eine begrenzte Anzahl an Threads um.

(***) je nach Implementierung kann man sich über "gleichzeitig" fröhlich fetzen...

 

[cool and silent]

@pipip

Die Entwickler von CPUs, Compilern und Betriebsystemen kenne diese Themen alle. Weltweit beschäftigen sich zigtausende von Leuten genau mit diesen Fragen.

 

[Piktogramm]

Wieso müssen Optimierungen immer im Bereich High-Level Sprachen passieren ?
Software basiert nicht nur aus Java, C und Co. Im Bereich Compiler und Betriebsystem wäre es interessant. Wer sagt dass man aus 2 oder mehr Cores nicht ein Thread machen könnte. Ein Corr berechnet zB, ein anderer holt die Befehle, addressiert ect. Bisher macht eine CPU viele Operationen. Wieso das zB nicht eventuell aufteilen.[...]

Moderne CPU Kerne haben bereits mehrere, spezialisierte Funktionseinheiten die auf Teufel komm raus optimiert werden. Das Holen der nächsten Befehle / Daten erfolgt bereits über spezialisierte Bereiche der CPU (Spectre und Meltdown zeigen wie abgefahren komplex der Spaß bereits ist) während die Rechenwerke der CPUs die eigentlichen Berechnungen ausführen.

Darauf hat man meines Wissens aber keinen Einfluss, selbst wenn man Assembler schreibt. Ansätze hab es aber z.B. mit Itanium bzw. der IA64 Architektur von Intel. Wirklich der Knaller war es nicht. Es gibt auch jetzt immer mal wieder Forschungsprojekte dazu.

 

[Taxxor]

@Piktogramm

So, jetzt hast du jeweils 5-zeilige Absätze zu Multithreading und Multitasking als Erklärung geliefert, die ziemlich exakt das aussagen, was ich in meinem Post kurz und knapp in einer Zeile auch gesagt habe.

Was soll ich oder Wadenbeisser jetzt durcheinander werfen?

Und zum Multiprocesing haben wir gar nichts gesagt, darum ging es ja auch nicht.

 

[Piktogramm]

Ich zitiere dich einfach mal:

@Piktogramm
[...]
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.
[...]

Du hast da grundlegend einen anderen Sachverhalt geschrieben und nutzt Fachbegriffe auch noch falsch.

Tasks/Prozesse können in Threads untergleidert werden, typischerweise hat das aber keinen Einfluss auf die Ausführungsgeschwindigkeit in dem Sinne wie du es meinst. Daher auch meine Erklärung von Multiprocessing. Denn das was du diskutierst ist (dort wo es verständlich ist) Multiprocessing und nicht Multithreading.
Multitasking... Tasks/Prozesse bestehen bzw. können aus Threads bestehen. Prozesse können Threads jedoch NICHT auslasten. Was du da geschrieben hast ist erstaunlich absurder Unsinn der mit Multitasking nichts zu tun hat.

 

[pipip]

Das wird innerhalb der einzelnen Cores schon möglichst effizient via Pipes gemacht.

Mir ging es ja auch darum, dass das nicht nur innerhalb eines einzelnen Cores effizient gemacht wird, sondern eben unter eine Gruppe von Cores.
Ich habe da auch speziell an das Thema VISC gedacht gehabt.

 

[new Account()]

Wie denn?

 

[pipip]

Ich zitiere mich selbst:
"PS der Beitrag ist nur ein Impuls zum Weiterdenken. "

Mir ging es Grundsätzlich eher um die Aussagen, dass etwas nicht geht, weil es "immer" so war. Ob es geht, ist natürlich eine ganz andere Frage, die ich nicht beantworten kann. Deshalb auch der Implus, auf die es scheinbar Antworten/Meinungen gibt

In meiner naiven Vorstellung, wäre es cool, wenn man aus einem Ryzen 8 Core einen virtuellen 4 Core macht, der pro Thread dann bsp "schneller" wäre.
Sicher gibt es da genug Forscher, die sich den Gedanken schon angeschaut haben. Aber es wäre etwas, was MultiCore Chips mehr Bedeutung zusprechen könnte.

 

[Piktogramm]

@pipip
"War schon immer so" ist auf fachlicher Ebene wirklich kein Argument. Es sind schon knallharte Restriktionen die da wirken. Die trivialen Lösungsansätze werden in der Regel auch schon genutzt.
Auch das Zusammenschalten einzelner Cores wird bedingt schon genutzt.

[Quelle: https://techreport.com/review/31366/amd-ryzen-7-1800x-ryzen-7-1700x-and-ryzen-7-1700-cpus-reviewed ]

Die Rechenwerke gibt es mehrfach und sie werden mehr oder weniger parallel genutzt und da praktisch trotzdem nicht alle Rechenwerke gleichzeitig genutzt werden kam man vor einer ganzen Weile auf den Trichter den CPUs Multithreading beizubringen.(*)
Wobei aktuelle CPUs schon darauf optimiert werden, dass die durch zusätzliche (oder breitere) Rechenwerke gewonne Performance im Verhältnis zum Aufwand steht (Komplexität der CPU und Bedarf elektrischer Leistung).
(*) Real ist es "minimal" komplizierter und verschiedene Architekturen unterscheiden sich da in "Details"

 

[StefVR]

Das Problem ist immer das berühmte Bottleneck. Man kann alles noch so toll parallelisieren, wenn alle Threads auf einen immer warten müssen bringt es nichts leider und die Single Thread Performance ist wieder King.

 

[Wadenbeisser]

@Piktogramm
Glückwunsch, alles was du schreibst bezieht sich auf die Hardware ebene oder besser gesagt auf einen Kern denn Multitasking geht natürlich auch mit einem Kern mit genau den von dir beschriebenen Einschränkungen und mit mehreren Prozessoren ging es dann auch wirklich parallel. Das wäre dann der technische Stand von vor fast 20 Jahren....
Letztendlich ist es aber genau das wovon eben nicht die Rede war denn es ging um die Soft- und nicht um die Hardware. Thema verfehlt.

 

[yummycandy]

as wäre dann der technische Stand von vor fast 20 Jahren....

Wenn man ehrlich ist, gibts das seit 1985. Der Amiga hatte imho immer noch das beste Multitasking. Was auch daran lag, daß Teile des OS im ROM lagen. Die Fenster- und Screenverwaltung* allein, ist bis heute unerreicht.
Und der Witz ist, das ganze ging mit einer CPU mit einem Core.

* -> http://wiki.amigaos.net/wiki/Intuition_Library

 

[Taxxor]

Multitasking... Tasks/Prozesse bestehen bzw. können aus Threads bestehen. Prozesse können Threads jedoch NICHT auslasten.

Du scheinst dich hier die ganze Zeit auf Threads der Software zu beziehen, denn hier wird ein Prozess tatsächlich in viele Threads aufgegliedert(sieht man ja auch im Taskmanager, wo bei mir aktuell 2346 Threads aktiv sind)
Ich beziehe mich auf die Threads als logische Prozessorkerne und derer gibt es beim Threadripper dann nun mal 64 Stück.

Was du da geschrieben hast ist erstaunlich absurder Unsinn der mit Multitasking nichts zu tun hat.

Ich beziehe mich ganz einfach nur auf die allgemein gültige Definition des Wortes

Denn das was du diskutierst ist (dort wo es verständlich ist) Multiprocessing und nicht Multithreading.

Deine Erklärung zum Multiprocessing beinhaltete das jeder Task auf dedizierter Hardware ausgeführt wird. Also ein eigener Rechner pro ausgeführtes Programm oder wie soll man das verstehen?

 

[Kalsarikännit]

Im Prinzip braucht es einen Paradigmenwechsel beim Programmieren - anstatt zu überlegen, ob eine Aufgabe parallelisierbar ist sollte eher geschaut werden, ob eine Aufgabe wirklich sequentiell abgearbeitet werden muss.

Beispiel C#: Parallel.For/.Foreach, einfacher kann man man sequentielle Abläufe nicht aufbrechen. Natürlich sorgt deren Einsatz nicht zwangsläufig zu 100% Kernauslastung, man schafft es aber im Prinzip ohne Aufwand, sich dem ganzen Thema Nebenläufigkeit anzunehmen, und „Ängste“ diesbezüglich, wie ich sie bei Kollegen immer wieder feststelle, zu überwinden.

 

[cool and silent]

Beispiel C#: Parallel.For/.Foreach, einfacher kann man man sequentielle Abläufe nicht aufbrechen.

Das vereinfacht aber auch nur sehr oberflächlich die Syntax. Innerhalb der Schleife müssen Zugriffe auf geteilte Resourcen weiterhin verriegelt werden. Race conditions, Locks und alles andere, was Multtreaded Programming aufwändig macht, bleibt weiterhin erhalten.

 

[Kalsarikännit]

^^sicherlich, aber wie oft kommt sowas bei der Brot-und-Butter-Programmierung vor?

Das Parallel.X sicherlich nicht die Kür darstellt ist klar, soll es aber auch nicht. Wenn man aber Einfachstschleifen wie sie einem dauernd begegnen, damit realisiert, hat man oftmals ohne großen Aufwand bei 4Cores gerne mal 20-30% gewonnen, im Prinzip geschenkt.

Die von dir genannten Szenarien existieren natürlich, sind aber zumindest in meinem Bereich zur Zeit eher selten. Da geht es größtenteils darum, einen Sack voller Daten einzeln durch eine API zu feuern, und gerade für so Fälle funktionieren die Parallel.X absolut hervorragend.