Interessante Erkenntnis oder auch nicht ?
- Ersteller latiose88
- Erstellt am
Ultra_Force
Lieutenant
- Registriert
- Juni 2008
- Beiträge
- 1.015
@luckysh0t meiner war ein Northwood 
SaxnPaule
Fleet Admiral
- Registriert
- Okt. 2010
- Beiträge
- 12.035
Blätter mal eine Seite zurück. Sowohl Northwood, als auch Prescott waren Pipeline-Krüppel.
Die P4 waren damals ein Griff ins Klo und man hat lieber zu Thorton und Barton gegriffen.
AMD hatte ja damals das + Rating eingeführt um eine Vergleichbarkeit zum Intel Pendant zu ermöglichen. Durch die höhere IPC konnte AMD die gleiche Leistung wie ein deutlich höher taktender Pentium erreichen. Bei entsprechend niedrigerem Verbrauch.
Die P4 waren damals ein Griff ins Klo und man hat lieber zu Thorton und Barton gegriffen.
AMD hatte ja damals das + Rating eingeführt um eine Vergleichbarkeit zum Intel Pendant zu ermöglichen. Durch die höhere IPC konnte AMD die gleiche Leistung wie ein deutlich höher taktender Pentium erreichen. Bei entsprechend niedrigerem Verbrauch.
- Registriert
- Juni 2007
- Beiträge
- 24.235
Weißt du, die grundsätzliche Leistungsfähigkeit eines Rechners hat natürlich etwas mit der CPU zu tun, je nach Anwendung auch mit der Grafikkarte usw.
Aber am Ende ist es die Gesamtheit der all dem zu Grunde liegenden Architektur.
Wie ist ein x86 kompatibler Rechner hardwareseitig aufgebaut?
CPU, Kernanzahl, Taktraten, evtl. ab Werk vorhandene Turbostufen (Werksübertaktung), Abwärme (sprich Effizienz), Breite und Tiefe diverser "Pipelines",
Bussysteme, Cachestufen, Speicheranbindung, Zugriffszeiten/Latenzen/Transferraten von Arbeitsspeicher, Laufwerken uvm.
Taktrate bei CPUs ist im Grunde belanglos. Die Leistungsfähigkeit einer CPU kann man anhand der Taktrate nur innerhalb der selben Generation vergleichen.
Weil sich die Effizienz, also das Maß wie viel Arbeit pro Taktschritt erledigt werden kann, immer ändert, meist verbessert von Generation zu Generation.
Das nennt man dann gerne IPC, Instructions Per Cycle.
Früher gab es den "Megahertz-Wahn", immer mehr, mehr, mehr. Weil, mehr ist besser.
Dann kam man drauf das dabei die Effizienz auf der Strecke bleibt. Die Abwärme immer weiter ansteigt usw.
Also ist man drauf gekommen das Parallelität das bessere Prinzip ist.
Also mehr Rechenkerne pro CPU, jeder einzelne Rechenkern muss dann nicht ganz so performant sein, weil ja mehrere gleichzeitig arbeiten.
Das führte aber dazu das Anwenderprogramme nun entsprechend befähigt sein müssen, mehrere aufeinander aufbauende Aufgaben gleichzeitig verarbeiten zu lassen. Das ist nicht unbedingt viel mehr Programmieraufwand, sondern der Aufwand liegt vorher in der Entwicklung von Datenstrukturen und Algorithmen, die das ermöglichen. Und wie effizient kann man bestimmte Aufgaben parallelisieren? Das steigt nicht linear mit und bei manchen Aufgaben geht das gar nicht.
Bei CPUs muss man auch bedenken, rein technisch bedingt, je mehr Rechenkerne vorhanden sind, desto leistungsschwächer werden die einzelnen Kerne, weil man ist, was Leistungsaufnahme, Abwärme usw. angeht, auf ein gewisses Maximallevel festgelegt. Beispielsweise wie viel Stromaufnahme können wir gewährleisten und wie viel Abwärme kann das Hardwaredesign überhaupt abführen?
Das heißt, habe ich eine Software, die so gestaltet ist das sie z.B. 4 CPU-Kerne auslasten kann, wird das Programm auf einer CPU mit 32 Rechenkernen vermutlich langsamer ausgeführt. Weil die übrigen 28 Rechenkerne nicht benutzt werden.
Die Leistungsfähigkeit kann man nie an einer einzelnen Sache fest machen.
CPU, Grafikkarte, Menge/Geschwindigkeit Arbeitsspeicher, Menge/Geschwindigkeit Laufwerke, Geschwindigkeit diverser Bussysteme, die intern all diese Dinge miteinander verbindet usw. Im Zusammenspiel ergibt sich die finale Leistung.
Letztlich müsste man, um deutlich mehr Leistung rauszukitzeln nun eine gänzlich neue Plattform entwickeln/nutzen, also weg vom x86 Design hin zu etwas effizienterem. Das würde aber dazu führen das ein grundsätzliches Prinzip nicht mehr funktionieren würde, die Kompatibilität.
Was Software angeht, so erfindet natürlich nicht jeder ständig das Rad neu.
Spiele profitieren z.B. gerne von mehr Cache. Deshalb greift man für Spiele-Rechner gerne zu AMDs X3D CPUs, z.B. den AMD Ryzen 7 9850X3D.
Andere Anwendungsprogramme profitieren davon deutlich weniger.
Das liegt aber oft daran das z.B. bei Spielen gewisse Standard-Bibliotheken/Engines verwendet werden, die mehr Cache effizient ausnutzen können.
Das liegt nicht daran das Programmierer für Spiele mehr Ahnung haben als Programmierer für andere Anwendungen.
Ganz allgemein formuliert, die heute gängige Systemarchitektur eines "Von-Neumann-Rechners" krankt letztlich an einem prinzipbedingt erzwungenen Sequentialismus, denn obwohl man inzwischen viele Dinge parallelisiert, gilt nach wie vor dieses feste Prinzip einer strikt sequenziellen Befehlsabfolge.
OK, das ist schon sehr hochtrabend ausgedrückt...
Aber am Ende ist es die Gesamtheit der all dem zu Grunde liegenden Architektur.
Wie ist ein x86 kompatibler Rechner hardwareseitig aufgebaut?
CPU, Kernanzahl, Taktraten, evtl. ab Werk vorhandene Turbostufen (Werksübertaktung), Abwärme (sprich Effizienz), Breite und Tiefe diverser "Pipelines",
Bussysteme, Cachestufen, Speicheranbindung, Zugriffszeiten/Latenzen/Transferraten von Arbeitsspeicher, Laufwerken uvm.
Taktrate bei CPUs ist im Grunde belanglos. Die Leistungsfähigkeit einer CPU kann man anhand der Taktrate nur innerhalb der selben Generation vergleichen.
Weil sich die Effizienz, also das Maß wie viel Arbeit pro Taktschritt erledigt werden kann, immer ändert, meist verbessert von Generation zu Generation.
Das nennt man dann gerne IPC, Instructions Per Cycle.
Früher gab es den "Megahertz-Wahn", immer mehr, mehr, mehr. Weil, mehr ist besser.
Dann kam man drauf das dabei die Effizienz auf der Strecke bleibt. Die Abwärme immer weiter ansteigt usw.
Also ist man drauf gekommen das Parallelität das bessere Prinzip ist.
Also mehr Rechenkerne pro CPU, jeder einzelne Rechenkern muss dann nicht ganz so performant sein, weil ja mehrere gleichzeitig arbeiten.
Das führte aber dazu das Anwenderprogramme nun entsprechend befähigt sein müssen, mehrere aufeinander aufbauende Aufgaben gleichzeitig verarbeiten zu lassen. Das ist nicht unbedingt viel mehr Programmieraufwand, sondern der Aufwand liegt vorher in der Entwicklung von Datenstrukturen und Algorithmen, die das ermöglichen. Und wie effizient kann man bestimmte Aufgaben parallelisieren? Das steigt nicht linear mit und bei manchen Aufgaben geht das gar nicht.
Bei CPUs muss man auch bedenken, rein technisch bedingt, je mehr Rechenkerne vorhanden sind, desto leistungsschwächer werden die einzelnen Kerne, weil man ist, was Leistungsaufnahme, Abwärme usw. angeht, auf ein gewisses Maximallevel festgelegt. Beispielsweise wie viel Stromaufnahme können wir gewährleisten und wie viel Abwärme kann das Hardwaredesign überhaupt abführen?
Das heißt, habe ich eine Software, die so gestaltet ist das sie z.B. 4 CPU-Kerne auslasten kann, wird das Programm auf einer CPU mit 32 Rechenkernen vermutlich langsamer ausgeführt. Weil die übrigen 28 Rechenkerne nicht benutzt werden.
Die Leistungsfähigkeit kann man nie an einer einzelnen Sache fest machen.
CPU, Grafikkarte, Menge/Geschwindigkeit Arbeitsspeicher, Menge/Geschwindigkeit Laufwerke, Geschwindigkeit diverser Bussysteme, die intern all diese Dinge miteinander verbindet usw. Im Zusammenspiel ergibt sich die finale Leistung.
Letztlich müsste man, um deutlich mehr Leistung rauszukitzeln nun eine gänzlich neue Plattform entwickeln/nutzen, also weg vom x86 Design hin zu etwas effizienterem. Das würde aber dazu führen das ein grundsätzliches Prinzip nicht mehr funktionieren würde, die Kompatibilität.
Was Software angeht, so erfindet natürlich nicht jeder ständig das Rad neu.
Spiele profitieren z.B. gerne von mehr Cache. Deshalb greift man für Spiele-Rechner gerne zu AMDs X3D CPUs, z.B. den AMD Ryzen 7 9850X3D.
Andere Anwendungsprogramme profitieren davon deutlich weniger.
Das liegt aber oft daran das z.B. bei Spielen gewisse Standard-Bibliotheken/Engines verwendet werden, die mehr Cache effizient ausnutzen können.
Das liegt nicht daran das Programmierer für Spiele mehr Ahnung haben als Programmierer für andere Anwendungen.
Ganz allgemein formuliert, die heute gängige Systemarchitektur eines "Von-Neumann-Rechners" krankt letztlich an einem prinzipbedingt erzwungenen Sequentialismus, denn obwohl man inzwischen viele Dinge parallelisiert, gilt nach wie vor dieses feste Prinzip einer strikt sequenziellen Befehlsabfolge.
OK, das ist schon sehr hochtrabend ausgedrückt...
Zuletzt bearbeitet:
Das Thema hat Gene Amdahl vor 50 Jahren bearbeitet, seines Zeichens IBM-Spezialist und später Supercomputer-Entwickler. Siehe Wikipedia zu Amdahlsches Gesetz.
Programme bestehen aus Teilen, die nicht paralelisierbar sind und welche die parallel laufen können. Daten werden z.B. vor einer parallelen Verarbeitung erstmal zerlegt und anschließend wieder zusammengefügt.
Eine höhere Singelthread-Leistung sorgt also immer für mehr Geschwindigkeit, während Paralelisierung nur greift, wenn die Software das unterstützt.
Bei Paralelisierung kommen zusätzliche Hürden hinzu, vor allem wenn der Prozess auf einen anderen Kern wechselt und die Daten aber noch im Cache eines anderen Kerns liegen oder wenn Daten von einem Kern in den Cache geschrieben werden und ein anderer Kern diese lesen muß. Die Daten werden vom RAM angefragt, aber die Speicherverwaltung signalisiert, daß die Daten im RAM ungültig sind, weil in Cache Nummer 4 aktuelle Daten liegen. Dann muß der Kern die Daten über die internen Bussysteme die Daten bei einem anderen Kern anfragen. Das dauert dann sehr viel Zeit.
Es gibt dafür die NUMA-Speicherverwaltung, die einzelne Threads möglichst an den immer gleichen Kern bindet. Bei Windows wurde NUMA mit Vista eingeführt. In der Konsequenz müssen alle Treiber umgeschrieben werden, die performance und speicherrelevant sind (Storage, Grafik, Netzwerk). Deshalb war die Stabilität von Vista wackelig, aber der Entwicklungsschritt war unumgänglich notwendig.
Eine Software sollte immer an die Hardware angepaßt sein, idealerweise macht sie das dynamisch. Daten sollten möglichst nicht die Grenzen der Architektur überteten, weil es über die Entfernung immer langsamer wird. Da sind zuerst die Register im Core (wenige Bytes), dann L1-, L2-, L3-Cache. Das ist z.B. bei Datenbanken und Satzlängen relevant, daß man nicht unnötige Daten zur Verarbeitung lädt.
Wird parallel verarbeitet, steigen in gleichem Maße die Datenmengen. Es kann also sinnvoll sein, daß man nur 12x parallelisiert, obwohl man 16 Cores hat, einfach weil die Caches überlaufen. Versucht man vlt sogar 20 Threads abzuarbeiten, müssen sich die einzelnen Threads auf den Cores abwechseln und die jeweiligen Daten fliegen dann oft mit aus dem Cache, falls dieser nicht groß genug ist. Das bremst die Verarbeitung dann ziemlich aus.
Programme bestehen aus Teilen, die nicht paralelisierbar sind und welche die parallel laufen können. Daten werden z.B. vor einer parallelen Verarbeitung erstmal zerlegt und anschließend wieder zusammengefügt.
Eine höhere Singelthread-Leistung sorgt also immer für mehr Geschwindigkeit, während Paralelisierung nur greift, wenn die Software das unterstützt.
Bei Paralelisierung kommen zusätzliche Hürden hinzu, vor allem wenn der Prozess auf einen anderen Kern wechselt und die Daten aber noch im Cache eines anderen Kerns liegen oder wenn Daten von einem Kern in den Cache geschrieben werden und ein anderer Kern diese lesen muß. Die Daten werden vom RAM angefragt, aber die Speicherverwaltung signalisiert, daß die Daten im RAM ungültig sind, weil in Cache Nummer 4 aktuelle Daten liegen. Dann muß der Kern die Daten über die internen Bussysteme die Daten bei einem anderen Kern anfragen. Das dauert dann sehr viel Zeit.
Es gibt dafür die NUMA-Speicherverwaltung, die einzelne Threads möglichst an den immer gleichen Kern bindet. Bei Windows wurde NUMA mit Vista eingeführt. In der Konsequenz müssen alle Treiber umgeschrieben werden, die performance und speicherrelevant sind (Storage, Grafik, Netzwerk). Deshalb war die Stabilität von Vista wackelig, aber der Entwicklungsschritt war unumgänglich notwendig.
Ergänzung ()
Im Grunde ist das Thema und die Gedanken des TE nicht neu. Multiprozessorsysteme gibt es seit 50 Jahren und damals waren die absoluten Cracks am werk, die das erforschten und Bücher mit ihren Erkenntnissen füllten.KnolleJupp schrieb:
Eine Software sollte immer an die Hardware angepaßt sein, idealerweise macht sie das dynamisch. Daten sollten möglichst nicht die Grenzen der Architektur überteten, weil es über die Entfernung immer langsamer wird. Da sind zuerst die Register im Core (wenige Bytes), dann L1-, L2-, L3-Cache. Das ist z.B. bei Datenbanken und Satzlängen relevant, daß man nicht unnötige Daten zur Verarbeitung lädt.
Wird parallel verarbeitet, steigen in gleichem Maße die Datenmengen. Es kann also sinnvoll sein, daß man nur 12x parallelisiert, obwohl man 16 Cores hat, einfach weil die Caches überlaufen. Versucht man vlt sogar 20 Threads abzuarbeiten, müssen sich die einzelnen Threads auf den Cores abwechseln und die jeweiligen Daten fliegen dann oft mit aus dem Cache, falls dieser nicht groß genug ist. Das bremst die Verarbeitung dann ziemlich aus.
Zuletzt bearbeitet:
latiose88 schrieb:
Ja aber z.B. bei Games hast Du inzwischen das Problem, dass die meisten auf Konsolen bzw. für Konsolen entwickelt werden und da hat man 'nur' 8 Kerne.
Und es gibt haufenweise Games, die nur auf einem Kern laufen. Das ist leider bei vielen Simulationen der Fall.
Ja es gibt diese Software Threads. Diese sind nicht echte Threads. Als ich das zum ersten Mal gesehen hatte ,dachte ich das seien echte Threads. Also 18 Threads ,18 Kerne. Aber dem ist ja nicht so.darum weicht es ja ab von dem ganzen. Da es immer die selben Threads Anzahl bei bestimmten Einstellung sind ,bin ich genau da wo ihr so geschrieben habt. In einem Software limit. Ah einer gewissen Menge an kernen und Takt ,bremst dann die Software das ganze aus. Es ist dann dicht an den Punkt. Dieses limit ist ja nicht neu ,da haben mehrere dieses Problem.
- Registriert
- Aug. 2019
- Beiträge
- 3.064
"Mehr Takt=Mehr besser" stammt aus dem 20. Jahrhundert, wo man mit dem 8086 bei 5 MHz anfing und mit dem Athlon die 1 GHz-Marke erreichte (und gleichzeitig die Architektur von 16 auf 32-Bit anhob).
Heute kommt es mehr auf den Anwendungsfall an als früher:
Spiele auf Consumerhardware? 8 Kerne um die 5 GHz + möglichst großer Cache. Ryzen X3D.
Virtualisierung? Soviel Kerne wie möglich. 16-Kern-Ryzen. Wer mehr braucht: Threadripper/Epyc.
Heute kommt es mehr auf den Anwendungsfall an als früher:
Spiele auf Consumerhardware? 8 Kerne um die 5 GHz + möglichst großer Cache. Ryzen X3D.
Virtualisierung? Soviel Kerne wie möglich. 16-Kern-Ryzen. Wer mehr braucht: Threadripper/Epyc.
Wenn man das ganze nicht nur von CPU oder GPU betrachten würde, wäre das Fazit wohl doch eher, mehr Takt hilft. Aber nuatürlich nur, wenn in ALLEN Komponenten die Geschwindigkeit im gleichen Verhältnis steigen würde, z.B. auch die Zugriffszeit auf Speicher und Datenträger bei Taktverdoppelung auch nur noch halb so groß ist. Und hier beißt sich die Maus den Schwanz ab. Irgendein Limit liegt halt immer vor. Erst die CPU, dann der Arbeitspeicher, dann die Datenträger etc etc. Ein unendlicher Kreis. Aber im Fazit bleibt, wenn alle Komponenten gleichviel schneller werden, kommt die Geschwindigkeit an. Software ist da per se aber keine Grenze. Und natürlich, wenn nur an der CPU geschraubt (diskutiert) wird, dann gibt es irgendwann irgendwo ein anderes Limit. Nicht die SW!kachiri schrieb:
- Registriert
- Juni 2007
- Beiträge
- 24.235
Es gibt ja viele Limits.
Die CPU, die kann zu langsam sein und/oder zu wenig Rechenwerke besitzen,
die Geschwindigkeit des Arbeitsspeichers, die Geschwindigkeit von Laufwerken, die Geschwindigkeit von Grafikkarten usw.,
inkl. ihrer jeweiligen Anbindung untereinander.
Dann kann auch Software limitieren.
Wie gut lassen sich zu erledigende Aufgaben parallelisieren?
Passt die Kombination aus Registern, Pipelines, Cachestufen usw. oder kommt die Software, der betriebssystemseitige Task Scheduler
an Grenzen? Wo liegen wann welche Daten vor, liegen die in einem gemeinsamen Cache, müssen die CPU-intern erst neu verteilt werden uvm.
Mit welcher Geschwindigkeit kann man welche Datenmenge an andere Komponenten übergeben, z.B. der Grafikkarte, dem Arbeitsspeicher usw.?
Irgendwo ist immer ein Flaschenhals.
Idealerweise sind alle Komponenten so ausgewählt das in den benötigten Anwendungsszenaren möglichst alles möglichst lange möglichst voll ausgelastet ist, ohne überlastet zu werden. Dann ziehe ich aus der vorhandenen Hardware die größtmögliche Leistung.
In der Realität ist es aber oft so das ein Teil erst auf die Arbeit eines anderen Teils warten muss.
Windows heißt übersetzt "Weißer Mann warten auf Sanduhr". Das war früher schon so und ist es heute immer noch.
Das Betriebssystem muss Aufgaben möglichst effizient auf die in der CPU verfügbaren Resourcen aufteilen und gleichzeitig muss die Software, die ausgeführt wird so ausgelegt sein das mehrere parallele Ausführungspfade überhaupt ermöglicht werden.
Habe ich eine Software, die so programmiert ist das sie nur auf einem einzelnen Rechenkern laufen kann, nützt mir alles Verteilen nichts mehr. Weil es dann nichts zu verteilen gibt.
Und wenn ich dann mehrere Programm gleichzeitig laufen habe, will jeder zur selben Zeit was vom Kuchen abbekommen.
Beispielsweise Windows 11 Pro unterstützt bis zu 128 physische Prozessorkerne und maximal zwei physische Prozessoren gleichzeitig.
Wenn wir noch Hyper-Threading/Simultaneous Multithreading dazu nehmen, wären wir bei maximal 256 Threads.
Man könnte also ein Dual-CPU System mit zwei 64-Kern CPUs inkl. Hyper-Threading/Simultaneous Multithreading nutzen.
Dazu kommen noch maximal 2TB Arbeitsspeicher.
Du könntest z.B. einen Rechner bauen mit zwei AMD Epyc 9575F https://geizhals.de/amd-epyc-9575f-100-000001554-a3332562.html auf z.B. einem
Gigabyte MZ73-LM2 https://geizhals.de/gigabyte-mz73-lm2-9mz73lm2mr-000-3-a3552120.html und dazu noch 24 mal Arbeitsspeicher wie z.B.
Kingston KSM64R52BD4-64MD https://geizhals.de/kingston-server-premier-rdimm-64gb-ksm64r52bd4-64md-a3452640.html
und da drauf ein ganz ordinäres Windows 11 Pro installieren und nutzen...
Das "bisschen" Hardware das du im Rechner hast, ringt dem Betriebssystem nichtmal ein müdes Lächeln ab...
Die CPU, die kann zu langsam sein und/oder zu wenig Rechenwerke besitzen,
die Geschwindigkeit des Arbeitsspeichers, die Geschwindigkeit von Laufwerken, die Geschwindigkeit von Grafikkarten usw.,
inkl. ihrer jeweiligen Anbindung untereinander.
Dann kann auch Software limitieren.
Wie gut lassen sich zu erledigende Aufgaben parallelisieren?
Passt die Kombination aus Registern, Pipelines, Cachestufen usw. oder kommt die Software, der betriebssystemseitige Task Scheduler
an Grenzen? Wo liegen wann welche Daten vor, liegen die in einem gemeinsamen Cache, müssen die CPU-intern erst neu verteilt werden uvm.
Mit welcher Geschwindigkeit kann man welche Datenmenge an andere Komponenten übergeben, z.B. der Grafikkarte, dem Arbeitsspeicher usw.?
Irgendwo ist immer ein Flaschenhals.
Idealerweise sind alle Komponenten so ausgewählt das in den benötigten Anwendungsszenaren möglichst alles möglichst lange möglichst voll ausgelastet ist, ohne überlastet zu werden. Dann ziehe ich aus der vorhandenen Hardware die größtmögliche Leistung.
In der Realität ist es aber oft so das ein Teil erst auf die Arbeit eines anderen Teils warten muss.
Windows heißt übersetzt "Weißer Mann warten auf Sanduhr". Das war früher schon so und ist es heute immer noch.
Das Betriebssystem muss Aufgaben möglichst effizient auf die in der CPU verfügbaren Resourcen aufteilen und gleichzeitig muss die Software, die ausgeführt wird so ausgelegt sein das mehrere parallele Ausführungspfade überhaupt ermöglicht werden.
Habe ich eine Software, die so programmiert ist das sie nur auf einem einzelnen Rechenkern laufen kann, nützt mir alles Verteilen nichts mehr. Weil es dann nichts zu verteilen gibt.
Und wenn ich dann mehrere Programm gleichzeitig laufen habe, will jeder zur selben Zeit was vom Kuchen abbekommen.
Nein. Ehr nicht.latiose88 schrieb:
Beispielsweise Windows 11 Pro unterstützt bis zu 128 physische Prozessorkerne und maximal zwei physische Prozessoren gleichzeitig.
Wenn wir noch Hyper-Threading/Simultaneous Multithreading dazu nehmen, wären wir bei maximal 256 Threads.
Man könnte also ein Dual-CPU System mit zwei 64-Kern CPUs inkl. Hyper-Threading/Simultaneous Multithreading nutzen.
Dazu kommen noch maximal 2TB Arbeitsspeicher.
Du könntest z.B. einen Rechner bauen mit zwei AMD Epyc 9575F https://geizhals.de/amd-epyc-9575f-100-000001554-a3332562.html auf z.B. einem
Gigabyte MZ73-LM2 https://geizhals.de/gigabyte-mz73-lm2-9mz73lm2mr-000-3-a3552120.html und dazu noch 24 mal Arbeitsspeicher wie z.B.
Kingston KSM64R52BD4-64MD https://geizhals.de/kingston-server-premier-rdimm-64gb-ksm64r52bd4-64md-a3452640.html
und da drauf ein ganz ordinäres Windows 11 Pro installieren und nutzen...
Das "bisschen" Hardware das du im Rechner hast, ringt dem Betriebssystem nichtmal ein müdes Lächeln ab...
Zuletzt bearbeitet:
