News Qualcomm Centriq 2400: Mit 48 Kernen und 60 MB L3-Cache gegen Intels Xeon

[Simpson474]

Bei Intel (ab Haswell) kannst du da von Faktor 4 ausgehen. Mit AVX 512 eher Faktor 8.

Ein Haswell mit SSE (ohne AVX/FMA) hat 4 DP FLOP pro Takt und 8 SP Flop pro Takt.

 

[Simon]

Laut Qualcomm liegt in internen Tests die Integer-Leistung in einigen Szenarien auf dem Level von Intel Xeon Platinum, jedoch bei deutlich geringerer Leistungsaufnahme.

"Laut Qualcomm" <-- Fehler 1: Messung vom Hersteller
"internen Tests" <-- Fehler 2: nicht von unabhängiger Quelle und nachvollziehbar transparent
"die Integer-Leistung" <-- Fehler 3: Ich wüsste nicht, dass moderne Standard CPUs noch auf eine hohe Integer-Leistung getrimmt werden (höchstens spezielle TPUs für INT8)
"in einigen Szenarien" <-- Fehler 4: gleichbedeutend mit "manchmal" und "optimalen Bedingungen"
"jedoch bei deutlich geringerer Leistungsaufnahme." <-- Fehler 5: definiere "deutlich"

Allein von dem einen Satz könnte man ableiten, dass das Ding eine Krücke ist, die mal wieder nur in ein paar cherry-picked Szenarien vor einer Standard x86-CPU liegt.

Davon abgesehen: Bei Standard Integer-Workload erreicht auch keine Xeon Platinum CPU die 205 Watt TDP. Jene wird nur bei maximaler Auslastung der beiden AVX-Vektoreinheiten geknackt, aber dann dreht das Ding halt auch mit ziemlicher Sicherheit großflächige Kreise um so einen Centriq 2400.

Es bleibt dabei: Mir will so recht kein Mehrwert für so eine CPU einfallen. Jetzt mit AMDs EPYC noch weniger. Da gibt es einen 7401P mit 24 potenten und ausgeglichenen Kernen, 48 Threads, Unterstützung für 2 TB RAM verteilt auf acht Kanäle und satte 128 PCIe Lanes für lächerliche 1.100 €. Für Single-Socket-Systeme kaum zu schlagen.

Für die x86-Architektur - ob man sie mag oder nicht - gibt es mit großem Abstand das breiteste Treiber- bzw. Softwareportfolio, Admin- und Entwickler-Knowhow.

 

[Thane]

@Simpson
Mein Fehler. Ich dachte, du beziehst dich rein auf AVX 512.
Ja, die angaben vorher sind mit Erweiterungen zu verstehen.

Trotzdem ist so ein Intel Prozessor in Sachen Rohleistung weit vorne.
Geekbench halte ich auch weiterhin für eine schlechte Basis zum Vergleich der Leistung der verschiedenen Architekturen.

 

[Atent123]

Das glaubst du doch selbst nicht. Die ARM Prozessoren verbrauchen 5W, eine Intel CPU 15W, in den Macbooks eher 20-30W bei ähnlicher Strukturbreite. Sollen aber 6-Mal so effizient sein. Im Leben nicht.
Sollen Sie eine ARM CPU mit vollwertigem Windows/MacOS benchen, mal schauen ob die Benchmarks dann immernoch so toll ausfallen. Bezweifel ich.

Schwachsinn.
Wieso genau sollte das OS da einen so großen Einfluss drauf haben ? Ist halt eine andere Architektur (X86 gegen ARM)
Windows kommt ende des Jahres übrigens als ARM Version mit eingebautem Emulator für X86 code.
"Die ARM Prozessoren verbrauchen 5W"
Schwachsinnige Veralgemeinerung.
Ein Snapdragon 835 verbraucht beispielsweise nur um die 1,5 Watt, ein A11 Bionic um die 2,5 Watt.
Ältere Planar Bulk CPUs verbrauchen hingegen deutlich mehr.
Der Snapdragon 810 hat um die 5 Watt gesogen.

 

