News AMDs Zukunft: Arctic Islands und Zen als GPU- und CPU-Hoffnung für 2016

Mit der Errungenschaft könnten Entwickler genauso miserabel programmieren wie gewohnt, die Hardware selbst würde die Leistung so oder so bringen ^^
Naja, da würde ich mich nicht zu früh freuen. Sowas kann nur funktionieren, wenn tatsächlich viel unabhängiger Code in einem Thread läuft, der an sich schon höhere IPC-Werte zulässt als die CPU. Wenn da jetzt ewig lange Dependency Chains im Code sind, geht das gar nicht.

Und Spiele sind nun wahrlich keine IPC-Monster. AC3 liefert auf meinem X6 auf jedem Kern zwischen 0.2 und 0.3 Befehle pro Takt, würde also selbst auf nem aktuellen Intel weit unter 1 bleiben - wenn da irgendwas parallel laufen könnte, würde es das wohl auch tun.

aber z.B. Webbrowser nutzen gereade 1 Kern
Und Mozilla hat eine Multicore-fähige Engine in Entwicklung und wird sie nicht für den Desktop bringen. Dabei hätte gerade Firefox sowas mal nötig.
 
Hier ist übrigens ein schöner Beitrag über VISC
http://www.heise.de/newsticker/meldung/VISC-Ein-virtueller-Single-Core-Prozessor-2435023.html
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.

Also das einzige was man über das Thema erwähnen kann. AMD unterstützt das Projekt von Soft Machines und hat selbst damit experementiert. (Bulldozer hätte sowas bekommen sollen).

Jim Keller selbst lobt die Register in ARM Design und aktuell arbeitet ein Team bei AMD an K12 und Zen. Viel sagt das aber nicht aus
 
Zuletzt bearbeitet:
Wenn man das so liest, dann erscheint die Fusion Folie von der vorherigen Seite gar nicht mehr so unwahrscheinlich.
Es kann also passieren das Zen so ganz anders aussieht als wir es jetzt erwarten.
 
Wenn du bei deinen Hobby Recherchen etwas interessantes findest, teile es uns doch bitte mit. Auch, wenn du gelegentlich etwas überenthusiastisch bist, kannst du immer sehr gut interessante technische Informationen verständlich aufbereitet wiedergeben. Etwa über FD-SoI, aus dem ja leider zumindest für AMD nichts geworden ist.

