[Lerran]

Hallo zusammen,

ich habe mal eine allgemeine Frage zum Thema x86/x64 bzw. CISC-Prozessoren und RISC-Prozessoren (ARM).

Bei CISC-Prozessoren heißt es, dass diese einen komplexen Befehlssatz haben, gegenüber den RISC-Prozessoren. Also müssten die ja eig. "mehr" können sozusagen.
Wenn man sich aber heute mal die ARM-Prozessoren anguckt, wie z. B. den neuen Apple M1, der ja laut Benchmarks sehr schnell und angeblich ebenbürtig gegenüber Intel/AMD sein soll, welchen Vorteil haben dann heute noch CISC-Prozessoren bzw. die x86/x64 Architektur, wenn die ARM-Plattform "genau so viel" kann?

[Homerclon]

Der M1 von Apple ist nur in ausgewählten Szenarien ebenbürtig, und natürlich hat auch dieser seine Bereiche wo dieser überlegen ist.

Folgender Artikel könnte dich interessieren: igorslab.de | Warum Apples M1 Single “Core” Vergleiche grundlegend fehlerhaft sind (mit Benchmarks) | Gastbeitrag

[foobar]

Die „können” beide das gleiche. Der Unterschied liegt darin, wie sie das Ziel erreichen. CISC-Prozessoren haben einen komplexen Befehlssatz und können daher mit wenigen Instruktionen in der Software viele verschiedene Dinge machen. Der Preis dafür ist, dass das Dekodieren der Befehle länger dauert, was u.a. auch die Länge der Pipeline, die Sprungvorhersage und damit die Performance beeinflusst. RISC-Prozessoren verwenden einen reduzierten Befehlssatz. Die Befehle sind schneller dekodiert und ausgeführt und kommen mit kürzeren Pipelines aus, dafür muss man komplexere Aufgaben aber auf mehrere Opcodes verteilen.

Das ist jetzt nur eine Analogie, aber stelle es dir so vor: Eine CISC-CPU kennt den Befehl „MULT”, um zwei Ganzzahlen miteinander zu multiplizieren. Die RISC-CPU dagegen kennt nur den Befehl „ADD” zum Addieren. Will man mit der RISC-CPU also 5 × 3 rechnen, dann muss man das über wiederholte Addition lösen (5 + 5 + 5 ist ja das selbe wie 5 × 3). Die CISC-CPU macht das unter Haube auch, bietet nach außen hin (für die Software) aber einen handlichen Befehl an.

In der nackten Theorie ist CISC aufwendiger und teurer in der Schaltungslogik, kommt dafür aber mit einfacheren Compilern aus. RISC macht die Prozessoren einfacher und billiger, dafür muss der Compiler etwas schlauer sein. In der Praxis sind die Grenzen zwischen beiden Architekturen heutzutage allerdings fließend. Das liegt daran, dass keine Architektur der anderen in jedem Fall klar überlegen ist und man versucht, eine gesunde Mischung zu finden. Der M1 von Apple ist bspw. deshalb praktisch die einzige ARM-CPU, die mit aktuellen x86-CPUs mithalten kann, weil er halt am Ende dann doch nicht so wahnsinnig viel günstiger in der Entwicklung und Fertigung ist. Apple hat den IMHO hauptsächlich deshalb entwickelt, weil sie damit die Hardware besser kontrollieren und die vertikale Integration erhöhen können. Es gefällt denen halt nicht, dass andere Leute auch Prozessoren von Intel kaufen dürfen. Und sie können sich den Luxus einer eigenen CPU leisten, weil sie halt – je nach Metrik – die reichste Firma der Welt sind.

EDIT: Das Blatt wendet sich übrigens, wenn man grundlegend andere Anforderungen hat. Wenn z.B. geringer Energieverbrauch oberstes Gebot ist und darunter im Zweifel auch die Performance leiden darf (und zwar gewaltig), dann sind RISCs eindeutig die bessere Wahl. Da kommen wir dann in den Bereich der Mikrocontroller, die praktisch allesamt mehr oder weniger der RISC-Architektur folgen (RISC-V, ARM, Xtensa, MIPS, etc.)

[Lerran]

Vielen Dank an euch beiden! Ist ja interessant mit dem Benchmark. Also eig. mal wieder mehr Marketing
Der Vergleich mit dem Addieren und Multiplizieren ist ein echt gutes Beispiel, foobar. Jetzt habe ich das ganze mal richtig verstanden und verstehe jetzt auch warum Programme für x86/x64 auf ARM nicht "gleich schnell" laufen; weil es ist ja doch eine etwas "andere Sprache" im Grunde mehr oder weniger.

[Cheesecake]

Folgender Artikel könnte dich interessieren: igorslab.de | Warum Apples M1 Single “Core” Vergleiche grundlegend fehlerhaft sind (mit Benchmarks) | Gastbeitrag

Ist ja interessant mit dem Benchmark. Also eig. mal wieder mehr Marketing