[Limit]

@Limit
Die Rohleistung auf was Bezogen? Leistung pro Takt?

Einfach die theoretische Integer-Leistung, also vereinfacht Kernzahl * Pipeline-Breite * Taktfrequenz. Das alles natürlich bei vergleichbarer Verlustleistung. Kein sehr relevantes Maß, aber je einfacher und kleiner der Code ist, desto stärker nähert sich die reale Leistung diesem theoretischem Maximum an.

Das gilt aber auch, wenn Geekbench auf x86 läuft. Man kann Geekbench daher schon als echten Vergleich der Architekturen sehen.

Kann man nicht, insbesondere wenn man eine Smartphone-SoC Architektur mit einer Server-Architektur vergleicht. Geekbench mag ein passabler Test für Smartphones/Tablets sein, er sagt aber nur sehr wenig über die Leistung bei Desktop-/Server-Anwendungen aus, da diese sehr viel größeren und komplexeren Code enthalten und in der Regel auch sehr viel mehr Daten verarbeiten müssen. Da spielen die x86-Architekturen mit ihrer viel größeren Bandbreite ihre Vorteile aus.
Das könnte man mit PKW vs. LKW vergleichen. Wenn du nur einen Koffer transportieren willst (Smartphone-App) ist der PKW genauso schnell (oder hier sogar schneller) als der LKW. Das ist im übertragenen Sinne was Geekbench misst. Wenn du jetzt aber deinen gesamten Hausrat transportieren willst (Server-App), spielt nicht mehr nur die Höchstgeschwindigkeit (Geekbench-Ergebnis) eine Rolle, sondern auch der Laderaum (Bandbreite, Cache, RAM, IO, …) und da verliert der PKW dann deutlich.

Das restliche Ökosystem (Speicheranbindung, Bandbreite), etc. kann damit jedoch nicht bewertet werden.

Und deswegen ist der Benchmark nur für Vergleiche von Smartphone/Tablet-SoCs brauchbar. Für mehr aber auch nicht.

Allerdings ist das auch der Teil, den Qualcomm für den Server-Markt stark angepasst hat. Es wird sich zeigen, welche Performance der Chip am Ende erreicht.

Ich denke nicht, dass diese Server-SoCs bei klassischen Server-Apps mit der x86/Power-Konkurrenz mithalten wird können. Bei den weniger anspruchsvollen Cloud-Server könnten sie allerdings aufgrund ihrer schlankeren Architektur Effizienzvorteile haben. Intel und AMD haben beide eine zeitlang versucht abgespeckte Architekturen dafür anzubieten (Intel mit Xeons auf Atom-Basis und AMD mit ARM-SoCs), aber beide scheinen das nur halbherzig voranzustreiben und bei AMD sieht es fast so aus als hätte man davon Abstand genommen.

 

[smalM]

Das restliche Ökosystem (Speicheranbindung, Bandbreite), etc. kann damit jedoch nicht bewertet werden.

Geekbench hat Memory-Subtests für Copy, Latenz und Übertragungsrate. Fehlt eigentlich nur noch ein Memory-Allocation-Test, aber das ist ja eher ein Test des Betriebsystems.

PS:
Richtige Männer testen ihr System mit SAP HANA. Alles andere ist doch nur Kinderkram.

 

[Phneom]

Schwachsinn.
Wieso genau sollte das OS da einen so großen Einfluss drauf haben ? Ist halt eine andere Architektur (X86 gegen ARM)
Windows kommt ende des Jahres übrigens als ARM Version mit eingebautem Emulator für X86 code.
"Die ARM Prozessoren verbrauchen 5W"
Schwachsinnige Veralgemeinerung.
Ein Snapdragon 835 verbraucht beispielsweise nur um die 1,5 Watt, ein A11 Bionic um die 2,5 Watt.
Ältere Planar Bulk CPUs verbrauchen hingegen deutlich mehr.
Der Snapdragon 810 hat um die 5 Watt gesogen.

