Core-Technologien: die Konzepte von CPU-Cores: big or small, mit Multithreading oder ohne etc.
- Ersteller BavarianRealist
- Erstellt am
BavarianRealist
Grand Admiral Special
- Mitglied seit
- 06.02.2010
- Beiträge
- 3.358
- Renomée
- 80
Es stellt sich mehr und mehr die Frage, welche Ansatz im Aufbau der CPU-Cores ist für welche Anwendung der beste. Den Ansatz von Big/Small-Cores gibt es in den ARM-SoCs schon länger, Intel bringt diesen Ansatz nun in den Desktop. Den Anssatz von 4-fach Multithreading gab es schon, aber womöglich steht MT für energieeffiziente Lösungen komplett im Weg?
In diesem Thread soll es um die verschiedenen Ansätze von CPU (aber auch GPU-) Cores gehen. Wohin könnte die Reise gehen, vor allem in Lowpower-Bereich aber auch für Server-Lösungen.
Mit dem Erscheinen von Intels Alderlake dürfte eine komplett neue - und wohl auch sehr spannende - Diskussion beginnen: und zwar einfach darum, ob der Ansatz mit den Big/Little-Cores erfolgreich sein wird. Sicherlich wird sich Alderlake nun sehr unterschiedlich in den jeweiligen Einsätzen gegenüber den bisherigen Konzepten mit einheitlichen Cores verhalten.
Zudem ein sehr wichtiger Aspekt: für Intel und AMD wird es wichtiger werden, ihre X86-Technologie gegenüber ARM-Ansätzen in den jeweilligen Anwendungen zu "verteidigen". Die nun wieder zunehmende Konkurrenz zwischen AMD und Intel wird am Ende beiden helfen, weil sie schneller wieder besser werden und damit indirekt der ARM-Technologie das Eindringen in die X86-dominierten Felder schwieriger machen.
In diesem Thread soll es um die verschiedenen Ansätze von CPU (aber auch GPU-) Cores gehen. Wohin könnte die Reise gehen, vor allem in Lowpower-Bereich aber auch für Server-Lösungen.
Doppelposting wurde automatisch zusammengeführt:
Mit dem Erscheinen von Intels Alderlake dürfte eine komplett neue - und wohl auch sehr spannende - Diskussion beginnen: und zwar einfach darum, ob der Ansatz mit den Big/Little-Cores erfolgreich sein wird. Sicherlich wird sich Alderlake nun sehr unterschiedlich in den jeweiligen Einsätzen gegenüber den bisherigen Konzepten mit einheitlichen Cores verhalten.
Zudem ein sehr wichtiger Aspekt: für Intel und AMD wird es wichtiger werden, ihre X86-Technologie gegenüber ARM-Ansätzen in den jeweilligen Anwendungen zu "verteidigen". Die nun wieder zunehmende Konkurrenz zwischen AMD und Intel wird am Ende beiden helfen, weil sie schneller wieder besser werden und damit indirekt der ARM-Technologie das Eindringen in die X86-dominierten Felder schwieriger machen.
Zuletzt bearbeitet:
Multithreading nach dem SMT Prinzip halte ich in der breiten Masse nur dann für sinnvoll wenn es um das Stopfen von Auslastungslücken geht da sich die virtuellen Kerne sonst zu sehr gegenseitig behindern. Die unnötig groß zu gestalten um per SMT mehr raus zu bekommen halte ich für meinen Teil für sinnlos da man dann auch gleich mehr Kerne verbauen kann. 4 fach SMT halte ich eher für Sonderfälle der Software Landschaft relevant bei denen prinzipbedingt die Recheneinheiten kaum belastet werden weil die auf irgendetwas warten müssen und entsprechend viel Rechenleistung des Kerns trotz Auslastung liegen bleibt.
Der Vergleich zwischen ARM und x86er/x64 hinkt in meinen Augen immer ziemlich da beide unterschiedliche Ansätze verfolgen.
Die x86er Architektur hat ihren Schwerpunkt auf der Kompatibilität damit auch ältere Programme noch drauf laufen, die ARM Architektur hat hingegen ein eher spezialisiertes Software Umfeld.
Einen 10 Jahre alten PC kann man idR. auch heute noch mit halbwegs aktueller Software nutzen, bei den Smartphones, Tablets und Co. kann man froh sein wenn überhaupt noch ein aktuelles Programm drauf läuft....
Der Vergleich zwischen ARM und x86er/x64 hinkt in meinen Augen immer ziemlich da beide unterschiedliche Ansätze verfolgen.
Die x86er Architektur hat ihren Schwerpunkt auf der Kompatibilität damit auch ältere Programme noch drauf laufen, die ARM Architektur hat hingegen ein eher spezialisiertes Software Umfeld.
Einen 10 Jahre alten PC kann man idR. auch heute noch mit halbwegs aktueller Software nutzen, bei den Smartphones, Tablets und Co. kann man froh sein wenn überhaupt noch ein aktuelles Programm drauf läuft....
Ich denke die große Kunst und der Grund warum AMD im Moment keinen Bedarf für big/little hat ist ein gut balanciertes Design.
Im Normalfall würde es für Intel keinen Grund für die big cores geben wenn ihre little cores bei angenommen 30% weniger Leistung ein Viertel so groß und 4 Mal effizienter sind. Das zeigt nur wie ineffizient die big cores mittlerweile sind und nur der sprichwörtliche Holzhammer um die Leistungskrone zurück zu bekommen.
Für ein gutes Design müsste es aber das Ziel sein ausschließlich auf effiziente Kerne zu setzen. Und je nach Leistungsbereich können dann gegebenenfalls andere Kerne effizienter sein (siehe ARM). Bei Alder Lake scheint mir dass jedoch nicht der Fall zu sein.
Irgendwo ist nun Mal auch der Punkt erreicht wo man bei einer bestimmten Fertigung mit immer mehr Transistoren (längeren Pipelines usw) bei einem Prozessor am Ende sogar weniger Leistung raus bekommt. Weil entweder dann die IPC sinkt oder der Takt. Das konnte man früher schon am Prescott beobachten.
Erst mit verbesserter Fertigung (kleinere Transistoren oder auch 3D Stacking) kann das Design weiter wachsen und muss neu balanciert werden.
Ein effizienter Kern der möglichst von 1W bis 15W gut skaliert wäre damit für Notebook bis Desktop und Server ideal. Intels little core scheint noch nicht in den hohen Leistungsbereich zu skalieren während der big core am oberen Anschlag hängt und selbst da nicht effizient ist.
Im Normalfall würde es für Intel keinen Grund für die big cores geben wenn ihre little cores bei angenommen 30% weniger Leistung ein Viertel so groß und 4 Mal effizienter sind. Das zeigt nur wie ineffizient die big cores mittlerweile sind und nur der sprichwörtliche Holzhammer um die Leistungskrone zurück zu bekommen.
Für ein gutes Design müsste es aber das Ziel sein ausschließlich auf effiziente Kerne zu setzen. Und je nach Leistungsbereich können dann gegebenenfalls andere Kerne effizienter sein (siehe ARM). Bei Alder Lake scheint mir dass jedoch nicht der Fall zu sein.
Irgendwo ist nun Mal auch der Punkt erreicht wo man bei einer bestimmten Fertigung mit immer mehr Transistoren (längeren Pipelines usw) bei einem Prozessor am Ende sogar weniger Leistung raus bekommt. Weil entweder dann die IPC sinkt oder der Takt. Das konnte man früher schon am Prescott beobachten.
Erst mit verbesserter Fertigung (kleinere Transistoren oder auch 3D Stacking) kann das Design weiter wachsen und muss neu balanciert werden.
Ein effizienter Kern der möglichst von 1W bis 15W gut skaliert wäre damit für Notebook bis Desktop und Server ideal. Intels little core scheint noch nicht in den hohen Leistungsbereich zu skalieren während der big core am oberen Anschlag hängt und selbst da nicht effizient ist.
BavarianRealist
Grand Admiral Special
- Mitglied seit
- 06.02.2010
- Beiträge
- 3.358
- Renomée
- 80
Ein paar interessante Infos dazu, wie aufwändig so ein Core für den jeweiligen Prozess ausbalanciert sein muss, um möglichst den perfekten sweet-spot zu treffen hier von AMDs Chief Architekt Mike Clark auf ananatech.
SMT muss nicht zwingend schlecht sein in Bezug auf die Effizienz. Intel hatte bei den ersten Atoms Multithreading, aber keine Out-of-order execution, und dies damals damit begründet, dass SMT weniger aufwändig sei als Out-of-order execution. SMT hat bei den alten Atoms viel Leistung gebracht, bei einem In-Order-Design hat man halt sehr viele Lücken in der Befehlsabarbeitung.
Interessanterweise wurde Out-of-order aber früher eingeführt als SMT, was vermutlich dem damals fehlenden Multithreading in den verbreiteten Betriebssystemen geschuldet war (Unix konnte es natürlich, aber in der Unix-Welt hat man eher SMP mit mehreren "richtigen" Prozessoren gemacht). In der Windows-Welt gab es das aber nur bei NT und später ab XP auf dem Desktop vom Heimanwender. Folglich war es attraktiver, den einzelnen Kern zu beschleunigen, als einen zweiten Thread zur Verfügung zu stellen (und ein K5 oder Pentium Pro hatte im Vergleich mit moderneren Chips ein eher schmales Design).
Interessant finde ich in dem Zusammenhang die Aussage von Mike Clark, der sagt dass SMT nicht ganz so trivial ist (Er setzt es natürlich nicht in ein Verhältnis zu Out-of-order, weil das heute bei AMD64 die Norm ist).
Bei den hybriden Chips von Intel bin ich nicht soo überzeugt vom Konzept. Dass man als Hersteller unterschiedlich grosse Cores hat finde ich durchaus interessant (aktuell sehe ich bei AMD z.B. kaum richtig sparsame Embedded-Chips als nachfolger der alten Chips mit den kleinen Kernen), aber verschieden grosse Cores auf einem Chips verkomplizieren das Scheduling. Bei Android auf ARM und bei Apple scheint man das im Griff zu haben, aber ich bin mir nicht so sicher, wie erfolgreich das ausserhalb des mobilen Bereich sein wird, wenn der Kunde eine Wahl hat. Bei ARM findet man das auch nur im Mobile-Bereich, die Serverchips bestehen aus lauter identischen Cores.
Im Serverbereich wird meines Erachtens kaum jemand verschieden schnelle Cores haben wollen, dort zählt meist der Durchsatz, und falls die kleinen Cores effizienter sind, könnte ich mir sogar vorstellen dass die Kunden in gewissen Bereichn dann lieber z.b. 48 kleine als 24 grosse und 8 kleine haben. Es gibt natürlich auch Kunden die möglichst schnelle Cores haben wollen (meist aus Lizenzgründen, oder für Sachen wie high frequency trading), die wollen dann aber erst reicht keine langsamen Cores als Addon und würden die im BIOS direkt deaktivieren (falls das möglich ist).
Interessanterweise wurde Out-of-order aber früher eingeführt als SMT, was vermutlich dem damals fehlenden Multithreading in den verbreiteten Betriebssystemen geschuldet war (Unix konnte es natürlich, aber in der Unix-Welt hat man eher SMP mit mehreren "richtigen" Prozessoren gemacht). In der Windows-Welt gab es das aber nur bei NT und später ab XP auf dem Desktop vom Heimanwender. Folglich war es attraktiver, den einzelnen Kern zu beschleunigen, als einen zweiten Thread zur Verfügung zu stellen (und ein K5 oder Pentium Pro hatte im Vergleich mit moderneren Chips ein eher schmales Design).
Interessant finde ich in dem Zusammenhang die Aussage von Mike Clark, der sagt dass SMT nicht ganz so trivial ist (Er setzt es natürlich nicht in ein Verhältnis zu Out-of-order, weil das heute bei AMD64 die Norm ist).
Bei den hybriden Chips von Intel bin ich nicht soo überzeugt vom Konzept. Dass man als Hersteller unterschiedlich grosse Cores hat finde ich durchaus interessant (aktuell sehe ich bei AMD z.B. kaum richtig sparsame Embedded-Chips als nachfolger der alten Chips mit den kleinen Kernen), aber verschieden grosse Cores auf einem Chips verkomplizieren das Scheduling. Bei Android auf ARM und bei Apple scheint man das im Griff zu haben, aber ich bin mir nicht so sicher, wie erfolgreich das ausserhalb des mobilen Bereich sein wird, wenn der Kunde eine Wahl hat. Bei ARM findet man das auch nur im Mobile-Bereich, die Serverchips bestehen aus lauter identischen Cores.
Im Serverbereich wird meines Erachtens kaum jemand verschieden schnelle Cores haben wollen, dort zählt meist der Durchsatz, und falls die kleinen Cores effizienter sind, könnte ich mir sogar vorstellen dass die Kunden in gewissen Bereichn dann lieber z.b. 48 kleine als 24 grosse und 8 kleine haben. Es gibt natürlich auch Kunden die möglichst schnelle Cores haben wollen (meist aus Lizenzgründen, oder für Sachen wie high frequency trading), die wollen dann aber erst reicht keine langsamen Cores als Addon und würden die im BIOS direkt deaktivieren (falls das möglich ist).
Zuletzt bearbeitet:
Das lag aber weniger an SMT sondern dem eher ineffizienten In-order Design das bereits den Pentium 4 im Bezug auf den Takt nicht allso performant machte. Diesen Effizienzverlußt durch die schlecht ausgelastete Pipeline versuchte man ganz einfach per SMT auszugleichen. Das Problem bei der Sache, SMT kann nur da greifen wo SMP ebenfalls greift denn der zweite virtuelle Kern wird von der Software ebenso angesprochen wie ein weiterer physischer Kern.
Da man sich aber gerade im Bereich der x86er Software ziemlich wenig um das Multithreading Thema gekümmert hat und sich dabei nur allso ger auf "nicht alles ist parallelisierbar" berief war der Nutzen im Alltag schon extrem überschaubar. Der Kunde kann ja einfach schnellere Hardware kaufen um das durch die Software verschenkte Leistungspotential auszugleichen. Hauptsache es läuft beim Marktführer schnell genug.
Im ARM Sektor ist die Software in dem Bereich deutlich weiter, was wohl nicht zuletzt an der deutlich geringeren Einzelkernleistung und der idR. nicht austauschbaren Hardware liegen dürfte. Da will man ganz einfach per Software so viel Leistung aus der Hardware rausholen wie möglich.
Da man sich aber gerade im Bereich der x86er Software ziemlich wenig um das Multithreading Thema gekümmert hat und sich dabei nur allso ger auf "nicht alles ist parallelisierbar" berief war der Nutzen im Alltag schon extrem überschaubar. Der Kunde kann ja einfach schnellere Hardware kaufen um das durch die Software verschenkte Leistungspotential auszugleichen. Hauptsache es läuft beim Marktführer schnell genug.
Im ARM Sektor ist die Software in dem Bereich deutlich weiter, was wohl nicht zuletzt an der deutlich geringeren Einzelkernleistung und der idR. nicht austauschbaren Hardware liegen dürfte. Da will man ganz einfach per Software so viel Leistung aus der Hardware rausholen wie möglich.
Die Leistungsfähigkeit des x86 Designe ist das eine die Umsetzung in Hardware das andere. Wie viel verbraucht ein Transistor beim Schaltvorgang, wie hoch muss ich mit dem Takt um auf die Konkurrenz aufzuschließen bis hin zu den Leckströmen.
Da hat AMD die Messlatte auch sehr hoch gesetzt wenn man von der Aktuellen APU im mobilen Bereich ausgeht. Gut taktbar bei sehr wenig Verbrauch.
AL mit 5,2 GHz (Big 41,5GHz) und die 3,8 GHz (Litle 30,4 GHz) Um in den Leistungsbereich vom 5950x auf Default zu kommen. Vom Verbrauch her sind das einfach Welten.
Und wer benutzt im Desktopbereich Energiesparmodi? Ist alles was für mobile Geräte.
Da hat AMD die Messlatte auch sehr hoch gesetzt wenn man von der Aktuellen APU im mobilen Bereich ausgeht. Gut taktbar bei sehr wenig Verbrauch.
AL mit 5,2 GHz (Big 41,5GHz) und die 3,8 GHz (Litle 30,4 GHz) Um in den Leistungsbereich vom 5950x auf Default zu kommen. Vom Verbrauch her sind das einfach Welten.
Und wer benutzt im Desktopbereich Energiesparmodi? Ist alles was für mobile Geräte.
Praktisch jeder denn Geschichten denn auf viele die zum Einsatz kommen haben wir ohnehin keinen Einfluss.
So wie das Big/Small Core Konzept bei AL umgesetzt wurde macht das für mich überhaupt keinen Sinn. Bei AL können die Big Cores AVX 512 nicht nutzen, da Windows nicht mit unterschiedlichen Befehlssätzen von Cores umgehen kann. Alle Cores müssen beim aktuellen Windows den gleichen Befehlssatz ausführen. Solange das so ist, macht das Big/Small Core Konzept keinen Sinn. Wäre das anders dann könnte ich mir schon vorstellen, dass man KI-Engine, AVX 512, etc. nur auf Big Cores implementiert und Small Cores ohne diese Befehlserweiterungen.
Wobei ich sagen muss das die Relevanz von AVX512 vor allem im Desktop Bereich gegen 0 geht und sinnvoll ist es für das Verschieben der Arbeit bei wenig Last auf die little Cores durchaus denn wenn das Programm es nutzt und mitgeteilt bekommen hat das der Prozessor es unterstützt dann würde es nach dem Verschieben knallen oder sie würden auf den Big Cores fest sitzen und das Design wäre für die Katz. Wird AVX512 vom Programm nicht unterstützt dann ist das Fehlen von AVX512 ganz einfach irrelevant.
Edit:
Ich kann mir vorstellen das AVX512 den HPC Modellen vorbehalten sein könnte die dann wiederum auf die little Cores verzichten würden.
Edit:
Ich kann mir vorstellen das AVX512 den HPC Modellen vorbehalten sein könnte die dann wiederum auf die little Cores verzichten würden.
Zuletzt bearbeitet:
Es ging mir nicht um die Sinnhaftigkeit von AVX512, sondern dass man hier Cores verbaut und mit Transistoren die das AVX512 ausführen könnten und damit Platz verbrauchen der aber gar nicht genutzt werden kann. Die ganzen Big Cores sind doch für die Katz, da sie nur Platz verbrauchen und dann doch wiederum nur das gleiche wie die Small Cores ausführen können. Warum also nicht gleich auf die Big Cores verzichten und nur Small Cores implementieren.
Der Pentium 4 (Netburst) hatte ein out-of-order Design, aber eine sehr lange Pipeline, was teuer war wenn die Sprungvorhersage danebengeraten hat.
Beim P4 brachte es wohl so 20-30% gemäss Benchmarks die ich jetzt gegoogelt habe. Bei den Atoms war es meines Wissens einiges mehr.
SMT war beim P4 nach damaliger Meinung vor allem die Brechstange, um noch etwas mehr Leistung rauszuholen.
SMT (oder SMP) war IMHO schon zur Zeit vom P4 nützlich, schon damals lief auf fast jedem Windows mindestens ein Virenscanner im Hintergrund (Peer2Peer-Downloadprogramme waren auch noch in Mode), auf Linux war SMP schon länger ein Thema und wurde kontinuierlich verbessert.
Die Software dürfte häufig auch einfach jünger sein. Android oder IOS und die ganzen Apps haben die Entwicklung viel später begonnen als viele Desktop-Software. Bei den Desktop-Browsern hat man die Aufteilung in Threads für einzelne Tabs teilweise fast eher als Sicherheitsfeature gesehen.
In anderen Bereichen ist es aber auch eine Frage des Problems, bei neuen Formaten für Bild oder Video wird heute darauf geachtet, dass sie sich gut parallelisieren lassen, das war früher sicher weniger ein Thema.
Spielkonsolen sind dann eine andere Anwendung, wo die Programmierer darauf achten, die Hardware maximal auszunutzen.
Maverick-F1
Grand Admiral Special
Hatte mich da meine Erinnerung zum Design getäuscht? Mir war so als wäre Intel bei der Netburst Architektur zum einem in-order Design gewechselt um mehr Takt rausquetschen zu können. Als die Meltdown/Spectre Probleme hoch kochten meine ich auch genau das gelesen zu haben. 
SMT war damals vor XP bei Windows sogar gern mal schädlich für die Performance weil z.B. unter Windows 2000 kein Unterschied zwischen den virtuellen und den physischen Kernen gemacht wurde. Die wurden dann nach SMP Prinzip schön gleichmäßig verteilt und bremsten sich dann gegenseitig aus. Die Sheduler Anpassung die entsprechend priorisierte gab es erst mit XP.
Aufgrund des Arbeitsprinzips von SMT ist bei 2 Threads pro Kern eine Leistungsverdoppelung bis hin zu einem Leistungsverlußt letztendlich alles drin, das ist in erster Linie von der Frage abhängig wie gut der erste Thread den Kern bereits ausgelastet hat.
Ich halte es für ausgeschlossen das es am Alter der Software liegt denn so lange wird wohl kaum daran rumprogrammiert.
Unterm Strich würde ich sagen das die Desktop Software der Hardware beim Thema Multithreading gut und gern 10 Jahre oder mehr hinterher hinkt, denn da boten AMDs FX und Intels Desktop i7 die besagten 8 Threads die heute immer öfter auch sinnvoll genutzt werden.
bei der Nutzung der Befehlssätze vielleicht ein paar Jahre weniger.
Das Grundproblem der x86er Software dürfte eher sein das es deutlich bequemer und kostensparender ist nur so viel zu verändern und zu optimieren das es beim Marktführer am schnellsten läuf. Das spart Arbeit, Weiterbildungsmaßnahmen, die meisten potentiellen Kunden sind zufrieden und bekommen die brach liegende Rechenleistung durch die ineffiziente Nutzung der Hardware aufgrund fehlender Vergleichsmöglichkeiten eh nicht mit.
SMT war damals vor XP bei Windows sogar gern mal schädlich für die Performance weil z.B. unter Windows 2000 kein Unterschied zwischen den virtuellen und den physischen Kernen gemacht wurde. Die wurden dann nach SMP Prinzip schön gleichmäßig verteilt und bremsten sich dann gegenseitig aus. Die Sheduler Anpassung die entsprechend priorisierte gab es erst mit XP.
Aufgrund des Arbeitsprinzips von SMT ist bei 2 Threads pro Kern eine Leistungsverdoppelung bis hin zu einem Leistungsverlußt letztendlich alles drin, das ist in erster Linie von der Frage abhängig wie gut der erste Thread den Kern bereits ausgelastet hat.
Ich halte es für ausgeschlossen das es am Alter der Software liegt denn so lange wird wohl kaum daran rumprogrammiert.
Unterm Strich würde ich sagen das die Desktop Software der Hardware beim Thema Multithreading gut und gern 10 Jahre oder mehr hinterher hinkt, denn da boten AMDs FX und Intels Desktop i7 die besagten 8 Threads die heute immer öfter auch sinnvoll genutzt werden.
bei der Nutzung der Befehlssätze vielleicht ein paar Jahre weniger.
Das Grundproblem der x86er Software dürfte eher sein das es deutlich bequemer und kostensparender ist nur so viel zu verändern und zu optimieren das es beim Marktführer am schnellsten läuf. Das spart Arbeit, Weiterbildungsmaßnahmen, die meisten potentiellen Kunden sind zufrieden und bekommen die brach liegende Rechenleistung durch die ineffiziente Nutzung der Hardware aufgrund fehlender Vergleichsmöglichkeiten eh nicht mit.
SMT ist auch nicht gleich SMT bei einem anderen Prozessor. Man kann die Threads alternierend, parallel mit mehreren Einheiten und hierbei teils dezidiert oder mit geteilten Ressourcen ausführen. Je nachdem wie viele Zusatzeinheiten man spendiert ist am Ende auch der Performancegewinn größer oder kleiner.
Bei Bulldozer hat man hier schon sehr viele verschiedene Konzepte innerhalb eines Moduls ausprobiert mit teils wohl mehr und weniger Erfolg.
Generell kann man wohl sagen, dass bei sehr breiten Designs (oder mieser Auslastung) der Aufwand für ein thread tagging sehr gering und der mögliche Nutzung relativ groß wird.
Interessanterweise hat sich Intel bei ihren little Kernen gegen SMT entschieden. Vermutlich sind diese also schmaler als die bisherigen Kerne und deren Auslastung meist sehr hoch.
Bei Bulldozer hat man hier schon sehr viele verschiedene Konzepte innerhalb eines Moduls ausprobiert mit teils wohl mehr und weniger Erfolg.
Generell kann man wohl sagen, dass bei sehr breiten Designs (oder mieser Auslastung) der Aufwand für ein thread tagging sehr gering und der mögliche Nutzung relativ groß wird.
Interessanterweise hat sich Intel bei ihren little Kernen gegen SMT entschieden. Vermutlich sind diese also schmaler als die bisherigen Kerne und deren Auslastung meist sehr hoch.
Aufgeteilte Einheiten entsprechen dem CMT Design das bei Bulldozer zum Einsatz kam und deutlich mehr Ausführungseinheiten und Cache (jeder Thread benötigt auch ein Stück vom Cache) zu verbauen als mit einem Thread genutzt werden kann um damit die SMT Skalierung zu pushen wird auch ganz schnell sinnlos wenn der Kern dadurch so aufgeblasen wird das man gleich entsprechend viele normale verbauen kann. Andere Faktoren hängen wiederum zu stark von der eingesetzten Software ab.
Gerade für den Desktop Bereich war ja der große Vorteil der bisherigen SMT Ausführung das es Leistung freisetzt und dabei kaum Platz einnimmt. Genau der Vorteil geht aber den Bach runter wenn man die Kerne für eine bessere Skalierung künstlich aufbläst.
Gerade für den Desktop Bereich war ja der große Vorteil der bisherigen SMT Ausführung das es Leistung freisetzt und dabei kaum Platz einnimmt. Genau der Vorteil geht aber den Bach runter wenn man die Kerne für eine bessere Skalierung künstlich aufbläst.
Dem Bulldozer hat vor allem der MicroOp-Cache gefehlt. Bin mir auch sicher, dass wenn man heute Zen um das CMT wie bei Bulldozer ergänzen würde, dass man damit wesentlich bessere Ergebnisse erzielen würde. Cache sollte ja mit 3D-VCache nicht mehr so das Problem sein.
Die Kerne müssen ja nicht zwingend für SMT verbreitet worden sein, sondern um eine IPC Steigerung zu erreichen. Das wiederum führt zwangsweise dazu dass unterschiedliche Software den Kern unterschiedlich stark auslastet und damit wird SMT sinnvoll. Nur muss bei einer SMT Implementierung das Design entsprechend wieder neu/anders balanciert werden wenn es am Ende gut funktionieren soll.
Und ja das Bulldozer Konzept hatte durchaus seine Stärken nur leider genauso auch größere Schwächen. Zu lange Pipelines mit schlechter Sprungvorhersage und zu langsame/kleine Caches drücken die IPC extrem.
Und ja das Bulldozer Konzept hatte durchaus seine Stärken nur leider genauso auch größere Schwächen. Zu lange Pipelines mit schlechter Sprungvorhersage und zu langsame/kleine Caches drücken die IPC extrem.
Abseits neuerer Befehlssätze war die Bulldozer Architektur pro Thread und Takt langsamer als der Phenom 2. Das Design krankte noch an ganz anderen Sachen. Meiner Meinung nach war das gesammte L2 Cache System suboptimal.
Der 3D Cache betrifft übrigens nur den L3 Cache, in den L1 und L2 Cache müssen die Daten der Threads aber auch passen um performant zu laufen und die sind nochmal deutlich relevanter für die Performance als der L3. Um mehr Recheneinheiten überhaupt nutzen zu können darf dann auch noch der gesammte Frontend Part Aufgeblasen werden usw. usw. .....
Es läßt sich viel machen aber die Frage ist eher ob es auch sinnvoll ist.
@tex_
Mit den zusätzlichen Threads läßt sich bei SMT nur das nutzen was der erste Thread liegen läßt und die Anzahl der Recheneinheiten des Kerns läßt sich nicht beliebig erweitern weil die Software damit nicht hinreichend skaliert. Mehr lassen sich dann mit einem Thread einfach nicht mehr vernünftig auslasten und blähen ohne Sachen wie SMT dann nur noch das Chip Design auf und fressen damit vor allem Platz, Platz den man dann auch einfach für einen weiteren Kern nutzen könnte.
Sachen wie 4fach SMT sind einfach zu speziell um sie in einem Desktop Produkt sinnvoll zu nutzen und solange wir beim 2 fach SMT über eine Skalierung von deutlich unter 100% reden ist es ohnehin komplett sinnlos. Wo soll die Leistung für die zusätzlichen Threads auch her kommen wenn der Rest bereits mit dem zweiten Thread nutzbar gemacht wird?
Der 3D Cache betrifft übrigens nur den L3 Cache, in den L1 und L2 Cache müssen die Daten der Threads aber auch passen um performant zu laufen und die sind nochmal deutlich relevanter für die Performance als der L3. Um mehr Recheneinheiten überhaupt nutzen zu können darf dann auch noch der gesammte Frontend Part Aufgeblasen werden usw. usw. .....
Es läßt sich viel machen aber die Frage ist eher ob es auch sinnvoll ist.
Doppelposting wurde automatisch zusammengeführt:
@tex_
Mit den zusätzlichen Threads läßt sich bei SMT nur das nutzen was der erste Thread liegen läßt und die Anzahl der Recheneinheiten des Kerns läßt sich nicht beliebig erweitern weil die Software damit nicht hinreichend skaliert. Mehr lassen sich dann mit einem Thread einfach nicht mehr vernünftig auslasten und blähen ohne Sachen wie SMT dann nur noch das Chip Design auf und fressen damit vor allem Platz, Platz den man dann auch einfach für einen weiteren Kern nutzen könnte.
Sachen wie 4fach SMT sind einfach zu speziell um sie in einem Desktop Produkt sinnvoll zu nutzen und solange wir beim 2 fach SMT über eine Skalierung von deutlich unter 100% reden ist es ohnehin komplett sinnlos. Wo soll die Leistung für die zusätzlichen Threads auch her kommen wenn der Rest bereits mit dem zweiten Thread nutzbar gemacht wird?
Zuletzt bearbeitet:
Intel hat die Pipeline extrem lang gemacht um so den Takt hochtreiben zu können, ich konnte mit einer Recherche aber keine Hinweise auf ein in-order Design finden. Bezüglich Meltdown/Spectre kenne ich den genauen Hintergrund nicht, ich habe um Netburst aber auch immer einen weiten Bogen gemacht. War für mich immer eine Elektroheizung mit AbrechenleistungHatte mich da meine Erinnerung zum Design getäuscht? Mir war so als wäre Intel bei der Netburst Architektur zum einem in-order Design gewechselt um mehr Takt rausquetschen zu können. Als die Meltdown/Spectre Probleme hoch kochten meine ich auch genau das gelesen zu haben.
Wie viele Leute waren effektiv davon betroffen, weil sie mehr als einen echten Kern mit SMT im System hatten? Die Pentium 4 waren single-Core, beim Pentium D weiss ich nicht wie gut sich der verkauft hat, ich kenne den nur von Wikipedia.
Die Xeons in den Servern waren sicher ein anderes Thema, zumindest in der Linux-Welt hat man sich aber schon mit dem AMD Opteron stark damit beschäftigt, den Scheduler noch besser auf Systeme zu optimieren, die nicht streng symmetrisch sind (Die Opteron waren als Zweisockel-System die ersten NUMA-Maschinen in der PC-Welt).
Nach Netburst kamen mit Core und Core2 erst mal Chips auf den Markt, die kein SMT hatten, und zum Zeitpunkt der Einführung von den Core i-Chips war Windows 2000 nahe dem Supportende.
Du beschreibst schön, wieso es eben doch am Alter liegt. Viele Software, die wir auf dem Desktop nutzen, ist im Kern sehr alt, und es wird einfach jeweils die neue Funktionalität ergänzt. Ein anschauliches Beispiel ist da z.B. Adobe Photoshop, da wurde in der Vergangenheit immer mal wieder gross demonstriert, wie stark die neue Intel-CPU dank Spezialfunktion XY die Software beschleunigt. Bewiesen wurde es dann mit EINEM Plugin, und der Rest der Software war davon unberührt (es lässt sich natürlich auch nicht alles mit z.B. SSE beschleunigen).
Aber kein Hersteller schreibt die Software in der neuen Version komplett neu oder optimiert sie auf aktuelle Hardware. Dazu kommt auch, dass der Hersteller die Software in der Regel auf die Hardware auslegt, die bei den Kunden effektiv im Einsatz ist. Den Supportaufwand, wenn nur schon 5% der Kunden die Software nicht starten können, will sich schlichtwegs keiner antun.
Als Betriebssystemhersteller kann Microsoft einen Mindeststand voraussetzen, und ansonsten das Update oder die Installation verweigern. Aber als Hersteller von irgend einer Business-Software hat man vermutlich weniger Support-Aufwand wenn es langsam läuft, als gar nicht. Heute wird ja häufig nicht mal mehr eine Mindestvoraussetzung der Hardware angegeben, früher stand bei jedem Software-Karton aussen drauf, was für Hardware der Kunde haben musste.
Abseits von irgendwelchen Spezialanwendungen kann man auch nicht erwarten, dass die Kunden alle zwei bis drei Jahre die Hardware tauschen, und dann auch noch das beste am Markt verfügbare Modell wählen. Jeder der in irgend einer Form IT betreut (privat oder beruflich), kann bestätigen, dass teils echt alte Hardware im Einsatz ist, die weit von 8 Threads entfernt ist.
In der Konsequenz findet man auch heute noch viele Maschinen mit 4 Threads, dazu kommt noch die Produktpolitik von Intel, welche bei den Pentium und Celeron gerne mal den Befehlssatz beschneidet. Man sieht die Diskussion ja schön, wenn die Gamer wieder klagen, weil der Hersteller in irgend einem neuen Patch-Level von einem Game den Compiler etwas moderner eingestellt hat, und einige ältere AMD-CPUs nicht mehr unterstützt werden, weil ein Befehl fehlt. Man kann sich das Steam Hardware and Software Survey für einen Überblick ansehen, und das sind die Gamer, nicht die Leute, welche sich vor ein paar Jahren bei der Aktion vom Discounter einen "Volks-PC" gekauft haben.
Die einzigen, die in meiner Wahrnehmung aktuell wirklich bemüht sind, das Maximum an Optimierung rauszuholen, dass sind die Entwickler vom AV1-Decoder dav1d. Die haben ihre Software in den letzten Jahren konsequent darauf optimiert, verschiedene Versionen von SSE und AVX maximal auszureizen. Es mag da bestimmt noch weitere geben, aber die Regel ist das nicht.
@Cmdr_Zod
Der Pentium 4 startete bereits zu Zeiten des Athlons, die Athlon XPs waren Singlecores und mit dem Athlon MP konnte man 2 Prozessoren in einem Board nutzen. Die Variante nutzte ich damals. In der Server Welt gab es multi CPU Systeme schon deutlich länger.
Mit dem Athlon 64 X2 fing AMD im Desktop Bereich mit den Dualcores an, Intel mit dem Pentium D.
Damals wurde dennoch fröhlich den höher taktenden Singlecores gehuldigt weil es ja ach so unmöglich ist alles zu parallelisieren. An der Argumentation hat sich bis heute nichts geändert aber einen Singlecore will dennoch keiner mehr haben.
Und nein, ich beschrieb nicht warum das Thema Software am Alter liegt sonder am fehlenden Wille der Software Optimierung.
Hier greift bei den ARM Geräten eher das gleiche Prinzip wie bei den Spiele Konsolen, man muss zwangsläufig mehr in die Optimierung der Software investieren weil die Leistungsfähigkeit der Hardware begrenzt und nicht aufrüstbar ist. Man muss sich also mehr anstrengen damit das Produkt bei den Kunden vernünftig läuft. Man macht also nur so viel wie man muss um das Produkt verkaufen zu können und entsprechend nutzlos sind dann die entsprechenden Hochleistungsprozessoren für das Desktop Umfeld weil die zusätzlichen Kerne von den Programmen ganz einfach nicht genutzt werden und der mögliche Leistungssprung damit ausfällt.
Und ja, gerade im Spiele Bereich wird die Software bei jeder Portierung auf eine andere Plattform mehr oder weniger neu geschrieben. Der Schwerpunkt der Entwicklung liegt auf den Konsolen deren Fähigkeiten der Hardware bekannt sind und nicht selten laufen Portierungen auf die PC Plattform dann deutlich schlechter. Soll der Kunde die schlechte Optimierung eben mit schnellerer Hardware ausgleichen. Eine Option die bei den Konsolen ganz einfach entfällt. Entweder läuft die Software vernünftig oder eben nicht und wird dann auch nicht gekauft.
Im übrigen ging es auch nicht darum Anforderungen hochzuschrauben um die Prozessoren bis an die Grenze zu belasten sondern lediglich darum sie auch auslasten zu können.
In dem Fall reichen dann auch ganz schnell mehr langsamere Kerne um auf das gleiche Endergebnis zu kommen und die high FPS Fraktion kommt auch auf ihre Kosten weil man durch die zusätzliche Rechenleistung das CPU Limit erheblich weiter nach oben schieben könnte als mit reiner Taktsteigerung.
Das bedeutet im Umkehrschluss angesichts der notorischen Unterforderung der Hardware aufgrund mangelhaften Multithreadings das diese sogar länger genutzt werden könnte.
Der Pentium 4 startete bereits zu Zeiten des Athlons, die Athlon XPs waren Singlecores und mit dem Athlon MP konnte man 2 Prozessoren in einem Board nutzen. Die Variante nutzte ich damals. In der Server Welt gab es multi CPU Systeme schon deutlich länger.
Mit dem Athlon 64 X2 fing AMD im Desktop Bereich mit den Dualcores an, Intel mit dem Pentium D.
Damals wurde dennoch fröhlich den höher taktenden Singlecores gehuldigt weil es ja ach so unmöglich ist alles zu parallelisieren. An der Argumentation hat sich bis heute nichts geändert aber einen Singlecore will dennoch keiner mehr haben.
Und nein, ich beschrieb nicht warum das Thema Software am Alter liegt sonder am fehlenden Wille der Software Optimierung.
Hier greift bei den ARM Geräten eher das gleiche Prinzip wie bei den Spiele Konsolen, man muss zwangsläufig mehr in die Optimierung der Software investieren weil die Leistungsfähigkeit der Hardware begrenzt und nicht aufrüstbar ist. Man muss sich also mehr anstrengen damit das Produkt bei den Kunden vernünftig läuft. Man macht also nur so viel wie man muss um das Produkt verkaufen zu können und entsprechend nutzlos sind dann die entsprechenden Hochleistungsprozessoren für das Desktop Umfeld weil die zusätzlichen Kerne von den Programmen ganz einfach nicht genutzt werden und der mögliche Leistungssprung damit ausfällt.
Und ja, gerade im Spiele Bereich wird die Software bei jeder Portierung auf eine andere Plattform mehr oder weniger neu geschrieben. Der Schwerpunkt der Entwicklung liegt auf den Konsolen deren Fähigkeiten der Hardware bekannt sind und nicht selten laufen Portierungen auf die PC Plattform dann deutlich schlechter. Soll der Kunde die schlechte Optimierung eben mit schnellerer Hardware ausgleichen. Eine Option die bei den Konsolen ganz einfach entfällt. Entweder läuft die Software vernünftig oder eben nicht und wird dann auch nicht gekauft.
Im übrigen ging es auch nicht darum Anforderungen hochzuschrauben um die Prozessoren bis an die Grenze zu belasten sondern lediglich darum sie auch auslasten zu können.
In dem Fall reichen dann auch ganz schnell mehr langsamere Kerne um auf das gleiche Endergebnis zu kommen und die high FPS Fraktion kommt auch auf ihre Kosten weil man durch die zusätzliche Rechenleistung das CPU Limit erheblich weiter nach oben schieben könnte als mit reiner Taktsteigerung.
Das bedeutet im Umkehrschluss angesichts der notorischen Unterforderung der Hardware aufgrund mangelhaften Multithreadings das diese sogar länger genutzt werden könnte.
Softwareanpassungen sind schwierig, man hat jetzt ein CPU Vielfalt von irgendwelchen alten Krücken bis hin zu brandneu.
Kernelversionen die es bei Linux alleine nur für AMD optimiert gibt. Zen1, Zen2, Zen3/Zen3 mit großem L3 und Raven für APU. Im Desktop Betrieb merkt man keinen Unterschied zum normalem Kernel. Bei Berechnungen gehen die Zeiten runter und die GPU Benches laufen ein bischen besser. Kann mir vorstellen das es auch spezielle Versionen für Intel geben wird.
Kernelversionen die es bei Linux alleine nur für AMD optimiert gibt. Zen1, Zen2, Zen3/Zen3 mit großem L3 und Raven für APU. Im Desktop Betrieb merkt man keinen Unterschied zum normalem Kernel. Bei Berechnungen gehen die Zeiten runter und die GPU Benches laufen ein bischen besser. Kann mir vorstellen das es auch spezielle Versionen für Intel geben wird.
Für Serverbetreiber zum Beispiel machen solchen einseitigen Optimierungen viel Sinn. Da weiß man schließlich welche Hardware läuft und kann genau auf die eigenen Anforderungen den Kernel anpassen.
Bei normaler Consumer Software ist das natürlich deutlich schwieriger. Da kann man froh sein wenn es einen Codepfad mit AVX und einen ohne gibt.
Bei Android wird meines Wissens nach die Software vom Playstore erst auf dem Gerät kompiliert (verbessert mich wenn ich da falsch liege). Dabei könnte der Compiler natürlich auch sofort Optimierungen für die verbaute CPU durchführen.
Bei normaler Consumer Software ist das natürlich deutlich schwieriger. Da kann man froh sein wenn es einen Codepfad mit AVX und einen ohne gibt.
Bei Android wird meines Wissens nach die Software vom Playstore erst auf dem Gerät kompiliert (verbessert mich wenn ich da falsch liege). Dabei könnte der Compiler natürlich auch sofort Optimierungen für die verbaute CPU durchführen.