Ihr solltet euch von diesem Artikel bitte nicht blenden lassen. Die Zahlen und die grundlegende Erklärung zur Auslastung von Kernen durch SMT mögen jetzt nicht per se falsch sein aber dass der M1-Chip in Benchmarks zu gut wegkäme oder der Vergleich unfair wäre, wird in dem Artikel ziemlich schlecht begründet. Das Problem für den Autor scheint ja zu sein, dass z.B. Cinebench von "Single-Core" spricht und das irreführend wäre, weil ein Core ohne SMT nicht komplett ausgelastet wird und es daher "Single-Thread" heißen müsste aber das ist bestenfalls Erbsenzählerei. So eine wirklich allgemeingültige Nomenklatur gibt es in dem Bereich ja leider nicht aber was der Autor aus diesem Gedanken alles schlussfolgernd, ist wirklich albern.
Jedenfalls ist die vom Autor vorgeschlagene Benchmark-Methode, bei der man einem Kern zwei Threads zuweist, um durch die bessere Auslastung einen "fairen" Vergleich zu erhalten, extrem weit hergeholter Murks. So ein Szenario gibt es schlicht und ergreifend nicht, solange man Mehrkernprozessoren nutzt und es nicht absichtlich und gegen jede Vernunft herbeiführt. Man kann da vielleicht einen Wert ermitteln aber der ist in etwa so relevant wie die Höchstgeschwindigkeit meines Autos im ersten Gang. Wenn ich mal einen Single-Core-Prozessor mit SMT habe, würde der Test ja sowieso automatisch so ablaufen aber da ist ein Vergleich zum M1 jetzt auch nicht wahnsinnig interessant.
In der realen Welt gibt es zwei grobe Szenarien. Entweder mein Workload ist weitestgehend seriell oder er ist parallel. In ersterem Fall ist es vollkommen normal, SMT nicht weiter zu beachten. SMT heißt nicht, dass ein Prozessor einfach so besser ausgelastet wird, sondern es handelt sich um eine Technik, die nur im Zusammenhang mit Multithreading ihren Nutzen zeigen kann, wie man ja auch am Namen erkennen kann. Wenn ich aber bspw. ein Spiel habe, dass seine Berechnungen nur in einem Thread ausführt, dann bringt mir SMT natürlich nichts und solche Szenarien sind durch den Single-Core-Benchmark bei Cinebench halbwegs simuliert (jetzt mal abgesehen davon, dass Benchmarks immer ihre Schwächen haben). Wenn ich meinen Workload parallelisieren kann, dann ist es ziemlich selten der Fall, dass ich nur einen weiteren Thread richtig ausnutzen kann. Selbst wenn das aber der Fall sein sollte, würde das Betriebssystem sowieso immer erst einmal physische Kerne belegen und SMT vermeiden. Das heißt, dass selbst der SMT-fähige Prozessor in diesem Szenario "echtes" Multithreading nutzt. Erst wenn alle Kerne einen Thread ausführen, werden die restlichen logischen Kerne genutzt. Das ist bei den üblichen Betriebssystem direkt so eingebaut und wird von einem Programm in der Regel auch nicht geändert. Hier zeigt sich dann auch der Vorteil von SMT, da einem M1 an dieser Stelle die Puste ausgeht. Allerdings ist die CPU dann eventuell auch durch Speicherdurchsatz usw. beschränkt, wenn so viele Threads aktiv sind und daher ist das ein viel sinnvollerer Test als das, was der Autor da vorschlägt und dementsprechend funktionieren auch die meisten Benchmarks wie eben z.B. Cinebench. Der vorgeschlagene Benchmark liefert hier keine sinnvollen neuen Erkenntnisse, da er ein völlig anderes Verhalten erzwingt. Voll ausgelastete physische Kerne zu vergleichen ist einfach keine aussagekräftige Metrik und ich habe keine Ahnung, wie der Autor auf Idee kommt, diesem Aspekt so eine Bedeutung zu geben. Die Performance bei einzelnen Threads ist in der Realität einfach viel wichtiger.
Der M1 ist halt einfach ziemlich gut, wenn es um serielle Ausführung geht aber bei massiver Parallelisierung liefern diverse andere Prozessoren dann eben deutlich bessere Ergebnisse, weil sie mehr Kerne und SMT haben. Das ist keine Verfälschung oder sonst etwas, sondern der Artikel versucht den Bereich, in dem der M1 gut abschneidet, mit merkwürdigen Argumenten die Gültigkeit zu entziehen und durch einen Benchmark zu ersetzen, der weniger relevante Ergebnisse liefert.
Wenn ich mir einen Prozessor kaufe, ist es doch eigentlich auch nicht relevant, ob der jetzt SMT kann, wie viele Kerne er hat oder ob er eine bestimmte Taktrate erreicht. Man kann sich natürlich ein Stück weit an Kennzahlen orientieren aber solche Vergleiche zwischen Herstellern waren noch nie allzu sinnvoll. Was mich am Ende interessiert, ist die Performance in konkreten Anwendungen. Entsprechende Benchmarks zu erstellen ist nicht immer einfach und kleinere Verfälschungen kommen vor aber Benchmarks von Anfang an mit dem Ziel anzupassen, die Stärke einer Hardwarekomponente hervorzuheben, wirkt auf mich manipulativ. Das erinnert mich ein bisschen an Nvidia und ihre Spielereien mit Tessellation, wodurch manche Spiele-Benchmarks in der Vergangenheit irreführend waren, falls sich hier jemand daran erinnert. Dort würde der Autor wahrscheinlich auch so etwas sagen wie: "Nvidia ist in bei Tessellation viel besser. Wir sollten also die Tessellation hochdrehen, damit wir Nvidia-Karten richtig auslasten können. Spiele-Bechmarks ohne Tessellation sind fehlerhaft, da sie Nvidia benachteiligen." Ist für mich zumindest eine ähnliche Denkweise.

Sorry für das lange Geschwafel

[jabu]

Ich möchte Cheesecake im Wesentlichen zustimmen. Man hat sich wohl einmal an der Formulierung "Single-Core" festgebissen und die gesamte Argumentation darauf aufgebaut (was man zwar machen kann, aber wenig hilfreich ist).

Anstatt sich über schlechte Benchmarks zu beschweren, sollte man lieber anerkennen, dass die M1-CPU wohl, nach allem, was man bisher weiß, besonders effizient arbeitet und auch absolut sehr leistungsfähig ist (was natürlich bei stark parallelisierten Workloads seine Grenzen findet).

Sobald man von "Single-Thread" anstatt von "Single-Core" spricht, passt auf einmal alles. Beim M1 ist das natürlich austauschbar, da er kein SMT hat. Hat man SMT, so verhilft es aber nicht zu schnellerer serieller Abarbeitung, sondern nur zu weniger Einbrüchen bei bereits stark paralleler Last. Und dort gehört das Thema auch hin.