Stromverbrauch ist aber auch nicht alles. ARM ist die Pest. Schau dir mal das Smartphone Debakel an und geht weiter mit Mali Treibern. Wenn sie das Treiber Problem irgendwie gelöst haben dann ja aber momentan ist x86 einfach deutlich besser.
Im übrigen denke ich das der x86 Emulator viel Overhead hat und somit das ganze nicht sonderlich schnell sein wird, besser wären ja native Programme. Ich denke da will MS ja auch hin mittels UWP Apps.Unter Linux kompiliert man die Anwendung einfach für die entsprechende Architektur.
Zumindestens für den Desktop ist ARM echt noch nicht tauglich finde ich. Server möglicherweise sofern die Treiber gepflegt werden aber selbst da bin ich skeptisch weil im prinzip lässt man da ja meist auch nen Linux laufen.

 

[Atent123]

Stromverbrauch ist aber auch nicht alles. ARM ist die Pest. Schau dir mal das Smartphone Debakel an und geht weiter mit Mali Treibern. .

Redest du jetzt von der GPU (Mali) oder den ARM CPUs ?
Wozu sollte eine CPU noch mal zusätzlich einen Treiber brauchen (für den Chipsatz vielleicht) ?

 

[cruse]

@Dezor: Windows 10 soll mit dem nächsten Update tatsächlich x86, natürlich würde nicht x64, emulieren können, damit kommen dann W10-Tablets mit Snapdragon 835, wurde letztes Jahr vorgestellt, aktuell prüft Qualcomm auch, ob eigene Patente verletzt werden.

richtig schlechtes deutsch.
falsche kommasetzung, absolut 0 Satzbau, verdrehte aussage
da schreib ich mit 2.0 Promille besser lesbares ...
edit: hab trotz mehrfachen lesens nicht verstanden was du aussagen willst. win10 kommt demnächst mit x86 ? aber nicht mit x64 ? kann x86 emulieren ?
irgendwie vermischt du hier zuviel

Geekbench halte ich auch weiterhin für eine schlechte Basis zum Vergleich der Leistung der verschiedenen Architekturen.

was ist dann die bessere Basis ?

 

[Teralios]

...

Du wirst es nicht glauben: Sie würden auch dann immer noch so gut aus fallen. Zumindest eben genau bei dem einem Benchmark.

x86 ist immer noch CISC, das per Decoder zu Mikro-OPs (RISC) gewandelt wird, ausgeführt wird und am Ende wieder zu CISC wird. So etwas frisst etwas Effizienz.

Zudem sollte man etwas Abstand davon nehmen und denken Windows/MacOS würden sich so massiv von ihren mobilen Pendants unterscheiden. MacOS und iOS bauen auf Darwin auf, das wiederum auf ein BSD-Derviat zurück geht, das wiederum auf ein Unix zurück geht.

Ebenso gibt es ja bereits Windows für ARM-System - Win10 Mobile mal als Stichwort und Microsoft bringt nicht umsonst auch ein »vollwertiges« Windows für die SnapDragons, das eine Emulation für x86-Code beinhaltet. …

Nur weil ARM aus dem "Mobilenbereich" kommt, bedeutet es nicht, dass die CPUs nicht sehr leistungsfähig sein können.

...

Man sollte hier auch etwas mehr unterscheiden. ARM stellt ja sowohl eine ganze Befehlssatz-Architektur da, als auch eine CPU-Architektur.

Ob nun die verwendeten Prozessoren allen Szenarios gerecht werden hängt nicht unbedingt vom Befehlssatz ab (hier ARM gegen x86) sondern davon, wie die CPU darauf zugeschnitten ist.

Cache-Größen, Anbindung des Arbeitsspeichers usw. ist unabhägnig von der gewählten Befehlssatz. ARMv8 kann man auch mit entsprechenden Caches und Speichercontroller ausstatten und für entsprechende Einsatzszenarien wappnen.

