AMD K12 -Spekulation

miriquidi schrieb:

Das Modulkonzept drängt die einzelnen Baugruppen eines CPU-Kerns (Caches, Dekoder, Recheneinheiten, ...) auf dem Die weiter auseinander

Zum Vergrößern anklicken....

Nein, sie liegen enger beieinander. Das was sonst auf zwei Kerne verteilt wäre liegt nun unmittelbar nebeneinander (Decoder, Integer Cluster, FPU, etc). Latenzen sind maximal aus Funktionsgründen gestiegen, zB FMA statt FMUL/FADD. Oder ein grösserer L2 Cache. Das hat aber wenig mit CMT zu tun. Man erkauft sich den zweiten Thread pro Modul nicht mit reduzierter singlethreaded Performance.

Die Ausgangslage vor der Idee "wir machen Module" waren doch einzelne Kerne. AMD sagte, ein Modul erreiche 90% der Leistung von zwei hypothetischen Einzelkern-Bulldozern bei einem Bruchteil der Fläche (irgendeine Zahl deutlich kleiner als 90%). Bedeutet also, die Flächeneffizienz (Rechenleistung pro Quadratmillimeter) ist damit höher, aber die absolute Rechenleistung eines einzelnen Threads ist kleiner als bei zwei getrennten, kompletten Kernen. Ohne Modulkonzept wäre ein Kaveri vielleicht 5% schneller und 20% größer, keine Ahnung. Module bedeuten also eine gute Methode, um CPUs für die Mittelklasse preisgünstig herzustellen, aber eine schlechte, um im High-End Spitzenleistungen zu erreichen. Bei einem Verkaufspreis von über 300 $ wären 20% größere Dies sicherlich kaum gewinnschmälernd, aber einige Prozent weniger Leistung verhindern komplett die Realisierung von hohen Verkaufspreisen.

Wenn man parallelisierbare Workloads hat, dann ist die absolute Rechenleistung eines einzelnen Kerns irrelevant, es kommt dann nur auf kumulierte Rechenleistung pro Fläche und pro Watt an. Aber wenn man eben nicht gut parallelisierbare Workloads hat, scheitert das Konzept. Typischerweise wird bei einem Spiel aus einem Hauptthread einiges ausgelagert, um weitere Kerne zu beschäftigen und den ersten zu entlasten, aber die Last ist nicht gleichmäßig beliebig teilbar wie z.B. bei Videoencoding, sondern es gibt weiterhin einen Thread, der limitiert, und eine endliche Menge an ausgelagerten Threads, die nur eine begrenzte Menge an weiteren Kernen auslasten können. Wie man ja bei den meisten Spielen sieht, ist ein Dual-Core immer besser als ein SingleCore, inzwischen auch ein Quadcore besser als ein DualCore, aber über 4 Kerne wird es schlagartig schwierig, ein Spiel zu finden, was noch skaliert (selbst ein Spiel mit 30 Threads kann mit den 29 schwächeren kaum die Kerne 1-3 so füllen wie der 1. Thread den Kern 0). Deswegen ist z.B. auch ein hoch getakteter i5 besser für Spieler als ein niedriger getakteter Xeon oder Haswell-E, die auf dem Papier eigentlich mehr Gesamtrechenleistung haben, aber in die gleiche Falle laufen wie der Bulldozer mit 8 Kernen, weil sie ihre Kapazität nicht auslasten können mangels genug Threads.

Und diese gut parallelisierbaren Workloads laufen zwar auf 8 schwächeren Kernen effizienter als auf vier starken, aber auf 512 oder 2048 noch schwächeren Kernen laufen sie im Zweifel noch viel effizienter. AMD sollte beim APU- oder HSA-Konzept doch eigentlich alle Workloads abdecken, eine GPU für parallelisierbare Tasks und eine CPU für nicht-parallelisierbare. Aber mit BD in der APU ist das eine APU, die zwei Werkzeuge für dieselbe Aufgabe anbietet und keins für die andere. Wie ein Schweizer Taschenmesser mit zwei Korkenziehern aber ohne Messerklinge.

AMD sollte sich bei der Entwicklung einer neuen Architektur (oder besser gesagt zweien) also sinnvollerweise darauf konzentrieren, eine CPU zu entwerfen, die eine GPU optimal komplementiert.


Excavator soll ja eine leichte Abkehr vom Modulkonzept bedeuten, also mehr Einheiten, die nicht gemeinsam genutzt sind. Wir werden bei Carrizo hoffentlich auswerten können, wie das die Rechenleistung pro Thread hebt und wieviel mehr Fläche das frißt (wird aber wahrscheinlich durch andere Änderungen verschleiert und schwer feststellbar sein, wie üblich).

gruffi schrieb:

Nein, sie liegen enger beieinander. Das was sonst auf zwei Kerne verteilt wäre liegt nun unmittelbar nebeneinander (Decoder, Integer Cluster, FPU, etc). Latenzen sind maximal aus Funktionsgründen gestiegen, zB FMA statt FMUL/FADD. Oder ein grösserer L2 Cache. Das hat aber wenig mit CMT zu tun. Man erkauft sich den zweiten Thread pro Modul nicht mit reduzierter singlethreaded Performance.

Zum Vergrößern anklicken....

Du hast es noch nicht ganz verstanden. In nachfolgender Abb. [1] ist ein Modul in sehr grober Aufteilung abgebildet. Zwischen Kern 0 und L2-Cache liegt z.B. noch Kern 1.
Läge der L2-Cache direkt neben Kern 0, sänke die Signallatenz für das Eintreffen benötigter Daten. Ebenso ist die FPU durch die Anwesenheit von zwei Integerkernen weiter als im Einkernfall nötig von der Dekoder-Einheit entfernt.
Die Informationen, die ein Kern zum Rechnen benötigt, sind durch das Modulkonzept über eine größeren Teil der Siliziumfläche verstreut. Das senkt die Single-Thread-Perfomance.
[1] : http://i1-news.softpedia-static.com...-at-CeBIT-Most-Probably-Bulldozer-Chips-3.jpg

Das Problem taucht übrigens auch beim Bau von Exascale-Superrechnern auf. Man kann nicht einfach 10 Rechenzentren mit 1/10tel der Leistung nebeneinander stellen, weil durch die langen Signalleitungen die Latenz im System schnell anwächst. Ein anderes Beispiel ist das Bestreben, den Arbeitsspeicher möglichst nah an die CPU / GPU heran zu bekommen. Kurze Wegen ermöglichen geringere Latenzen.

OBrian schrieb:

Excavator soll ja eine leichte Abkehr vom Modulkonzept bedeuten, also mehr Einheiten, die nicht gemeinsam genutzt sind. Wir werden bei Carrizo hoffentlich auswerten können, wie das die Rechenleistung pro Thread hebt und wieviel mehr Fläche das frißt (wird aber wahrscheinlich durch andere Änderungen verschleiert und schwer feststellbar sein, wie üblich).

Zum Vergrößern anklicken....

Das war aber doch Steamroller mit den eigenständigen Decodern, oder nicht?
Grandiose Neuigkeiten erwarte ich für Excavator nicht, glaub kaum, dass man in eine sterbende Architektur noch großartig was investiert. Das wird ein neues Steamrollerstepping mit ein paar Bugs weniger sein, fertig.
Größte Neuerungen wirds höchstens für den HSA-Teil geben, den wird man später ja noch weiterverwenden können.

BoMbY schrieb:

Ich denke schon, dass Intel deutlich mehr könnte, wenn die einen Grund dafür hätten. Die Verbesserungen in den letzten vier Jahren waren marginal (seit den ersten i5/i7-Prozessoren.) Von Moore's law entfernen wir uns mittlerweile deutlich.

Zum Vergrößern anklicken....

In Zeiten von Mehrkernprozessoren gilt das Mooresche Gesetz allein aber auch nur noch bedingt - oder in Verbindung mit dem Amdahlschen Gesetz.