Der von igorslab.de durchgeführte bzw. vorgeschlagene Benchmark würde lediglich eine synthetische Kenngröße liefern (da nicht linear über die Anzahl der Kerne hochskalierbar).

[Multithread]

Sobald man von "Single-Thread" anstatt von "Single-Core" spricht, passt auf einmal alles. Beim M1 ist das natürlich austauschbar, da er kein SMT hat. Hat man SMT, so verhilft es aber nicht zu schnellerer serieller Abarbeitung, sondern nur zu weniger Einbrüchen bei bereits stark paralleler Last. Und dort gehört das Thema auch hin.

Was auch gerne vergessen geht, in dem zusammenhang, ist das der M1 Chip den "RAM" direkt auf dem Chip hat. Eingebunden als eine Art L4 Cache.
Es wird vermutet, das dies auch deutlich zur sehr hohen Performance beiträgt.

[Homerclon]

Was auch gerne vergessen geht, in dem zusammenhang, ist das der M1 Chip den "RAM" direkt auf dem Chip hat. Eingebunden als eine Art L4 Cache.
Es wird vermutet, das dies auch deutlich zur sehr hohen Performance beiträgt.

Dafür braucht man keine Vermutung.
Das kann man bspw. auch beim Intel Broadwell mit Iris Pro beobachten, obwohl dort der "L4 Cache" (eDRAM) nur 128MB umfasst.
Einige wünschen sich doch auch CPUs (bzw. APUs) mit HBM.

[jabu]

Was auch gerne vergessen geht, in dem zusammenhang, ist das der M1 Chip den "RAM" direkt auf dem Chip hat. Eingebunden als eine Art L4 Cache.
Es wird vermutet, das dies auch deutlich zur sehr hohen Performance beiträgt.

Es scheint sich doch um separate Chips zu handeln (siehe die von Apple bereitgestellte Abbildung):
https://www.tomshardware.com/news/Ap...ything-We-Know

Das deutet auch in diese Richtung:
https://www.heise.de/news/M1-Macs-RA...h-6006757.html

Golem dazu ("sitzt auf dem gleichen Träger"):
https://www.golem.de/news/apple-sili...11-152384.html

Und Wikipedia:
https://en.wikipedia.org/wiki/Apple_M1

Natürlich sind auch so die Latenzen als geringer als bei einem Mainboard anzunehmen (was den von dir besagten Nutzen stützt). Von einem L4-Cache-Äquivalent sehe ich noch nichts, zumindest solange kein weiterer RAM verbaut wird (ist wohl bisher unüblich). Da ich nicht weiß, wie das Zusammenspiel mit zusätzlichem RAM aussehen würde, möchte ich das nicht von vornherein ausschließen. Es bleibt einigermaßen spannend. Die L1- und L2-Caches sollen größer als sonst üblich sein, insbes. der (sonst eher zu kleine) L1-Cache. Bei kleineren Strukturen und moderatem Takt geht hier natürlich einiges.

Aber solange Apple zugenagelte Produkte verkauft, wird Apple mich nicht als Kunde gewinnen können, auch nicht bei Halbierung des Preises. Ein geschenktes Lesegerät für HTML, PDF etc. würde ich natürlich nutzen. Bis es die für mich interessante Software auf für ARM/iOS gibt, werden wohl noch ein paar Jährchen vergehen, evtl. zu viele.

Da RAM nun mal viele Speicherzellen hat und in dem Package wohl sehr warm werden wird, würde ich mich als Käufer wie ein Hazardeur fühlen, auch bei allem guten Bestreben seitens Apple, ordentliche Qualität abzuliefern. Irgendwie müsste ich notfalls in der Lage sein, den RAM selber zu tauschen, was hier komplett ausfällt, womit mir das Kostenrisiko zu groß wäre.

Außerdem ist 16 GB heutzutage Unterkante. Damit würde ich bei einer langfristigen Investition nicht mehr einsteigen. Momentan oder bei Spielzeug ist das noch anders, und ich denke, dass es sich eben immer noch um schnelllebiges Luxusspielzeug handeln soll. Und dafür genügt der Zielgruppe größtenteils auch die Variante mit 8 GB. Sobald es in ein paar Jahren Besseres gibt, wird sie die Dinger sowieso wie Dreck in die Ecke pfeffern.

Reine Lesegeräte sowie Spielzeug bekomme ich aber deutlich billiger, weswegen mich Apple auch mit diesem Kunstgriff nicht so leicht kriegen wird, außer vielleicht über Bande, wenn mal irgendwo so ein Teil übrig ist, was aber noch ziemlich lange dauern dürfte. Bis dorthin werden die Karten aber neu gemischt sein.

Hinzugefügt:
Viele interessante Details zum M1-SoC, die viele andere Quellen wohl nicht haben, gibt es hier bei elektroniknet.de (vorhin gefunden). Es gibt viel zu wenige dermaßen detaillierte und aufschlussreiche Artikel.

[Lerran]

Wow, danke für eure Ausführungen, echt super interessant

Mal ne allgemeine Frage - wie wichtig ist heutzutage eigentlich noch die Single-Core-Leistung? Sollte heute nicht alles auf Multicore laufen bzw. profitieren?

[foobar]

Mal ne allgemeine Frage - wie wichtig ist heutzutage eigentlich noch die Single-Core-Leistung? Sollte heute nicht alles auf Multicore laufen bzw. profitieren?

Cheesecake hat das schon ein bisschen angerissen: Es Kommt Darauf An™. Die Frage ist, um welche Aufgaben es geht und ob die sich gut parallelisieren lassen.

Mal wieder eine Analogie: Die Frage, ob nicht alles von Multicore profitieren sollte, ist wie die Frage, ob nicht alles von mehr Arbeitskräften profitieren sollte. Auch das hängt von der Aufgabe ab.