...

Richtig, Geekbench umgeht ein paar Aspekte einer CPU. Jedoch sollte einige hier jedoch auch von ihrer eigenen Behauptung Abstand nehmen, dass ARM-CPUs nicht für »richtige« Anwendungen geeignet sein, weil diese Aussage - gelinde gesagt - Bullshit ist.

Wer pauschal behauptet, dass ARM-Architektur wäre für »richtige« Anwendungen ungeeignet, zeigt eigentlich nur, dass diese Person von der Materie keine Ahnung hat und du tust es mit dem folgenden Beitrag selbst sogar, auch wenn die Argumente stimmen, ziehst du jedoch den falschen Schluss wegen Schubladendenken.

…

1. Das ist aber eine sehr starke Vereinfachung und eigentlich sogar falsch. Die Rechenleistung hängt zwar durchaus auch von der "Pipeline" ab, primär für die Rechenleistung verantwortlich sind jedoch eher die ALUs und wie schnell diese entsprechend Arbeiten. Also wie viele Takte sie pro Befehl brauchen.

Pipelines sorgen eher dafür, dass die ALUs effizienter ausgelastet werden. Das eine große "Pipeline" nicht unbedingt zu einer höheren Geschwindigkeit führt hat Intel mit der Pentium 4 Architektur bewiesen. Manchmal sollte man etwas nicht zu sehr vereinfachen.

2. Geekbench allgemein ist - in keinem Fall - kein wirklich aussagekräftiger Test wenn es um Anwendungen geht, egal ob SmartPhone oder Desktop oder eben Server. Geekbench ist höchstens eine interessante Fußnote, was die mögliche Leistungsfähigkeit angeht, da wirklich NUR die Architektur der CPU eine Rolle spielt, ohne Caches und ohne Arbeitsspeicher.

Alles was du danach schreibst ist zwar in seiner Form durchaus richtig, dein Schubladendenken, was die Prozessorarchitekturen angeht verhindert es jedoch, dass man dein Beitrag wirklich ernst nehmen kann.

Leg dieses Schubladendenken von SmartPhones/Tabletts und Server sowie Desktop-PCs ab. Ich habe schon Apps gesehen auf dem iPad und für Android, die stehen üblichen Desktopanwendungen in nichts nach. Siehe Affinity Photo/Designer oder auch Word für iOS und Co.

Ebenso schau dir die Browser und deren JS-JIT-Compiler an …

Man kann auch ARM-Kerne mit Caches und entsprechende Speicherinterfaces ausstatten und somit auch für entsprechende Szenarien wappnen. Hier wird ja etwas ähnliches gemacht. 256KiByte L2-Cache pro Kern entspricht dem, was Intel aktuell auch jedem Kern zur Verfügung stellt. (Ab SkyLake-X sind es 1MiByte). Nur der L3-Cache pro Kern ist 768KiByte kleiner.

Deswegen noch mal: Man sollte nicht die Befehlssatz-Architektur mit der am Ende genutzten Prozessorarchitektur verwechseln. Zu mal ARMv8 ganze 31 Register hat, während x64 gerade mal mit 16 daher dümpelt …

Man kann jedem deiner richtigen Argumente zustimmen, leider kommst du am Ende dennoch auf die falschen Schlüsse, was schade ist, da du - und du bist nicht alleine - zu sehr in der Schublade des Mobile vs. Desktop gefangen bist.

 

[Kenneth Coldy]

Solche Geräte werden wohl mehr oder weniger ausschließlich über Netzwerk kommunizieren und 2 x 1GBE deutet schon auf die zu erwartende Leistungsfähigkeit hin.

Die 2*1GBE sind wohl eher für Out of Band Management. Auf die zu erwartende Leistungsfähigkeit deutet eher die Anzahl der PCIe3-Lanes hin.

 

[itm]