Zwei Leute - zwei Meinungen, so ist das halt.
Ich denke eben, dass Intel nicht deutlich mehr kann. Sondern eher, dass sie schon deutlich Mehrleistung haben als es den Otto Normalverbraucher interessiert.
Diese Mehrleistung ist bereits Kaufbar und muss nicht erst entwickelt werden, wie es im Falle der FX nötig wäre.
Daher ist es aus Sicht von AMD völlig legitim zu sagen: Es macht aktuell keinen Sinn in diesen Markt zu investieren - Wer mehr Leistung braucht der soll zu Intel greifen.

Da gleichermaßen, aktuell und geschichtlich bedingt, einschlägige Hardware-Redaktionen ausschließlich Intel-Prozessoren empfehlen. Zudem viele User ebenso der Meinung sind - Brauchst du Leistung, dann kaufe Intel.
Wenn also niemand in diesem Umfeld AMD empfiehlt, soll AMD in Dieses investieren

Da scheint mir die Idee mit AMD K12 schon mehr Sinnvoll. Einen High-End-Prozessor auf x86- ARM-Kernen basierend von einer GPU flankiert. So etwas könnte evtl. alle Märkte abdecken, sogar den Leistungs-Markt jenseits der aktuellen FX-Prozessoren.

Das wird auf jeden Fall spannend, schielt man einmal in Richtung Apple A8X 64-Bit ARM-SoC...
Gruß Lehmann

Bezüglich AMDs ARM64- und Zen-X86-Cores würde ich das so formulieren: aus ARM-Sicht dürften AMDs ARM64-Cores Highend-Cores werden (evt. bis 5Watt/Core), weil diese weit über den ARM-Cores liegen dürften, wie sie in den Smartphones genutzt werden. Im x86-Segment wären aber Cores, die bis maximal 5Watt aufnehmen, eher Lowpower. Insgesamt denke ich, dass AMD nur noch das Leistungsspektrum von 1-10Watt/core anstrebt.

OBrian schrieb:

Die Ausgangslage vor der Idee "wir machen Module" waren doch einzelne Kerne. AMD sagte, ein Modul erreiche 90% der Leistung von zwei hypothetischen Einzelkern-Bulldozern bei einem Bruchteil der Fläche (irgendeine Zahl deutlich kleiner als 90%). Bedeutet also, die Flächeneffizienz (Rechenleistung pro Quadratmillimeter) ist damit höher, aber die absolute Rechenleistung eines einzelnen Threads ist kleiner als bei zwei getrennten, kompletten Kernen. Ohne Modulkonzept wäre ein Kaveri vielleicht 5% schneller und 20% größer, keine Ahnung. Module bedeuten also eine gute Methode, um CPUs für die Mittelklasse preisgünstig herzustellen, aber eine schlechte, um im High-End Spitzenleistungen zu erreichen.

Zum Vergrößern anklicken....

Ach menno, wieder diese uralte Diskussion? Das haben wir doch schon etliche male durchgekaut. Die Performance eines einzelnen Threads ist nicht geringer. Bei Intel wurde die Performance eines einzelnen Threads trotz der Implementierung von Hyperthreading doch auch nicht geringer. Richtig ist maximal, die Performance pro Thread ist bei voller Auslastung geringer. Das ist aber nicht von Bedeutung, wenn die Flächeneffizienz so gut ist, dass man entsprechend mehr Threads auf der gleichen Fläche unterbringen kann. Mal beispielhaft:

separate Kerne mit jeweils einem Thread:

Performance eines einzelnen Threads = 100%
Performance von zwei Threads mit voller Auslastung = 200%
Performance pro Thread mit voller Auslastung = 200% / 2 = 100%
Fläche pro Thread = 10 mm²
Performance bei 60 mm² mit voller Auslastung = 60 mm² / 10 mm² * 100% = 600%

Module mit je zwei Threads:

Performance eines einzelnen Threads = 100%
Performance von zwei Threads mit voller Auslastung = 180%
Performance pro Thread mit voller Auslastung = 180% / 2 = 90%
Fläche pro zwei Threads = 15 mm²
Performance bei 60 mm² mit voller Auslastung = 60 mm² / 15 mm² * 180% = 720%