Stelle dir mal vor, du solltest mit einer Schaufel einen Brunnen ausheben. Also ein Loch mit einem Quadratmeter Größe und 100 Meter tief. Wenn da 100 Leute gleichzeitig arbeiten, stehen die sich nur gegenseitig im Weg. Vielleicht kann man ein paar Aufgaben verteilen (z.B. schaffen ein paar Leute die ausgehobene Erde weg), aber das eigentliche Buddeln kann mehr oder weniger nur einer gleichzeitig machen. Es dauert also so lange, wie eine Person nun mal braucht, um 100m³ Erde zu bewegen.

Anders sieht es aus, wenn es um einen Bewässerungsgraben geht. 100 Meter lang und nur einen Meter breit und tief. Ist die selbe zu bewegende Menge an Erde (100m³), aber nun können problemlos 100 Leute nebeneinander arbeiten. Jeder schaufelt nur einen Kubikmeter und die Sache ist ruck-zuck erledigt.

Es kommt also auf die Aufgabe an. Manche Sachen kann man einfach nicht gut parallelisieren. Ein Rechenbeispiel wären die Fibonacci-Zahlen, bei denen man ja immer das Ergebnis der vorherigen Berechnung abwarten muss, bevor man die nächste Zahl berechnen kann. Andere Sachen lassen sich prima parallelisieren, z.B. die Suche nach einem bestimmten Eintrag in einer unsortierten Liste: Jeder schnappt sich einen Teil und sucht darin. In der Praxis fallen die meisten Aufgaben irgendwo dazwischen. Manches lässt sich parallelisieren, aber nur bis zu einem bestimmten Punkt. Ab da bringen dann zusätzliche Kerne keinen weiteren Vorteil mehr. Und dann gibt es auch Software, die sich im Prinzip dahingehend verbessern ließe, dass man mehrere Kerne einspannt, aber wo es aus irgendwelchen Gründen nicht gemacht wird. Zum Beispiel weil es alter Code aus der Prä-Multicore-Ära ist, den man nicht anfassen will. Oder weil es auch einfach zu aufwendig ist. Oft muss man nämlich leider ein bisschen Grips einsetzen, um ein Problem so zu zerteilen, dass man es (gut) parallelisieren kann – und auch zusätzliche Probleme lösen (z.B. die Arbeit der verschiedenen Kerne richtig koordinieren). Das geht nicht automatisch, das muss ein Programmierer mit der Zunge im richtigen Winkel machen.

Eine klassische Analogie aus der theoretischen Informatik, um sich die möglichen Probleme vor Augen zu führen, ist die der speisenden Philosophen. Da gibt’s verschiedene Variationen von, ich gebe mal eine: Eine Gruppe Philosophen sitzt im China-Restaurant an einem runden Tisch. Philosophen können entweder denken oder essen. Um zu essen, müssen sie zwei Essstäbchen aufnehmen. Aber es liegt immer nur ein Stäbchen zwischen je zwei Philosophen. Wenn also einer am Essen ist, können seine direkten Nachbarn nicht auch gleichzeitig essen. Und dann kann man halt überlegen, welche Probleme es geben kann und wie man sie löst. Ein Philosoph könnte einfach immer essen und seine Nachbarn verhungern lassen. Dagegen hilft z.B. ein Zeitlimit. Nach einer bestimmten Zeit muss der Philosoph aufhören zu essen und die Stäbchen zurück legen. Aber was ist, wenn er sich dann gleich wieder zum Essen entscheidet, ohne das seine Nachbarn eine Chance hatten, weil sie gerade am Denken waren? Es könnte auch sein, dass immer dann, wenn ein bestimmter Philosoph essen will, einer seiner beiden Nachbarn gerade isst. Mal der linke, mal der rechte. Keiner isst für sich genommen zu lange, aber der arme Kerl in der Mitte hat nie beide Stäbchen zur selben Zeit für sich. Und was ist, wenn sich alle Philosophen gleichzeitig entscheiden zu essen und zu ihrem jeweils linken Stäbchen greifen? Wenn sie dann versuchen, das rechte aufzunehmen, hat das ja schon ihr Nachbar in der Hand und jetzt hängen alle fest und keiner kann essen. Und so weiter. Wie gesagt, das ist nur ein Denkmodell, aber es hilft, sich die Probleme zu vergegenwärtigen, die man hat, wenn z.B. mehrere Kerne um begrenzte Ressourcen konkurrieren.

Die Kurzform lautet: Nicht alles kann überhaupt von mehreren Kernen profitieren und bei den Sachen, wo es theoretisch denkbar wäre, muss man abwägen, ob sich der zusätzliche Aufwand rechnet.

[Lookbehind]

Den ganzen theoretischen Ausführungen möchte ich eigentlich nur noch einen Denkanstoß hinzufügen. Die meisten der Beschreibungen beziehen sich immer auf eine Aufgabe, eine Anwendung. In der Praxis kommt es aber heute kaum vor, dass nur eine Anwendung auf einem Rechner läuft.

Jetzt ist die spannende Frage: "Was will ich beurteilen?" Wie gut eine einzelne Anwendung läuft, die nur seriell arbeitet? Wie gut eine einzelne stark parallelisierte Anwendung läuft? Wie gut sich eine Anwendung im Zusammenspiel mit anderen Anwendungen schlägt? Und wen beurteile ich da eigentlich? Die Anwendung? Den Prozessor? Oder, insbesondere bei parallelisierten Anwendungen, denjenigen, der die einzelnen Aufgaben (Prozesse) auf die Arbeiter (Kerne) verteilt (das ist die Aufgabe des Schedulers).