Also Windows 10 (1709 Build 16299.15) läuft auf ARM64. Ob Windows 2016 Server bereits portiert ist, muss ich mal suchen.

Anhang anzeigen 645976

Da Server 2016 immer noch 1607 sprich im Prinzip auf dem Stand des Aniversary Updates ist mag ich das bezweifeln...

 

[Limit]

x86 ist immer noch CISC

Da du es ja anscheinend sehr genau nimmst, möchte ich hier anmerken, dass x86 "nur" ein Befehlssatz ist und da dieser sich in den letzten 30 Jahren nicht verändert hat und damals schon CISC war, ist er es natürlich auch heute noch.

und am Ende wieder zu CISC wird

Das musst du näher erläutern. Nachdem die Micro-Ops ausgeführt wurden setzt die CPU sie wieder zu CISC-Instructionen zusammen?!?

Nur weil ARM aus dem "Mobilenbereich" kommt, bedeutet es nicht, dass die CPUs nicht sehr leistungsfähig sein können.

Man kann für jede halbwegs vernünftige ISA eine leistungsfähige CPU entwickeln und ARM hat das spätestens mit ARMv8 auch im Blick. Aber deine Aussage gilt auch andersherum, nur weil jemand eine gute Mobil-CPU bauen kann, bedeutet das nicht, dass sie auch eine gute Server-CPU bauen können, denn das Anforderungsprofil unterscheidet sich deutlich.

Cache-Größen, Anbindung des Arbeitsspeichers usw. ist unabhägnig von der gewählten Befehlssatz. ARMv8 kann man auch mit entsprechenden Caches und Speichercontroller ausstatten und für entsprechende Einsatzszenarien wappnen.

Wenn es denn so einfach wäre. Cavium und AppliedMicro z.B. bieten mittlerweile schon die 2. bzw. 3. Generation von Server-SoCs auf ARM-Basis an und bereits die erste hatte o.g. Features und trotzdem reicht die Leistung bei typischen Serveranwendungen nicht mal ansatzweise an die der klassischen Server-CPUs heran. Im Cloudserver-Bereich gibt es ein paar Anwendungen, bei denen sie ihre Effizienz ausspielen können, bei den eher klassischen Anwendungen schaffen sie es nicht.

Wer pauschal behauptet, dass ARM-Architektur wäre für »richtige« Anwendungen ungeeignet, zeigt eigentlich nur, dass diese Person von der Materie keine Ahnung hat und du tust es mit dem folgenden Beitrag selbst sogar, auch wenn die Argumente stimmen, ziehst du jedoch den falschen Schluss wegen Schubladendenken.

Es gibt bisher keine ARM-basierte CPU, die für High-Performance Anwendungen im Desktop-/Server-Bereich geeignet wäre und momentan ist, ehrlich gesagt, auch keine in Aussicht. Es gibt eine Nieche für ein schlanke Server-CPU und auf die zielen Cavium, AppliedMicro und auch Qualcomm mit ihren Server-SoCs ab. Eine direkte Konkurrent für die klassischen Server-CPUs stellen diese aber nicht dar.

1. Das ist aber eine sehr starke Vereinfachung und eigentlich sogar falsch. Die Rechenleistung hängt zwar durchaus auch von der "Pipeline" ab, primär für die Rechenleistung verantwortlich sind jedoch eher die ALUs und wie schnell diese entsprechend Arbeiten. Also wie viele Takte sie pro Befehl brauchen.

Die ALUs sind fester Bestandteil der Pipeline und mit Pipeline-Breite bezeichnet man gerade die Anzahl der ALUs. Außerdem schaffen die ALUs heutzutage einfache Ops in der Regel in einem Taktzyklus.

Pipelines sorgen eher dafür, dass die ALUs effizienter ausgelastet werden. Das eine große "Pipeline" nicht unbedingt zu einer höheren Geschwindigkeit führt hat Intel mit der Pentium 4 Architektur bewiesen. Manchmal sollte man etwas nicht zu sehr vereinfachen.