Ich würde dir ja beinahe ans Herz legen, einen Zen Thread aufzumachen, in dem bisherige Spekulationen und die kargen Infos sowie mögliche Technologie zusammengetragen und diskutiert werden können und in dem man nebenbei auch noch Neuerungen zu GCN sowie den neuem Cat CPUs abdecken kann (von Nolan und generell AM1 hört man ja leider nichts mehr :( ).
Aber die Verwaltung dieses Threads wäre wohl etwas zu viel verlangt :D
 
Techniker Freak

Was ja VISC wirklich interessant macht, die Technik arbeitet ähnlich wie VLIW. Wäre ja nicht so, als ob AMD da keine Erfahrung hätte.

Transmeta hat damals ein X86 Code in ein VLIW Code umgewandelt und dann von den Threads abgearbeitet und als 1 Thread behandelt.
Hier wird aber von 4 Cores gesprochen, die ähnliches machen sollen.
Im Text wird ja eh schön beschrieben. 1 Core 50-60 % und jeder weitere Core dann immer weniger sodass ab 4 Cores ein weitere kaum noch was bringt.
Aber für einen Core mit 1 virtuellen Core (also HTT) würde man so quasi eine IPC Steigerung schaffen. Man hätte SMT wir Intel, aber völlig anders integriert.
Fraglich ist nur, ob das nur über ein Modul geht (klingt zu mindestens so), oder auch Modul übergreifen funktioniert. Es ist eben sehr wenig bekannt.

Problem dürfte bisher niedrige Taktrate sein und die darf man in einem Design nun mal nicht vergessen.


[F]L4SH
Naja, man muss bei Begriffen wie CMT schon aufpassen, weil auch diese Abkürzung kann bei anderen Hersteller was anders bedeuten.
Aber VISC würde bei AMD Wahrscheinlich unter CSMT fallen (Clustered Simultaneous Multi-Thread).
Was ein Thread angeht. Da gibt es ja so einige Englische Foren wo man schön mitlesen kann.


Hier eine PDF, falls wer lesen möchte
http://softmachines.com/wp-content/uploads/2014/10/MPR-11303.pdf

Was ich in einem Komentar auf die schnelle gelesen habe, soll das Fron-End sehr groß sein. Die Cores selbst aber eher klein und schlank.

oft Machines has created an intermediate software layer that can translate from any
standard instruction set into threadable VISC instructions,

he company has spent seven years and $125 million to develop and validate its technology

vestors include AMD, GlobalFoundries, and Samsung as well as government investment funds from Abu Dhabi (Mubdala), Russia (Rusnano and RVC), and Saudi Arab
ia (KACST and Taqnia).

Compared with a high IPC processor such as Haswell, the front end is of similar complexity, but the scheduler in each physical core is much simpler, as it manages only a few function units (versus eight in Haswell). The data cache also has fewer ports and can cycle faster. Because the execution resources of both cores can apply to a single thread, however, even a two core VISC processor can deliver total ALU operations or memory operations per cycle that match or exceed those of Haswell.

VISC relies on a unique internal instruction set to do its magic, but true to its name, Soft Machines provides a conversion layer that converts from a standard instruction set to VISC

Dazu muss man sagen, dass in der Einleitung bereits von der Rede war, dass man damals vieles versucht hat im Compiler umzusetzten. Intel ist hier groß als Beispiel zu nennen.

a single VISC processor can emulate a traditional multicore design

because a VISC core can mix instructions from multiple threadlets

From a software viewpoint, the heavy thread runs on a single virtual core that comprises more than one physical core, while the light thread runs on a virtual core that uses only a portion of a physical core.

Es wird auch beschrieben wie zwei Aufgaben, davon eine schwer und eine andere Leicht auf einen Dual Core aufgeteilt wird. So werden zwei Threads geschaffen, wobei einer für die schwere Aufgabe da ist und der andere für die Leichte. Der Thread für die Schwere Aufgabe teilt aber einige Ressourcen des anderen Cores, wobei der Rest des anderen Core dann für die "Einfache" Aufgabe verfügbar wäre.

its fontend hardware will recognize which threads need more performance and allocate the virtual core resources appropriately. The operating system need not know the number of physical cores in the processor to assign threads or balance the load

Jetzt aber zum Problem des Design :
Because it uses a pipeline with only 10 stages (including some extra stages for VISC scheduling), the CPU cannot match the high clock speeds of leading edge x86 and ARM processor.
We estimate the chip runs at several hundred megahert

It estimates the second core improves performance by an average of 50 - 60% across a variety of benchmarks



Sonst liest sich das schön. Denn soviel ich verstanden habe, kann das Frontend selbst Threads erstellen und diese dann je nach Bedarf Cores zuteilen und abarbeiten. So kann ein solcher VISC Prozessor mehrere Threads aufeinmal bearbeitn wie ein Multi-Threads Prozessor, oder wenn eine schwere Aufgabe kommt, kann das Frontend mehreren Cores dann einen größeren Thread zuordnen.
Der Compiler selbst muss nicht angepasst werden und diesem ist auch ein VISC Modul "verborgen".

Also das Problem ist wohl die sehr knappe Pipeline von 10 Stages ^^ Davon sind aber auch enige für VISC scheduling inkludiert.

Also so glaube ich eher, dass man solche Chips eher in low - power Design sehen könnte. Wo ein solcher Prozessor mit einer hohen IPC die selbe Performance schafft, wie andere Prozessoren mit mehr Takt. Je nach Bedarf X86 oder ARM Code abarbeiten kann. Da hätte der niedrigere Takt keinen Nachteil.

Aber wer weiß, vllt konnte AMD Jaguar mit VISC mit SMT kombinieren ^^ Jaguar selbst hat auch nur "15" stages und läuft immerhin mit 2 GHZ.
 
Zuletzt bearbeitet:
Das ist ja der Punkt, sie haben in diesem Bereich bereits Erfahrung und diese könnte man auch kombinieren. Mir persönlich kam dabei in den Sinn das AMD 8 normale Kerne mit 8 "halben" Kernen (2 Module a 4 Kerne) kombinieren könnte. Diese könnten entweder als zusätzlicher Thread einem vollen Kern zugeordnet werden oder aber auch zu je 2 Blöcken kombiniert eine immense Rechenleistung bieten.
Da könnten dann je nach Lastszenario 4 - 16 Threads gefahren werden, sofern die Software mitmacht.
 
Techniker Freak

Das meinte ich auch mit CMST und 4, 8, 16 Threads. Die Software oder der Compiler selbst muss da gar nichts machen oder angepasst werden. Im Endeffekt erledigt das alles das Front-End.
Eigentlich passt das alles zu HSA. Denn man stelle sich vor dass das Front-End auch noch den GPU Shader Threads zuteilen könnte.

Wie in einem Beispiel beschrieben. Hast du zum Beispiel ein schwere Aufgabe und eine leichte Aufgabe, dann generiert das Front-End zwei Threads die jeweils für die Aufagben zugeschnitten sind und jeweils die Ressourecen zuweist. Also die Thread für die schwere Aufgabe bekommt 1 und einen halben Core und der Rest macht den leichten Thread. So arbeiten sich beide Cores zu.

Also so habe ich das zu mindestens verstanden. Der Compiler selbst sieht nicht wieviele Cores das System hat. Das Front End Fetcht und teilt dann zu.

Aber am ehesten könnte ich mir 1 Core und erweiterte Register vorstellen die nach dem Prinzip arbeiten. Weil ein weitere Core bringt so ca 60-50% höhere IPC oder kann als eigener Thread arbeiten. Umso weniger Arbeite, desto höher könnte man eventuell Takten weil da die Komplexität geringer ist.
 
Zuletzt bearbeitet:
Können die erweiterten Register noch genutzt werden wenn man die Kerne zusammen schaltet oder fallen die virtuellen Kerne dann weg?

Ich würde die Variante 8 halben und 8 ganzen Kernen vorziehen. Sie dürfte insgesamt performanter sein und evtl. kann man mit den halben Kernen im Officebetrieb etwas Energie einsparen wenn die dann arbeiten.

Insgesamt zeichnet sich da auf jeden Fall etwas technisch sehr interessantes für das nächste Jahr ab und ich bin wahnsinnig gespannt. Die Performance muss dann natürlich auch stimmen aber davon gehen wir einfach mal aus. Alles andere wäre zu pessimistisch. :D
 
Techniker Freak

Naja, Prozessoren werden heutzutage in "meet in the Middle" Entwurf entwickelt. Neue Design sind auch dann meist Full Costum Design die dann später in Costum Design verwendet werden können.

Ich für mein Teil hoffe dass man den Desktop und Notebooks in den Fokus gestellt hat. Dann können wir für den Desktop Markt schon mal etwas erwarten. Bei Bulldozer war ja der Entwurf auf Server gerichtet. Aber mal sehen. Wir wissen ja noch weniger über K12.

Btw gibt ja noch andere interessante Themen zu X86 und ARM.

Der Ansatz ist zu VISC schon sehr ähnlich, denn dort wird auch die Instruction in ein Buffer geladen und dann in die VISC-Instruction übersetzt ect.

http://www.tomshardware.de/arm-x86-befehlssatz-isaiah-ii,news-250881.html
 
Zuletzt bearbeitet:
Der Ansatz von VIA, sowohl x86 als auch ARM Decoder zu verbauen, regt in mir aber den Gedanken an, dass das das Gegenteil von Energieeffizienz ist. Der Vorteil von RISC-Architekturen, der sich gehalten hat, ist ja, dass wesentlich weniger Die-Fläche und Energie auf die Decoder verwendet werden muss, als bei x86. AMD wollte das bei Bulldozer/Piledriver beheben, indem dort ein Decoder zwei Integer-Kerne versorgt, aber mit Steamroller haben sie das Konzept ja wieder zurückgenommen, weil die Leistungseinbußen dadurch scheinbar zu groß waren. Die (vorerst gestorbene) Post-RISC-Architektur Itanium/EPIC hatte VLIW so abgewandelt, dass nicht die Decoder des Prozessors den Code optimieren, sondern der Compiler zur Compile-Zeit - auch gerade damit da nicht unnötig Die-Fläche und Stromverbrauch aufs CPU-Frontend entfällt.

Die Idee, sowas das Frontend bei der Ausführungszeit erledigen zu lassen, und somit mehr Die-Fläche und Strom ins Frontend zu investieren, schreckt mich ehrlich gesagt eher ab - sowohl bei Doppeldecodern von Via als auch bei dem Ansatz von AMD.
 
Zuletzt bearbeitet:
Zurück
Oben