Zu letzterem eine kleine Anekdote: Als AMD mit seinen Ryzen-Prozessoren auf den Markt kam, und erstmals viele Kerne in die Hände von normalen Anwendern legte (also in einem Maß, dass das auch von einer signifikanten Anzahl von Leuten gekauft wurde), stellte sich plötzlich raus, dass insbesondere Anwendungen die sich wirklich gut parallelisieren ließen, nicht so gut über alle Kerne skallierten. Ja, sie waren mit mehr Kernen immer noch schneller als mit weniger, aber nicht so proportional wie man das erwartet hätte. Klarer Fall: Die neuen AMD-Prozessoren waren wohl doch nicht so gut wie gedacht. ... bis ... ja bis ein Benchmark auf dem gleichen System deutlich unterschiedliche Ergebnisse zeigte, je nach dem, ob man ihn unter Windows oder unter Linux laufen ließ. Es stellte sich raus, dass der Scheduler von Windows mit der großen Anzahl an Kernen (genauer mit der Aufteilung auf die NUMA-Nodes) nicht so gut klar kam, und mehr Zeit damit verschwendete die Aufgaben ständig zwischen den Kernen hin und her zu bewegen, als die eigentliche Aufgabe zu erledigen. (Microsoft hat das inzwischen übrigens gehörig optimiert)

Den Otto-Normal-Verbraucher werden die meisten dieser Details aber überhaupt nicht interessieren. Und genau für den Markt, ist der M1 wirklich ein guter Prozessor. Er hat genug Leistung für das, was die meisten Leute so Tag ein, Tag aus mit ihrem Rechner tun und fühlt sich dabei echt flott an, und das alles bei einer phänomenalen Energiebilanz. Das ist schon was. Allerdings muss man dabei auch immer betrachten, dass es den M1, anders als die Core-i CPUs von Intel und die Ryzen-CPUs von AMD, nicht einzeln gibt. Um mal eine dieser unsäglichen Auto-Analogien zu bringen: Apple hat da ein neues Auto mit einem revolutionären (naja) Antriebskonzept auf den Markt geworfen. Der Motor ist auch wirklich super! Absolut, keine Frage. Aber das Auto drum rum? Mir hat das Ding zum Beispiel zu wenige und zu kleine Türen! (aka. nur USB-C und sonst nix ... ich hab keinen Bock ständig Adapter mit rum zu schleppen.)

tl;dr: Das ganze ist ein sehr komplexes Getriebe mit abertausenden Zahnrädchen. Da stumpf zu beurteilen, was letztlich "besser" ist, ist alles andere als trivial, und die beste Antwort die man darauf in aller kürze geben kann ist: Kommt drauf an!™

[Lerran]

Danke für eure Erklärungen.
Wie ist das eigentlich heute? Kommt Linux immer noch besser mit mehreren Kernen zurecht oder sind Windows und Linux in der Hinsicht gleich von der Performance?

Und noch was anderes. Welche Anwendungen profitieren denn von mehreren Kernen, also z. B. Spiele, Videobearbeitung usw.?
Das wäre eigentlich wichtig zu wissen, wenn man sich eine neue CPU kaufen möchte. Ansonsten zahlt man am Ende zu viel und nutzt es nicht mal aus

[Multithread]

Kommt Linux immer noch besser mit mehreren Kernen zurecht

Ja. Linux kommt immer noch besser mit vielen Kernen zurecht als Windows.

Und noch was anderes. Welche Anwendungen profitieren denn von mehreren Kernen, also z. B. Spiele, Videobearbeitung usw.?

Bild/Videobearbeitung
Simulationen
CAD
AI Berechnungen

Das sind so die häufigsten "Mehrkernanwendungen", welchen man als Privatperson begegnet.

[Lookbehind]

...
Wie ist das eigentlich heute? Kommt Linux immer noch besser mit mehreren Kernen zurecht oder sind Windows und Linux in der Hinsicht gleich von der Performance?

Genau weiß ich das nicht. Ich will auch nicht behauptet haben, dass Windows da immer den kürzeren gezogen hat. Es ist halt bei der Sache aufgefallen. Ich weiß, dass Microsoft da kräftig nachgearbeitet hat und gehe daher davon aus, dass die ihre Performance-Probleme inzwischen einigermaßen im Griff haben. Genauer verfolgt habe ich das aber zugegebenerweise nicht.

Und noch was anderes. Welche Anwendungen profitieren denn von mehreren Kernen, also z. B. Spiele, Videobearbeitung usw.?
Das wäre eigentlich wichtig zu wissen, wenn man sich eine neue CPU kaufen möchte. Ansonsten zahlt man am Ende zu viel und nutzt es nicht mal aus

Kommt drauf an ™

Das ist das worauf wir hinaus wollten. Das kann man so pauschal nicht sagen. Dabei kommt es stark auf die einzelne Anwendung an. Manche können gar nicht mit mehreren Kernen umgehen, weil die Aufgabe es nicht her gibt oder weil der Programmierer es nicht hin bekommt oder nicht für nötig hält oder ... hier Liste von Gründen einfügen. Andere Anwendungen sind mit zu wenigen Kernen ein echtes Problem.

In der Praxis ist meistens beides der Fall, denn sind wir mal ehrlich, welche Anwendung hat denn nur eine einzige Berechnung durch zu führen? Meistens hat jede Anwendung Parts die von vielen Kernen profitieren und andere die das nicht tun. ... und dann gibts noch die Option massiv parallelisierte Aufgaben an eine Grafikkarte oder andere Spezialhardware (sofern vorhanden und hilfreich) ab zu geben.

Wieviele Kerne sind jetzt genug? ... Kommt drauf an ™

Für normale Büro-Arbeiten reichen meisten 2-4 Kerne. Bei Videoschnitt ist die Grafikkarte meistens der wichtigere Teil. Wer viel mit virtuellen Maschinen arbeitet, freut sich über viele Kerne. Spiele kann ich nicht einschätzen, aus der Szene bin ich zu lange raus.

[Lerran]

Danke für eure Tipps!
Ich werde mir das mit den Kernen auf jeden Fall merken, sollte ich mir mal eine neue CPU zulegen. Aktuell komme ich mit meinen vier Kernen in den Spielen, welche ich spiele, gut zurecht.