Du redest über die Pipeline-Tiefe, ich über die Pipeline-Breite. Das sind zwei vollkommen orthogonale Parameter. Eine breitere Pipeline verbesser eher die IPC durch höheren ILP während eine längere Pipeline eher gut für höhere Taktraten ist.

da wirklich NUR die Architektur der CPU eine Rolle spielt, ohne Caches und ohne Arbeitsspeicher.

Cache und Speicherinterface sind schon seit vielen Jahren fester Bestandteil der Architektur.

Alles was du danach schreibst ist zwar in seiner Form durchaus richtig, dein Schubladendenken, was die Prozessorarchitekturen angeht verhindert es jedoch, dass man dein Beitrag wirklich ernst nehmen kann.

Naja, zumindest ist das was ich schreibe auch richtig. Das kann man von ein paar Sachen, die du schreibst, nicht behaupten.

Ich habe schon Apps gesehen auf dem iPad und für Android, die stehen üblichen Desktopanwendungen in nichts nach. Siehe Affinity Photo/Designer oder auch Word für iOS und Co.

Zu Affinity Photo kann ich nichts sagen, aber Word ist sicherlich keine Anwendung anhand der man die Leistungsfähigkeit einer CPU beurteilen kann.

Deswegen noch mal: Man sollte nicht die Befehlssatz-Architektur mit der am Ende genutzten Prozessorarchitektur verwechseln.

Tue ich nicht, ich spreche über CPUs, nicht über ISAs.

Zu mal ARMv8 ganze 31 Register hat, während x64 gerade mal mit 16 daher dümpelt …

Die Registerzahl spielt spätestens seit Einführung von register renaming mit Hilfe von Schattenregistern im Pentium Pro keine große Rolle mehr.

Man kann jedem deiner richtigen Argumente zustimmen, leider kommst du am Ende dennoch auf die falschen Schlüsse, was schade ist, da du - und du bist nicht alleine - zu sehr in der Schublade des Mobile vs. Desktop gefangen bist.

Mal eine Frage: Zu welchem Schluss komme ich deiner Meinung nach?

 

[Phneom]

Redest du jetzt von der GPU (Mali) oder den ARM CPUs ?
Wozu sollte eine CPU noch mal zusätzlich einen Treiber brauchen (für den Chipsatz vielleicht) ?

Weil halt zu einem SoC nicht nur die CPU gehört. Bei Desktop Systemen eben auch die Mali GPU.
Wenn dann der Server auf Linux läuft muss der Kernel halt zum SoC passen denke ich mal.

 

[T3mp3sT1187]

@cruse:
Beitrag editiert, vielleicht kannst du es jetzt nachvollziehen...

 

[smalM]

Da du es ja anscheinend sehr genau nimmst, möchte ich hier anmerken, dass x86 "nur" ein Befehlssatz ist und da dieser sich in den letzten 30 Jahren nicht verändert hat

SSE1, 2, 3, viele, AMD64, AES, AVX und was-weiß-ich-noch, es gab Unmengen Änderungen im Befehlssatz.

Das musst du näher erläutern. Nachdem die Micro-Ops ausgeführt wurden setzt die CPU sie wieder zu CISC-Instructionen zusammen?!?

Im Prinzip ja, denn die CPU muß wissen, daß der ursprüngliche CISC-Befehl abgearbeitet wurde, auch wenn er in mehrere µOps zerlegt und diese dann O-o-O abgearbeitet wurden. Dafür ist übrigens die Retirement Unit zuständig.

Es gibt bisher keine ARM-basierte CPU, die für High-Performance Anwendungen im Desktop-/Server-Bereich geeignet wäre und momentan ist, ehrlich gesagt, auch keine in Aussicht.

Das hat keine technischen Gründe, es gibt keinen Markt dafür.

Außerdem schaffen die ALUs heutzutage einfache Ops in der Regel in einem Taktzyklus.