Die Performance eines einzelnen Threads auf einem Modul ist nicht geringer, weil dem Thread dann auch alle Einheiten zur Verfügung stehen. Vorausgesetzt natürlich, dass keine Einheit weniger leistungsfähig ausgelegt ist als auf den separaten Kernen. Erst wenn zwei Threads ins Spiel kommen, müssen Einheiten auf dem Modul geteilt werden, so dass nicht die gleiche Skalierung wie bei separaten Kernen erreicht werden kann.

"Wenn man parallelisierbare Workloads hat, dann ist die absolute Rechenleistung eines einzelnen Kerns irrelevant, es kommt dann nur auf kumulierte Rechenleistung pro Fläche und pro Watt an. Aber wenn man eben nicht gut parallelisierbare Workloads hat, scheitert das Konzept. Typischerweise wird bei einem Spiel aus einem Hauptthread einiges ausgelagert, um weitere Kerne zu beschäftigen und den ersten zu entlasten, aber die Last ist nicht gleichmäßig beliebig teilbar wie z.B. bei Videoencoding, sondern es gibt weiterhin einen Thread, der limitiert, und eine endliche Menge an ausgelagerten Threads, die nur eine begrenzte Menge an weiteren Kernen auslasten können. Wie man ja bei den meisten Spielen sieht, ist ein Dual-Core immer besser als ein SingleCore, inzwischen auch ein Quadcore besser als ein DualCore, aber über 4 Kerne wird es schlagartig schwierig, ein Spiel zu finden, was noch skaliert (selbst ein Spiel mit 30 Threads kann mit den 29 schwächeren kaum die Kerne 1-3 so füllen wie der 1. Thread den Kern 0)."
Ist ja schön und gut. Mantle zeigt aber sehr gut, dass High-End CPUs für Spiele gar nicht mehr notwendig sind. Da gibt's kaum noch FPS Zuwächse oberhalb aktueller 2-3 GHz CPUs, egal ob von AMD oder Intel. Ressourcenfressende Aufgaben darüber hinaus, wie KI, lassen sich für gewöhnlich gut parallelisieren.

"Deswegen ist z.B. auch ein hoch getakteter i5 besser für Spieler als ein niedriger getakteter Xeon oder Haswell-E, die auf dem Papier eigentlich mehr Gesamtrechenleistung haben, aber in die gleiche Falle laufen wie der Bulldozer mit 8 Kernen, weil sie ihre Kapazität nicht auslasten können mangels genug Threads."
Fragt sich nur wie es ausschaut, wenn du noch ein paar Sachen nebenbei machst, wie zB Streaming oder Multiboxing.

miriquidi schrieb:

Du hast es noch nicht ganz verstanden. In nachfolgender Abb. [1] ist ein Modul in sehr grober Aufteilung abgebildet. Zwischen Kern 0 und L2-Cache liegt z.B. noch Kern 1.

Zum Vergrößern anklicken....

Nein. Du hast nur nicht verstanden, dass das keine Kerne sind. Das sind lediglich Integer Units bzw Integer Cluster. Und die hängen sowieso nicht direkt am L2. Oder glaubst du Daten im L2 werden direkt von den ALUs verarbeitet? Dir ist schon bewusst, wie eine Prozessorpipeline funktioniert? Glaubst du wirklich, die Ingenieure sind so dumm, die Integer Cluster nicht direkt neben dem L2 zu platzieren, wenn es wichtig wäre? Schau dir die einzelnen Pipelinestufen an, welche Stufe auf welche folgt, und vergleiche das mit der physischen Anordnung auf dem Die. Nur so viel sei verraten, Decoder/Dispatcher hängen gleichermassen an Integer Unit 0 und 1. Übrigens, die Integer Units in K8 und K10 lagen auch nicht direkt neben dem L2.

"Ebenso ist die FPU durch die Anwesenheit von zwei Integerkernen weiter als im Einkernfall nötig von der Dekoder-Einheit entfernt."
Selbst wenn das von Bedeutung wäre, hätte das nichts mit CMT zu tun, da man schliesslich nur ein FPU hat. Die kann man in der gleichen Weise anordnen, egal ob ein oder zwei Integer Units. Da könnten wir maximal über schlechtes Design diskutieren.

"Die Informationen, die ein Kern zum Rechnen benötigt, sind durch das Modulkonzept über eine größeren Teil der Siliziumfläche verstreut. Das senkt die Single-Thread-Perfomance."
Weder das eine, noch das andere. Stichwort FO4.