Noch eine allgemeine Frage, u. a. zu Linux. Wie kann man sich das vorstellen, dass das Betriebssystem besser mit mehreren Kernen zurechtkommt? Sprich, merkt man das dann in der allgemeinen Performance (z. B. beim Booten oder Start einer Anwendung) oder ist das dann nur rein auf die Anwendung bezogen?

[foobar]

Noch eine allgemeine Frage, u. a. zu Linux. Wie kann man sich das vorstellen, dass das Betriebssystem besser mit mehreren Kernen zurechtkommt? Sprich, merkt man das dann in der allgemeinen Performance (z. B. beim Booten oder Start einer Anwendung) oder ist das dann nur rein auf die Anwendung bezogen?

Als normaler User mit einer 4-, 6- oder 8-Kern CPU merkst du das gar nicht. Wir reden hier über Extremfälle, wenn du beispielsweise einen Threadripper mit 32 oder 64 SMT-fähigen Kernen, die für das Betriebssystem dann wie 64 oder 128 CPUs aussehen, hast und darauf einen entsprechenden Benchmark oder eine High-Performance-Anwendung laufen lässt.

Beim Threadripper 2990WX z.B. waren die vielen Kerne über mehrere Dies verteilt (also quasi mehrere CPUs in einem Gehäuse) und das ergab dann eben eine NUMA-Architektur. Wenn ein Kern auf Die A auf RAM zugreifen will, der Die B zugewiesen ist, dann dauert das länger als wenn er seinen lokalen RAM benutzt. Und der Scheduler des Betriebssystems muss das berücksichtigen. Beim Threadripper 3000 ist das behoben, weil AMD da das Chiplet-Design verwenden. Alle CCX teilen sich den selben RAM-Controller auf dem I/O-Die, so dass der Speicherzugriff von und nach überall immer gleich lange dauert.

[Lookbehind]

...
Noch eine allgemeine Frage, u. a. zu Linux. Wie kann man sich das vorstellen, dass das Betriebssystem besser mit mehreren Kernen zurechtkommt? Sprich, merkt man das dann in der allgemeinen Performance (z. B. beim Booten oder Start einer Anwendung) oder ist das dann nur rein auf die Anwendung bezogen?

Puh ... da müssen wir ein bisschen ausholen.

(Achtung, die folgende Erklärung enthält sehr viele Vereinfachungen und lässt viele Details aus! Sie dient nur dazu das grobe Konzept zu erklären.)

Scheduler

Das geht los mit der Frage: Was macht eigentlich ein Betriebssystem? Da ich aber keine Lust auf eine ewig lange Informatik-Vorlesung habe, beschränken wir uns mal auf den Teil, der für diese Frage am wichtigsten ist. Den Scheduler. Um zu verstehen, was das Ding macht, müssen wir uns erst mal anschauen, wie es denn aussähe, wenn es ihn (oder gleich das ganze Betriebssystem) nicht gäbe. Und um die Sache nicht vom Start weg zu kompliziert zu machen, gehen wir mal in die Zeit zurück, als es noch keine Mehrkern-Prozessoren gab.

Wir wollen unsere Anwendung auf dem Computer ausführen. Da wir kein Betriebssystem haben, muss die Anwendung direkt auf der Hardware laufen. Das hat den Vorteil, dass die Anwendung das komplette System für sich hat, sie kann also z.B. den kompletten RAM benutzen wie es dem Entwickler gefällt und alle Berechnungen können auf dem Prozessor am Stück und ohne Unterbrechung laufen. Das ist toll für die Anwendung, aber für Benutzer mit heute üblichen Ansprüchen nicht. Denn so lässt sich immer nur eine Anwendung ausführen. Surfen und nebenbei Musik hören? Vergiss es! Eine E-Mail schreiben und die nötigen Inhalte aus einer Tabellen-Kalkulation ablesen? Ja klar, du musst nur jedes mal neu starten und die Festplatte tauschen, wenn du zwischen den Programmen wechseln möchtest. ... In den 50ern und 60ern mag das noch ok gewesen sein, da waren Computer ohnehin nur was für Nerds und ihre Verwendung überwiegend für wenige große Berechnungen vorgesehen, die ohnehin mehrere Tage am Stück liefen. Aber heute? Heute ist Multitasking eine Selbstverständlichkeit. Und das nicht erst, seit es Mehrkern-Prozessoren gibt.

Hier kommt das Betriebssystem, genauer der Scheduler ins Spiel. Dessen Aufgabe ist es, jeder Anwendung einen bestimmten Zeit-Slot auf dem Prozessor zu zu weisen. Erst darf Anwendung A für ein paar Millisekunden den Prozessor benutzen, dann hat sie sich schlafen zu legen und Anwendung B ist dran, dann Anwendung C, dann D, dann wieder A, Anwendung B wartet noch auf Daten von der Festplatte und kann daher mit der Prozessor-Zeit gerade nix anfangen, also ist Anwendung C erst mal wieder dran ... und so weiter. Dieses ständige Umschalten zwischen den einzelnen Anwendungen lief schon auf den Einkern-Prozessoren der 90er schnell genug, dass man das Gefühl von Multitasking hatte, als würden mehrere Anwendungen gleichzeitig laufen. In Wirklichkeit liefen die alle abwechselnd. Nur der Wechsel ging so schnell, dass wir als Menschen das nicht mit bekommen haben.
Die Entscheidung wann welche Anwendung für wie lange ... etc. DAS ist die Aufgabe des Schedulers.

Fast Forward in die Gegenwart. Was das angeht hat sich eigentlich nicht viel geändert. Auf einem CPU-Kern kann immer noch nur eine Anwendung gleichzeitig laufen, Betriebssystem gibts immer noch, Menschen erwarten immer noch Multitasking von ihren Computern und es ist immer noch Aufgabe des Schedulers zu entscheiden welche Anwendung wann auf dem CPU-Kern läuft. Was neu ist, verglichen mit den Consumer-PCs der 90er, sind die Mehrkern-Prozessoren. Da kann zwar auch nur eine Anwendung pro Kern laufen, da wir aber mehrere Kerne haben, können wir mehrere Anwendungen wirklich parallel laufen lassen. Wir haben also echtes Multitasking. Allerdings macht das die Aufgabe des Schedulers jetzt nicht einfacher. Denn es gilt immer noch weit mehr Anwendungen laufen zu lassen, als CPU-Kerne zur Verfügung stehen.¹ Der Scheduler muss jetzt also nicht nur entscheiden in welcher Reihnefolge und für welche Zeit-Spanne er die Anwendungen laufen lässt, sondern auch noch auf welchem Kern.