Nein, sie brauchen in der Regel mehrere Takte selbst für einfache Ops. Sie nehmen nur jeden Takt einen neuen Befehl entgegen. Wieviel Takte die Executionunit tatsächlich braucht, sieht man an den Angaben zur Latenz.

Cache und Speicherinterface sind schon seit vielen Jahren fester Bestandteil der Architektur.

Direkt zum Core zählt nur der L1 (und der L2); alles andere ist heutzutage über Interconnects verbunden und damit uncore.

Die Registerzahl spielt spätestens seit Einführung von register renaming mit Hilfe von Schattenregistern im Pentium Pro keine große Rolle mehr.

Register-Renaming dient vornehmlich dazu Stalls in der Execution-Pipeline zu verhindern und damit O-o-O zu unterstützen und Register-Moves eventuell nicht physisch ausführen zu müssen. Es ersetzt in keinster Weise die Vorteile eines großen general-purpose Registersatzes.
Das hat übrigens nichts mit CISC/RISC zu tun, X86-Assembler war immer besch...eiden zu programmieren, MC68K dagegen eine Freude!

 

[Limit]

SSE1, 2, 3, viele, AMD64, AES, AVX und was-weiß-ich-noch, es gab Unmengen Änderungen im Befehlssatz.

Das sind alles nur Erweiterungen des ursprünglichen Befehlssatz (mit Ausnahme von AMD64, da wurden ein paar Legacy-Sachen für Real-Mode gestrichen), ändern aber die altbekannten Befehle nicht, was für einen Wechsel auf eine RISC-Architektur notwendig wäre.

Im Prinzip ja, denn die CPU muß wissen, daß der ursprüngliche CISC-Befehl abgearbeitet wurde, auch wenn er in mehrere µOps zerlegt und diese dann O-o-O abgearbeitet wurden. Dafür ist übrigens die Retirement Unit zuständig.

Ich war mir nicht mehr ganz sicher, also habe ich ein wenig gegoogelt. Laut diesem Paper speichert die Retirement Unit nur µOps, keine CISC-Befehle.

Das hat keine technischen Gründe, es gibt keinen Markt dafür.

Gäbe es ARM-CPUs, die im Server-Bereich eine vergleichbare/bessere Effizienz als x86/Power/SPARC hätte, gäbe es auch eine Markt. Im Gegensatz zum Desktop-Segment spielt der Befehlssatz hier keine ganz so große Rolle.

Nein, sie brauchen in der Regel mehrere Takte selbst für einfache Ops. Sie nehmen nur jeden Takt einen neuen Befehl entgegen. Wieviel Takte die Executionunit tatsächlich braucht, sieht man an den Angaben zur Latenz.

Hier hast du Recht. Wobei für die ursprüngliche Frage weniger die Latenz, sondern eher der Durchsatz entscheidend ist.

Direkt zum Core zählt nur der L1 (und der L2); alles andere ist heutzutage über Interconnects verbunden und damit uncore.

Das mag sein, allerdings würde ich auch den Uncore zur Architektur zählen, denn er hat mittlerweile erheblichen Einfluss auf die Performance der CPU und ist ja auch direkt mit auf dem Die.

Register-Renaming dient vornehmlich dazu Stalls in der Execution-Pipeline zu verhindern und damit O-o-O zu unterstützen und Register-Moves eventuell nicht physisch ausführen zu müssen. Es ersetzt in keinster Weise die Vorteile eines großen general-purpose Registersatzes.
Das hat übrigens nichts mit CISC/RISC zu tun, X86-Assembler war immer besch...eiden zu programmieren, MC68K dagegen eine Freude!

Mehr Register sind sicherlich angenehmer, vor allem, wenn man den Assembler-Code selbst schreibt und bei x86 mit seinen nur acht Registern gab es durchaus schon mal einen Notstand. Mit den 16 bei x86-64 kann man aber in der Regel gut auskommen ohne dass es Leistung kostet.