"Das Problem taucht übrigens auch beim Bau von Exascale-Superrechnern auf. Man kann nicht einfach 10 Rechenzentren mit 1/10tel der Leistung nebeneinander stellen, weil durch die langen Signalleitungen die Latenz im System schnell anwächst. Ein anderes Beispiel ist das Bestreben, den Arbeitsspeicher möglichst nah an die CPU / GPU heran zu bekommen. Kurze Wegen ermöglichen geringere Latenzen."
Ja, aber das sind ganz andere Grössenordnungen als bei einer Prozessorpipeline auf dem selben Stück Silizium. Erst wenn Signallaufzeiten so gross werden, dass du zusätzliche Takte brauchst, macht es einen Unterschied. Das kann man anhand eines Die Shots aber nun wirklich nicht beurteilen. Zumal Latenzen auch versteckt werden können während der Verarbeitung.

Man kann sicher auf quantitativer Ebene darüber diskutieren, ob die längeren Signallaufzeiten ein signifikanter Grund für die eher mäßige Single-Thread Leistung eines Bulldozer-Moduls sind. Auf jeden Fall bedeuten längere Wege größere Latenzen, da kommt man physikalisch nicht dran vorbei. Wenn die Infos aus den Caches erst noch durch einen für zwei Kerne gebauten Dekoder müssen, ist das sicher nicht weiter förderlich. Bulldozer ist auch nicht gerade mit schnellen Caches versehen.
Meines Erachtens gibt man mit einem Modul von vornherein etwas Single-Thread Performance auf, aber kommen wir lieber zum K12 bzw. Zen zurück. Wir haben jetzt beide unsere Sichtweisen dargelegt.

miriquidi schrieb:

Man kann sicher auf quantitativer Ebene darüber diskutieren, ob die längeren Signallaufzeiten ein signifikanter Grund für die eher mäßige Single-Thread Leistung eines Bulldozer-Moduls sind. Auf jeden Fall bedeuten längere Wege größere Latenzen, da kommt man physikalisch nicht dran vorbei.

Zum Vergrößern anklicken....

Wenn diese Latenzen innerhalb der selben Anzahl von Zyklen liegen, macht das aber wie gesagt keinen Unterschied. Nach den gröbsten machbaren Fehlerbeseitigungen mit Steamroller liegt man mittlerweile wieder auf Augenhöhe mit K10 pro Takt. Und das bei teilweise sogar weniger Einheiten (nur 2x ALU + 2x AGLU statt 3x ALU/AGU). Und etwas mehr Takt gibt es obendrein. Singlethreaded gibt's da praktisch keine Nachteile mehr gegenüber K10, selbst bei Wald- und Wiesencode. Bei entsprechender Software aber mitunter deutliche Vorteile.

miriquidi schrieb:

Wenn die Infos aus den Caches erst noch durch einen für zwei Kerne gebauten Dekoder müssen, ist das sicher nicht weiter förderlich.

Zum Vergrößern anklicken....

Dem Decoder ist das egal. Der Dispatcher schickt die dekodierten Ops an die Ausführungseinheiten. Und da macht es keinen Unterschied, ob vorher (K10) zwei Wege möglich waren (Integer, FPU) oder nun 3 Wege möglich sind (Integer 0, Integer 1, FPU). Eine entsprechende Selektion hast du so oder so. Die für 3 Wege sicherlich aufwändiger ausfällt, aber keine Latenz kosten sollte.

"Bulldozer ist auch nicht gerade mit schnellen Caches versehen."
Schnell sind sie schon, aber halt nur beim Lesen, nicht beim Schreiben. Und das hat wohl eher mit WT zu tun. CMT lässt sich natürlich auch mit WB-Caches implementieren. Insgesamt hat Cache wenig mit CMT ansich zu tun. Man kann hier maximal über getrennte L1D Caches diskutieren.