Hier hatte Windows seine ersten Probleme. In den frühen 2000ern funktionierte Windows zwar auf Mehrkern-CPUs, verwaltete die aber wie Einkerner. Es bekam also immer eine Anwendung die komplette CPU zugeteilt. Unabhängig davon, ob die überhaupt mehrere Kerne benutzt hat, oder nicht. Zwei Anwendungen, die jeder nur einen Kern brauchen, mussten also trotzdem nacheinander laufen, während sich der zweite Kern langweilte. Das wurde aber recht bald gefixt.
Allerdings war Windows nie für eine solche Umgebung konzipiert gewesen. Daher beinhaltete der Fix ein paar dreckige Tricks. Unter anderem den, dass der Scheduler selbst (und einige andere essentielle Komponenten) immer nur auf dem ersten Kern des Systems lief. Daher kam der Trick, dass man auf Systemen mit 4 Kernen oder mehr unter Windows 7 aus GTA5 deutlich mehr Performance kitzeln konnte, wenn man dem Spiel manuell untersagte, den ersten Kern zu benutzen. GTA5 lief auf Win7 quasi mit drei Kernen schneller als mit vier, wenn man den ersten Kern frei ließ. Auch das Problem ist schon länger beseitigt.
Wenn wir jetzt in den Bereich vor stoßen, dass wir mit 16 oder gar 32 Kernen um uns werfen können (AMD Threadripper), macht es manchmal außerdem Sinn, gar nicht alle Anwendungen ständig in die Pause zu schicken und den Kern für was anderes zu verwenden, sondern ein paar Prozesse vielleicht für 2-3 Zyklen einfach weiter laufen zu lassen, und damit vielleicht 3-4 Kerne für eine längere Zeit zu blockieren, und auf den verbleibenden Kernen weiterhin Bäumchen wechsel dich mit den anderen Prozessen zu spielen. Auf so ein Szenario war der Scheduler von Windows aber auch nicht vorbereitet und hat mehr Zeit damit vergeudet, die Prozesse ständig von einem Kern zum anderen zu schieben, als die eigentliche Berechnung durch zu führen. Das war eins der Probleme auf die ich mich bezog.

Speicherverwaltung

Und dann war da noch die Sache mit dem RAM. (Oder Speicher im allgemeinen, aber wir konzentrieren uns mal auf die Basics.) Wir schmeißen wieder unsere Zeitmaschine an und reisen zurück in die Zeit der Einkern-Prozessoren und Betriebssysteme brauchen wir auch nicht. Wer will schon Multitasking? Unsere Anwendung läuft also wieder direkt auf der Maschine. Hier hat der Entwickler Narrenfreiheit bei der Speichernutzung. Da seine Anwendung die einzige ist die auf dem System läuft, muss er sich auch keinen Kopf darum machen evtl. jemand anderem in die Quere zu kommen, wenn er Daten im RAM ablegt.

Wenn wir jetzt aber doch Multitasking betreiben wollen, sieht die Welt etwas anders aus. Plötzlich muss sich der Entwickler mit dem Entwickler der zweiten Anwendung, die auf dem System läuft, absprechen, wer welche Speicherbereiche für sich beanspruchen darf, damit man sich nicht aus Versehen gegenseitig die Daten kaputt schreibt. Solange das nur die zwei Anwendungen sind, geht das noch. Bei drei bis vier Anwendungen vielleicht auch noch. Insbesondere, wenn die Entwickler alle in der gleichen Firma arbeiten. Aber realistisch betrachtet kann ein Entwickler unmöglich wissen, welche Anwendungen der Benutzer noch auf seinem System laufen lässt und wer die alle entwickelt. Ganz zu schweigen da eine Einigung zu finden, die für alle funktioniert und keine Kollisionen beinhaltet ... über Systeme mit unterschiedlicher Ausstattung wollen wir gar nicht erst reden. Eine einheitliche Lösung muss her.

Auch hier kommt wieder das Betriebssystem ins Spiel. Genauer die Speicherverwaltung. Die Anwendung belegt nicht einfach blind irgendwelchen Speicher, sondern es fragt das Betriebssystem "Hey, ich brauch mal 500MB Speicher, wo darf ich das hin legen?", und die Speicherverwaltung des Betriebssystems schaut dann, welcher Speicher noch nicht verwendet wird und weist der Anwendung den entsprechenden Bereich zu, den die Anwendung dann verwenden kann.² Das Betriebssystem ist dann also dafür verantwortlich, dass es da keine Überschneidungen zwischen den Anwendungen gibt.

Zurück in die Zukunft ... ähhh, Gegenwart. Die Threadripper-CPUs sind, aus verschiedenen Gründen, unter anderem bei der Fertigung, in so genannte NUMA-Nodes (Non-Unified-Memory-Access) aufgeteilt. Dabei liegt immer ein Teil der Kerne auf dem einen NUMA-Node, und ein weiterer auf einem anderen NUMA-Node. Der wichtige Punkt dabei ist, dass nicht jeder NUMA-Node gleich schnell an jeden Speicher-Bereich des RAM angebunden ist. Also abhängig davon, auf welchem Kern eine Anwendung läuft, und wo im Speicher seine Daten liegen, kommt die Anwendung mal mehr und mal weniger schnell an ihre Daten heran. Auch dieses Detail hat Windows nicht berücksichtigt. Was zu sehr inkonsistenten Performance-Problemen führte. Denn natürlich kann man dabei auch mal Glück haben und die Daten liegen in einem Speicherbereich, der von dem aktuellen Kern schnell erreichbar ist. Genauso kann man aber auch Pech haben.

Linux

Warum hatte Linux damit jetzt keine Probleme? Warum ist der Pinguin mit seinen Watschelfüßen nicht über die gleichen Schwierigkeiten gestolpert? Ist er! Nur viel, viel früher! Linux hat diese Probleme schon in den 90ern, und teilweise noch früher, gelöst. Ihm kommen dabei zwei Dinge zur Hilfe.

Zum einen wird Linux schon seit Mitte der 90er massiv im Rechenzentrum eingesetzt. Und da gab es damals schon Systeme mit mehr als einer CPU. Nein, nicht nur mehreren CPU-Kernen, wirklich mehrere CPUs auf einem Board! Jede CPU ist übrigens zwangsweise ihr eigener NUMA-Node. Linux musste dieses Problem also schon damals lösen. Genauso wie die Frage, wie man eigentlich Prozesse effizient auf viele Kerne verteilt. Das waren Server-Systeme, und die mussten laufen. Und zwar so effizient wie möglich, denn im IT-Business hat keiner Geld zu verschenken. Da kann es sich keiner leisten mal 40-60% Performance liegen zu lassen, weil immer nur eine Anwendung gleichzeitig laufen kann, selbst wenn die nur einen der zwei Kerne benötigt.

Zum anderen ist Linux an sich zwar erst 1992 entstanden, das Konzept stammt aber schon aus den 70ern. Denn Linux ist ein Unix-Clone. Und die verschiedenen Unix-Derivate wurden seit jeher in Rechenzentren und auf Großrechnern verwendet. Mit unterschiedlichster Ausstattung und diversesten Besonderheiten. Von mehreren Prozessoren über Cluster-Systeme mit speziellen Aufgaben, verschiedenste Speicher-Anbindungen und Speicher-Techniken, und und und. All das in Bereichen, in denen es wirklich um was ging. Da waren keine halbherzigen Lösungen gefragt. Von diesem ganzen Erfahrungsschatz an konzeptionellen Lösungen konnte Linux in seiner Entwicklung zehren.

---

1) Um mal ne Größenordnung zu haben, auf meinem Laptop gibt es aktuell 133 Prozesse. Eine Anwendung kann dabei aus mehreren Prozessen bestehen, und letztlich verwaltet der Scheduler die Prozesse, nicht direkt die Anwendungen. (Und ein Prozess kann wiederum aus mehreren Threads bestehen.)

2) Das ist eine sehr grobe Vereinfachung. Speichermanagement ist noch um ein vielfaches komplizierter. Insbesondere gaukelt das Betriebssystem der Anwendung vor, sie wäre alleine auf dem System, und der gesamte adressierbare RAM stünde ihr alleine zur Verfügung. Unabhängig davon, ob das System überhaupt so viel Speicher hat. Das liegt unter anderem daran, dass einige Operationen viel einfacher zu entwickeln sind, wenn man durchgehende Speicher-Adressen verwenden kann, diese in der Praxis aber fragmentiert im Speicher abgelegt werden müssen. Ein paar Sicherheits-Implikationen hat es auch noch, wenn die Anwendung nicht weiß, auf welchen Speicheradressen sie wirklich arbeitet. Und ... ach, allein darüber kann man Bücher schreiben.

Edith meint, wie immer war foobar schneller und hat mein ganzes Geschwafel in viel weniger Worten zusammenfassen können. Ich sollte bei den Admins beantragen, dass foobar sich nicht einloggen darf, während ich eine Antwort tippe. *Auf foobars Sterne schiel* Oh ... wait!

[Homerclon]

Edith meint, wie immer war foobar schneller und hat mein ganzes Geschwafel in viel weniger Worten zusammenfassen können.

Ich fand es dennoch interessant zu lesen.
Konnte auch etwas neues aufschnappen: Der Grund für das noch immer gelegentliche Auftauchen des Tipps, Anwendungen manuell bestimmten Kernen zuzuordnen.

[Nobbi Habogs]

Bild/Videobearbeitung
Simulationen
CAD
AI Berechnungen

Das sind so die häufigsten "Mehrkernanwendungen", welchen man als Privatperson begegnet.

Naja, definiere Mehrkernanwendung, 2 Kerne sind auch Mehrkerne. Windows skaliert zwar vermutlich nicht so gut wie Linux, Widonws und die Programme brauchen es aber trotzdem zwingend. Um Windows 10 vernünftig betreiben zu können brauchts schon mindestens einen Dualcore neuester Generation, am besten ein Desktop Modell mit SMT. Dagegen auf einfachen vergleichsweise moderat getakteten Dualcores vergangener Tage ist das System kaum lauffähig, die ersten Quadcores können das allerdings noch gut handlen, selbst mit deutlich niederiger Taktung bzw. Single-Core Perfomance. Und auch Spiele profitieren merklich von 6 gegenüber 4 Kernen bzw. den Begleiterscheinungen: deutlich größerer Cache, erhöhte Parallelisierung für ein "weicheres Bild" wegen besserer Frametimes und weniger FPS-Einbrüche, sowie den geringeren Einfluss von Hintergrundanwendungen.

Gerade durch den Sprung von Windows 7 auf Windows 10, hat sich sehr viel geändert. Windows 7 läuft sehr gut mit schlechter Hardware, weil es so gut wie keine aktiven Hintergrundprozesse gibt, wenn man etwas startet wartet man etwas und gut ist. Bei Windows 10 profitiert man ja schon deshalb von den Mehrkernen, weil es einfach selbstständig immer irgendwas aktiv macht, was auch vergleichsweise ENORM viel Leistung braucht. Dort dauern die gleichen Aufgaben teilweise 5-10 mal so lange wie unter Windows 10, wenn die Hardware schon damit beschäftigt ist die ganze Kacke im Hintergrund zu regeln.