"Meines Erachtens gibt man mit einem Modul von vornherein etwas Single-Thread Performance auf"
Es gibt nach wie vor trotzdem keine klaren konzeptionellen Gründe, die dafür sprechen würden. Signallaufzeiten sind eher Balancing und Optimierung. Wenn das die singlethreaded Performance drücken würde, dann könnte ich auch behaupten, ein Design mit 4-fach Decoder liefert weniger singlethreaded Performance als ein Design mit 2-fach Decoder. Schliesslich ist ersterer grösser und die Distanz zu den Ausführungseinheiten ebenso. Faktisch ist aber ein Design mit 4-fach Decoder schneller, zumindest pro Takt. Generell könnte man dann behaupten, dass jeder Kern mit irgendeiner Multithreading-Technologie, also auch Intels Core, etwas singlthreaded Performance aufgibt. Weil dann immer an diversen Stellen in der Pipeline Threadselektierung stattfindet. Das mag in der Theorie nicht falsch sein. In der Praxis aber kaum relevant. Performance- und Effizienzvorteile solcher Multithreading-Technologien haben da eine ganz andere Gewichtung. Ebenso die eigentlichen Funktionseinheiten.

Zumindest sind die aktuellen Notebook-Kaveris in vielen Anwendungen wieder auf dem Single-Thread Niveau, das AMD vor 4 Jahren mit dem Regor-Kern mal erreicht hatte. Der Sprung von 45 auf 28 nm Fertigung mag dann die Effizienzsteigerung mit erklären.

Laut SA soll ein grosses Unternehmen für Serversoftware auf ARM portieren. Der gesamte Artikel ist leider hinter einer Paywall. Es wird darüber spekuliert, ob es Microsoft sein könnte. Wäre auf jeden Fall sehr gut für K12.

Microsoft Windows Azure kann seit neustem Teile der Serverbasis auch auf Linux laufen lassen womit auch (AMD-)ARM-Server möglich wären

VISC: Ein virtueller Single-Core-Prozessor

Ein kleines Startup ist aus seiner geheimen Phase herausgetreten, mit einem neuen Prozessordesign, das x86- und ARM-Code verarbeiten kann und das mehrere Kerne an einem Thread arbeiten lässt.

[...]

AMD ist übrigens an Soft Machines beteiligt, genauso wie der bei Intel gescheiterte frühere Mikroprozessorchef Albert Yu, wie Samsung und Globalfoundries-Besitzer Mubadala.

Zum Vergrößern anklicken....

Ob AMD da wohl was bei ZEN und K12 übernehmen wird?

Da musste ich auch gleich dran denken, zumal ja damals vor dem Start von Bulldozer über ein eben solches "revers-Hyperthreading" spekuliert worden war. Allerdings würde ich sagen muss das Startup erst noch zeigen, und das ist ziemlich entscheidend, ob das Prinzip auch mit gewöhnlichem bisher existierendem Code funktioniert. Wenn Programme erst extra dafür neukompiliert werden müssten gäbe es bei vielen Programmen wieder das Problem, dass über längere Zeit kein Nutzen eines solchen Features sichtbar würde.

Mit ARM dürfte es da keine Probleme geben. Das braucht man lediglich lizenzieren und kann dann entsprechende Decoder nutzen. Bei x86 schaut es etwas anders aus. Das lässt sich nicht so einfach lizenzieren. Wenn man sich die Investoren von Soft Machines aber mal anschaut, scheinbar kein unüberwindbares Problem:

AMD
Mubadala
Glofo
Samsung

Kennen wir doch alle irgendwo her.

Ich bin mir auch sicher, die gezeigten Leistungen wird man auch in anderen Anwendungen sehen. Sicherlich laufen Architekturen mal besser oder schlechter. Aber dass eine Architektur in bestimmten Anwendungen überhaupt nicht auf Touren kommt, wäre sehr ungewöhnlich.

Wo ich allerdings noch skeptisch bin, ist die Effizienz. Sowohl was Fläche als auch Energie betrifft. Das ist letztendlich der entscheidende Punkt für die Akzeptanz von VISC. Wäre auf jeden Fall interessant, mal wieder einen Prozessor im System zu haben, der mit lediglich ein paar Hundert MHz auskommt.


Übrigens, auch Bloomberg berichtet jetzt darüber, dass Microsoft an ARM Serversoftware arbeitet.

BoMbY schrieb:

Ob AMD da wohl was bei ZEN und K12 übernehmen wird?

Zum Vergrößern anklicken....

Und ich dachte der MR² CPU-Mark entstand aus Marketing zwecke: http://heiko.amberlin.eu/MR2CPU-Mark.html


Bei der CPU Wertung "Singlethread" erreicht mein System bis zu +30% Gesamtprozessorauslastung (agiert dynamisch).
Um so erstaunlicher ist die Mutlithread Skalierung von 1:7,96

VISC ist sicherlich ein Feature, welches vor allem für die ARM-basierenden Microserver mit Seamicro-Fabric hochinteressant ist.

WindHund schrieb:

Bei der CPU Wertung "Singlethread" erreicht mein System bis zu +30% Gesamtprozessorauslastung (agiert dynamisch).
Um so erstaunlicher ist die Mutlithread Skalierung von 1:7,96

Zum Vergrößern anklicken....

Nicht wirklich. Selbst Intels Hyperthreading erreicht hier eine hohe Skalierung, wenn nur die CPU Logik zum Tragen kommt. Man sieht auch recht gut, dass Bulldozer von der reinen CPU Logik sehr leistungsfähig ist. Übertrifft sogar Haswell locker pro Takt. In der Praxis kommt allerdings mehr als nur die CPU Logik zum Tragen, wie zB Cache. Und da skaliert dein FX halt "nur" mit 1:6,7. Was immer noch relativ gut ist und weitaus besser als Intels Hyperthreading.

gruffi schrieb:

Nicht wirklich. Selbst Intels Hyperthreading erreicht hier eine hohe Skalierung, wenn nur die CPU Logik zum Tragen kommt. Man sieht auch recht gut, dass Bulldozer von der reinen CPU Logik sehr leistungsfähig ist. Übertrifft sogar Haswell locker pro Takt. In der Praxis kommt allerdings mehr als nur die CPU Logik zum Tragen, wie zB Cache. Und da skaliert dein FX halt "nur" mit 1:6,7. Was immer noch relativ gut ist und weitaus besser als Intels Hyperthreading.

Zum Vergrößern anklicken....

Da kann ich dir voll und ganz zustimmen, bei den Teilbereichen skaliert es etwas geringer, aber theoretisch sind eben nur 1:33 möglich.
Es sollte nicht schwer sein für AMD, um an eine VISC Lizenz ran zu kommen, zumal SVM low level integriert wurde. (IOMMU)

BoMbY schrieb:

Ob AMD da wohl was bei ZEN und K12 übernehmen wird?

Zum Vergrößern anklicken....

Garantiert nicht, dafür ist es noch zu früh.
Das Design wird außerdem sehr wahrscheinlich seine Pferdefüße haben, z.B: schlechte Taktskalierung (die beste IPC nützt nichts, wenn das Teil nur mit 1,0 Ghz läuft) und eventuell auch nen schlechten Stromverbrauch, das ganze Umwandeln, Zerstückeln und wieder Zusammensetzen des Codes gibts sicherlich nicht umsonst.

Preisfrage ist da, wie simpel die verwendeten Rechenkerne ausfallen können, ob man also ggü. modernen Kernen auch etwas Komplexität sparen könnte.

Taktfrequenzen um die 1 Ghz wären jetzt nicht soo schlecht, insbesondere mit ner IPC um die 2, das wäre recht passabel im Smartfonbereich, aber wenn der Stromverbrauch dafür nicht passt, wars wieder nix.

@Opteron
Das ganze baut auf Virtuellen Kernen auf, sollte also auch auf vorhandenen Architekturen übertragbar sein.
Nur der Translater für x86 auf ARM oder umgekehrt wird Hardwareseitig gelöst.

The VISC architecture is based on the concept of “virtual cores” and “virtual hardware threads.” This new approach enables dynamic allocation and sharing of resources across cores. Microprocessors based on CISC and RISC architectures make use of “physical cores” and “software threads,” an approach that has been technologically and economically hamstrung by transistor utilization, frequency and power-scaling limitations. The VISC architecture achieves 3-4 times more instructions per cycle (IPC), resulting in 2-4 times higher performance per watt on single- and multi-threaded applications. Moreover, VISC uses a light-weight “virtual software layer” that makes VISC architecture applicable to existing as well as new software ecosystems.

Zum Vergrößern anklicken....

http://www.softmachines.com/soft-ma...through-revives-performance-per-watt-scaling/

MfG

Was die mit nem virtuellem Core meinen ist nicht so wirklich klar. Software braucht auf alle Fälle Hardware, die die Befehle ausführt. Wenn der Ansatz also auf Software basiert, ist es gut, da man keine neue Hardware oder größere Anpassungen braucht, aber dafür steigt die CPU-Zeit fürs Datenzerhäckseln etc. pp an. Umsonst gibts das schließlich auch nicht.

Ob das am Ende wirklich "light-weight" ist, oder man nicht doch nen kompletten Core dafür abstellen sollte, wird sich noch zeigen müssen.

Aus IPC-/Leistungssicht wär selbst das natürlich immer noch toll, aber Strom wird man damit keinen sparen können.

@Opteron
Klar, ein wenig hoffe ich auch, dass es Architektur übergreifend greift.
Einer meiner Argumente sind z.B. die Zeilen:

Soft Machines hopes to license the VISC technology to other CPU-design companies, which could add it to
their existing CPU cores. Because its fundamental benefit is better IPC, VISC could aid a range of applications from
smartphones to servers. The company has applied for more than 80 patents on its technology.

Zum Vergrößern anklicken....

http://www.softmachines.com/wp-content/uploads/2014/10/MPR-11303.pdf

S|A schreibt auch, dass es nicht ARM, AMD oder Intel spezifiziert ist, es läuft damit ebenso.

gruffi schrieb:

Dir nützt ein x86 Prozessor in einem ARM System mit ARM Software aber trotzdem nix und umgekehrt. Genauso wenig kauft sich ein Desktop Nutzer ein Serversystem und umgekehrt.

Zum Vergrößern anklicken....

Du hast mich falsch verstanden, unabhängig von der Software, ich meinte nur das die Architektur von K12 & ZEN ähnlich ausfallen sollte, also viele Gemeinsamkeiten, (Pipeline, Cache, FPU, Taktraten) könnte bei beiden Designs ähnlich sein, nur das man bei K12 auf ARM Decoder und bei ZEN auf x86 Decoder setzt, also eine Architektur für beide Gebiete.

gruffi schrieb:

Bei AMD gibt's nicht weniger Fortschritte, eher mehr.

Zum Vergrößern anklicken....

Bezogen auf den x86 Markt sehe ich trotzdem kaum Fortschritte die sich im Vergleich zu Intel durchsetzen können, was hat AMD was Intel nicht hat? Wo ist AMDs Marktanteil mit HSA? Die neuen Befehlssätze die der K10 nicht hat, die hat man wieder nur von Intel kopiert...Seit 6 Jahren gibt es bei AMD keine Fortschritte im x86 Bereich, die Leistung pro takt von Steamroller ist nicht höher als ein Phenom II von 01/2009.

gruffi schrieb:

Intel wärmt doch nur ständig alte Sachen neu auf und garniert das alle 2-3 Jahre mit neuen Fertigungen. Wo ist da der echte Fortschritt?

Zum Vergrößern anklicken....

Bei Intel skaliert die Architektur bis jetzt ganz gut nach oben.

Core2 > Nehalem +30% > Sandy Bridge +15% > Haswell +10% > Skylake...

Und so kann man immer wieder neue Server & Desktop Modelle mit mehr Leistung verkaufen.

AMDs CMT ist der größte reinfall von AMDs Geschichte gewesen, schwache Singlethread Performance, schlechte Performance in Games, gegen ein Server Modell von Intel mit 8C/16T braucht AMD mehr als 20 Kerne um Balken zeigen zu können, dabei sind die Prozessoren richtig ineffizient weil man keine gescheite Fertigung hat.

Du hast Ivy Bridge vergessen. Und ob deine Prozentangaben auch wirklich dem Durchschnitt an Zugewinn über wenigstens eine Vielzahl der Modelle entsprechen?