AMDs "Excavator" - 4. Modul Generation Spekulation

Complicated

Grand Admiral Special
Mitglied seit
08.10.2010
Beiträge
4.949
Renomée
441
file.php


Nachdem ich nun erstmalig Performance Gerüchte gelesen habe dachte ich ich eröffne mal den Thread hier. Aus dem Prozessorgeflüster bei heise:
http://www.heise.de/ct/artikel/Prozessorgefluester-1929893.html

Von AMDs sagenumwobenem Excavator weiß man bislang nur, dass er eine erhebliche Änderung der Mikroarchitektur gegenüber der Bulldozer-Linie aufweisen soll. Irgendeine chinesische Website hatte bereits im Mai tolle Performancewerte für ihn veröffentlicht: 400 SPECint_rate2006 und 700 SPECfp_rate2006. Danach wäre er vier- bis siebenmal so schnell wie ein FX 8150. Man las dort auch von solchen fantastischen Dingen wie Speculative Multithreading und „WaveScalar“. Ersteres ist etwas, mit dem Intel schon vor vielen Jahren experimentiert hat und Letzteres eine interessante Datenfluss-Technik mit einem speziellen Instruktionssatz, die Computerwissenschaftler Steven Swanson, heute Professor an der Universität von San Diego, vor nunmehr zehn Jahren auf einem Mikroprozessorsymposium vorgestellt hat. Der kann sich zwar auch keinen Reim aus den chinesischen Veröffentlichungen machen, aber dennoch, vielleicht überrascht uns ja AMD tatsächlich mit etwas ganz Neuem.
Hier der chinesische Link auf den Bezug genommen wird, der Benches eines angeblichen auf 4 GHz getakteten Engeneering Samples enthält. Dieses ES soll eine APU mit 4 Modulen sein und GCN 2.0 Compute Units gefertigt in 28nm:
http://diybbs.zol.com.cn/11/11_106489.html

Kommt nun tatsächlich "Spekulativ Multithreading"?

Infos zu "Wave Scalar"
http://cseweb.ucsd.edu/users/swanson/papers/TOCSWaveScalarArch.pdf
We present WaveScalar as a scalable alternative to conventional designs. WaveScalar is a dataflow instruction set and execution model designed for scalable, low-complexity/high-performance processors. Unlike previous dataflow machines, WaveScalar can efficiently provide the sequential semantics imperative languages require. To allow programmers to easily express parallelism, WaveScalar supports pthread-style, coarse-grain multithreading and dataflow-style, fine-grain threading. In addition, it permits blending the two styles within an application or even a single function.

To execute WaveScalar programs, we have designed a scalable, tile-based processor architecture called the WaveCache. As a program executes, the WaveCache maps the program’s instructions onto its array of processing elements (PEs). The instructions remain at their processing elements for many invocations, and as the working set of instructions changes, the WaveCache removes unused instructions and maps new instructions in their place. The instructions communicate directly with one-another over a scalable, hierarchical on-chip interconnect, obviating the need for long wires and broadcast
communication.

This paper presents the WaveScalar instruction set and evaluates a simulated implementation based on current technology. For single-threaded applications, the
WaveCache achieves performance on par with conventional processors, but in less area. For coarse-grain threaded applications the WaveCache achieves nearly linear speedup with up to 64 threads and can sustain 7-14 multiply-accumulates per cycle on fine-grain
threaded versions of well-known kernels. Finally, we apply both styles of threading to equake from spec2000 and speed it up by 9x compared to the serial version
Es scheint dass diese Technologie sogar im Stande wäre Single Threads zu parelellisieren. Ich hab das PDF allerdings erstmal nur überflogen.

Weitere Technologien die mit Excavator kommen sollen laut der chinesischen Quelle:
Thread Synchronisation Unit (TSU)
Thread Context Table (TCT)
Thread Memory History (TMH)
 
Zuletzt bearbeitet:
Vielen Dank für das pdf zur WaveScalar Architektur. Ist eigentlich ne sehr einfache Umsetzung nach der Instruktionen erst dann gültig sind wenn die Daten dafür bereit stehen. Im Optimalfall sind dass dann verdammt viele, die parallel abgearbeitet werden können. Im Fall von starken Abhängigkeiten landet man eben wieder ungefähr bei der Güte eines normalen OoO Prozessors mit nur einem Kern zur Abarbeitung. Allerdings braucht man dann ja kein OoO mehr, weil die Instruktionen eh schon so kommen, dass sie direkt zu bearbeiten sind.
Klingt auf alle Fälle umsetzbar, auch wenn dann das Debugging wohl kompliziert wird. Wäre wirklich interessant wenn AMD es schafft das für x86 umzusetzen.
 
"AMD are on track to catch up on high performance cores"
- Jim Keller, Corporate Vice President and Chief Architect of AMD's Microprocessor Cores

http://www.rage3d.com/articles/hardware/amd_worldcast/

Vielleicht ist ja was dran.
Aber so früh Leaks von nem echten ES? Excavator steht auf keiner Roadmap, kommt wohl also nicht vor 2015.
Ein paar Kaveri Benchmarks wären glaubhafter.

Bei 28nm und 4 Modulen kann man ja davon ausgehen, dass doch nochmal reine CPUs erscheinen (wenn es das ES wirklich gibt)
 
Das ES wie es oben beschrieben ist enthält GCN 2.0 Cores. Sollte AMD das mit Wave Scalar hin bekommen für Excavator, wären CPUs mit GPU Cores die massiv parallel arbeiten erst die richtigen Beschleuniger.
 
@Complicated
Schau dir mal die Uralt PDF an: http://eyetap.org/papers/docs/procicpr2004.pdf ;)

In our system, an additional five GPUs provided 4.5×more throughput than the CPU implementation.
The speedup is primarily achieved because each graphics card accesses its own memory, allowing parallel,
contentionfree memory access, increasing the overall memory bandwidth of the system
 
@Windhund
Danke für den Link, doch der beschäftigt sich mit generellem GPU Computing und ist aus 2004. Wave Scalar soll ja typischen x86 Programmcode, der üblicherweise auf CPU läuft, paralellisieren können. Sozusagen als Vorstufe und dann eben Streaming Einheiten (GPU, FPU oder auch Xeon Phi) zur Abarbeitung nutzen wo möglich.
 
Ist eigentlich ne sehr einfache Umsetzung nach der Instruktionen erst dann gültig sind wenn die Daten dafür bereit stehen. Im Optimalfall sind dass dann verdammt viele, die parallel abgearbeitet werden können.
Bräuchte man dann nicht einen deutlich größeren Instruction Cache? Falls ja, dann können wir ja darauf mal achten, ob sowas in der Richtung leakt.
 
Bräuchte man dann nicht einen deutlich größeren Instruction Cache? Falls ja, dann können wir ja darauf mal achten, ob sowas in der Richtung leakt.
Ne, man brauch überhaupt keinen I-Cache:
The WaveCache has no central processing unit. Instead it consists of a sea of processing nodes in a substrate that effectively replaces the central processor and instruction cache of a conventional system. The WaveCache loads instructions from memory and assigns them to processing elements for execution. The instructions remain at their processing elements for a large number, potentially millions, of invocations.

Klingt alles in allem eher GPU-artig, insbesondere auch der "
sea of processing nodes". Vielleicht GCN3 oder 4? Für die CPU sehe ich da keine Ansatzpunkte. Die präsentieren da wie besagt ne komplett neue ISA, die nicht mal dem sonst *überall* üblichen Von-Neuman-Schema folgt. Sowas über in ein bestehende CPU-Design zu integrieren: Neee.

Das hier klingt auch ziemlich nach GPU:

At its heart, the von Neumann model describes execution as a linear, centralized process. A single program counter guides execution and there is always exactly one instruction that, according to the model, should execute next. This is both a strength and a weakness. On one hand, it makes control transfer easy, tightly bounds the amount of state the processor must maintain, and provides a simple set of memory semantics. History has also demonstrated that constructing processors based on the model is feasible (and extremely profitable!). On the other hand, the model expresses no parallelism. While the performance of its processors has improved exponentially for over three decades, continued scalability is uncertain.

Frag mich jetzt nur, wie man sowas in ner APU integieren könnte, aber wird schon irgendwie gehen ^^
 
Der angesprochene Wave-Cache ist im Prinzip ja auch ein Instruktions-Cache, er funktioniert dann eben aber etwas anders. Aufgrund dessen das viele Instruktionen die noch nicht abgearbeitet werden können vorgehalten werden müssten und gleichzeitig auch mehrere Ausführungsstufen mit dran hängen, müsste dieser Cache aber in der Tat recht groß sein. Die Umsetzung in obigem Dokument kommt aber mit 8000 Einträgen scheinbar schon sehr gut aus. Kann auch sein, dass der L2 das wieder etwas abfängt...

Die Ähnlichkeit zu GPUs ist schon recht deutlich sichtbar, der wesentliche Unterschied bleibt aber, dass eine GPU die seriellen Workloads nur unzureichend abarbeiten könnte. Dass die Architektur mit spec2000 getestet wurde zeigt ja deutlich worauf man abzielt. Natürlich könnte in einem derartigen Design auch versuchen GPU-Instruktionen mit x86-Instruktionen in einem Programm zu mischen. Was an der Backend alles dran hängt ist erst mal zweitrangig. Das wäre vermutlich für die Compiler aber zu kompliziert.
Einfacher wäre da natürlich auch wieder eine neue ISA, aber so lange man rein auf x86 Kernen bleibt, sehe ich keinen Grund warum man diese über Bord werfen sollte.

Die Steuerung des Datenflows ist auch recht interessant. Für diesen bräuchte man dann einige Zusatzinstruktionen, was dazu führt, dass die Programme eben auch extra für diesen kompiliert werden müssen. Dafür sind spekulative Berechnungen dann auch recht einfach umsetzbar. In dem dort vorgestellten Design gibt es auch zwei Speichermodelle siehe "6.2.1 Mixing ordered and unordered memory".
6.1 Unordered memory
As described, WaveScalar’s only mechanism for accessing memory is the wave-ordered memory interface. The
interface is necessary for executing conventional programs, but it can only express limited parallelism (i.e.,
by using ripple numbers)
Ich denke mal damit ließe sich dann auch normaler Code noch ausführen, der entsprechende Instruktionen nicht besitzt.
Ich kam bisher aber auch nicht dazu alles komplett zu lesen und hab grad wenig Zeit dazu, kann also sein, dass ich gerade auch noch ein bisschen was durcheinander geworfen habe.^^
 
Zuletzt bearbeitet:
Hm, die Frage ist natürlich wie effizient so etwas sein kann, denn man stelle sich vor man hat ein Programm das 2 Pfade hat die am Anfang mit case oder if entschieden werden.
Da wird dann nach Adam Riese schnell mal 50% der Instruktionen "umsonst" durchgeführt.
Was dann zwangsläufig auf den Stromverbrauch geht.
Das ist quasi schlimmer als wenn der Prozessor die Pipeline leeren muss.
 
[...]

Bei 28nm und 4 Modulen kann man ja davon ausgehen, dass doch nochmal reine CPUs erscheinen (wenn es das ES wirklich gibt)
Da spricht so ziemlich alles dagegen. Die Architektur und ihre Nähe zur GPU, eine neue Plattform, die sicher auch APU-Fähig sein muss und vieles mehr. Die Zeiten der echten CPU sind einfach vorbei. Das wird bei Intels Skylake-E ebenfalls so sein.
 
Also das scheint aber irgendwie ganz anders zu funktionieren als übliche Rechner. Statt ein Programm abzuarbeiten, indem man den ersten Schritt ausrechnet und das Ergebnis dann wieder oben in die Pipeline stopft, um weiterzukommen (wobei man währenddessen bestenfalls an einem ganz anderen Programm weiterarbeiten kann, damit die lange Pipeline nicht leerläuft) bearbeitet man hier das ganze Programm an allen Stellen gleichzeitig, wo man irgendwas ausrechnen kann, und führt die Teilergebnisse dann baumartig zusammen. Also so eine Art massives Multithreading am Anfang mit einem Singlethread-Ende.

Es kann Timingprobleme geben, d.h. ein Zweig ist schneller fertig als der andere, aber das wäre immer noch schneller als serielle Abarbeitung (da bei Ende des längeren Zweiges der kürzere bereits komplett fertig ist, statt daß er erst begonnen werden muß). Und Auslastungsprobleme gibt es nicht, weil die Ausführungsblöcke nicht in bestimmter Reihenfolge, sondern wild durcheinander belegt werden können. Sobald einer frei ist mit einer Teilaufgabe, bekommt er eine andere.

Aber wie will man nicht nur die Instruktionen, sondern auch die fertigen Daten eines Blocks zwischenspeichern, bis sie ein anderer Block weiterverarbeiten kann? Was in einer normalen CPU die Register übernehmen (superschnell, aber nur wenig Platz), müßte bei dem enorm größeren Platzbedarf unbedingt mindestens wahnsinnig schneller Cache übernehmen. Das kann man nicht auf den RAM abwälzen (zu lahmarschig, viel zu wenig Bandbreite), es müßten aber trotzdem sicher einige MB sein. Es muß schon ein gemeinsamer Cache sein, da ja die fertigen Teilergebnisse von adneren Blocke weiterverarbeitet werden, d.h. lokale Speicherung am Ausführungsblock ist sinnlos. Die Instruktionen werden ja laut PDF auch nicht da gespeichert, sondern "gemappt", d.h. man sagt der im Gesamtcache liegenden Instruktion, auf welchem Block sie laufen soll.

Gleichzeitig muß man sich überlegen, ob man dieses neuartige Konzept immer einsetzen kann. Wenn das nur bei spezieller Software geht, die zu "Lebzeiten" der ersten Hardwaregeneration wie üblich kaum zur Verfügung steht, kann man nicht einfach die halbe Diefläche für Cache verballern, den man sonst nicht wirklich nutzen kann.

Das muß also irgendwie anders gehen als ich Kleindoofi mir das denke. *noahnung*
 
Frag mich jetzt nur, wie man sowas in ner APU integieren könnte, aber wird schon irgendwie gehen ^^
Einfacher wäre da natürlich auch wieder eine neue ISA, aber so lange man rein auf x86 Kernen bleibt, sehe ich keinen Grund warum man diese über Bord werfen sollte.
Nun HSA ist ja genau dafür konzipiert worden unterschiedliche ISA unter einen Hut zu bringen. Auch mit Hilfe des HSA Finalizers, der immer wieder als AMD Exklusiv bezeichnet wurde und so etwas wie einen Compiler in Echtzeit darstellt. Ja ich weiss an diesem Begriff hatten wir schon mal eine Diskussion über "virtuelle Compiler", vielleicht passt programmierbarer Compiler besser? HSAIL dürfte jederzeit durch Software/Treiber Updates für neue Hardware mit eigener ISA aktualisiert werden können. Wenn ich es mir recht überlege vieleicht sogar auf UEFI/BIOS Ebene.

AMD hat immer bei HSA von "TCU" und "LCU" gesprochen:
TCU = Throughput Computing Unit
LCU = Latency Throughput Unit
Hier nochmal zur Erinnerung das Whitepaper wo dies beschrieben ist.
http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf
2.5. HSA Intermediate Language (HSAIL)
HSA exposes the parallel nature of TCUs through the HSA Intermediate Language (HSAIL). HSAIL is translated onto the underlying hardware’s ISA (instruction set architecture). While HSA TCUs are often embedded in powerful graphics engines, the HSAIL language is focused purely on compute and does not expose graphics-specific instructions. The underlying hardware executes the translated ISA without awareness of HSAIL.
[...]
The finalizer translates HSAIL into the underlying hardware ISA at runtime.
[...]
The finalizer also enforces HSA Virtual Machine semantics as part of the translation to ISA. Because of that, the underlying hardware architecture does not have to strictly
adhere to the HSA Virtual Machine. The HSA Virtual Machine can also be implemented on an LCU, by having the finalizer convert HSAIL to the LCU’s ISA.

Each HSAIL program has its own set of registers. There are four kinds of registers: single-bit control registers, and 32-bit, 64-bit and 128-bit registers that can be treated as integer or as floating point. HSAIL instructions have a simple 3-address RISC-like format. All arithmetic operations are either register-to-register or constant-to-register.

The finalizer converts this load-store type architecture to the underlying processor ISA. The HSA load-store model is not imposed on the underlying processor.
Also wenn man das mal wirken lässt, könnte es sein dass AMD mit dieser Methodik die Fesselung an x86 gewaltig aufgeweicht hat. Nicht nur kann man beliebige ISA hinzufügen und Hardware verwenden die keine Altlasten benötigt, man könnte im Prinzip auch x86 durch ARM ISA ersetzen oder durch was völlig neues, ohne dass Programmierer viel an der Software ändern müssten, vermute ich zumindest.

Sollte ARM seine kommende 64-Bit Architektur voll HSA Kompatibel machen und AMD diese verbauen, sollte ja auch x86 Code dort funktionieren obwohl nichts davon in Hardware verbaut wurde. Dank HSAIL sollte x86 in ARM ISA übersetzt werden können. Stellt sich nur die Frage nach der Performance.

Nochmal zur Auffrischung:
http://developer.amd.com/community/blog/hsa-a-boon-for-opencl-and-heterogeneous-compute-in-general/

HSA-OCL-v1.21-graphic-e1341960719282.png


However, there are many developers who do not currently use OpenCL. These developers are developing applications in Java, Fortran, OpenMP, C++ AMP, managed languages etc. and they want the performance benefits of heterogeneous compute, but without having to incorporate an additional programing paradigm. The HSA runtime and HSAIL2 provide the basis for this. Any compiler that understands data parallel programing patterns can leverage the HSA run-time directly for data management on the heterogeneous platform, and can use HSAIL for the representation of data parallel kernels that will execute on the GPU. This is illustrated in the diagram above, taken from Phil Rogers’ keynote at AFDS.

Just like other languages, on HSA platforms the OpenCL runtime will leverage the underlying HSA runtime, and HSAIL as the intermediate language for kernels. Indeed, the HSA runtime and HSAIL could be used as the basis for implementing an HSA platform agnostic open-source OpenCL runtime.

HSA is the future of heterogeneous compute opening up many new opportunities, I’m excited.
[...]
HSAIL is a cross platform virtual ISA that can be efficiently converted to any given ISA using a finalizer.

Die Kombination ist, denke ich, nicht weit her geholt.
 
Snafuh :

Vielleicht ist ja was dran.
Aber so früh Leaks von nem echten ES? Excavator steht auf keiner Roadmap, kommt wohl also nicht vor 2015.

Also bei so umfangreichen Änderungen ist das schon nicht ausgeschlossen.
Es wird auch vom Ur-BD sehr früh ES gegeben haben.

Ein paar Kaveri Benchmarks wären glaubhafter.

Bei 28nm und 4 Modulen kann man ja davon ausgehen, dass doch nochmal reine CPUs erscheinen (wenn es das ES wirklich gibt)

Selbst dieses ES (so denn existent) ist ja schon eine APU, also reine CPUs sind damit Schnee von gestern.
Das ist ja auch ok, wenn die Leistung (des CPU-Teils) stimmt und davon ist schwer auszugehen.
Es muss einfach ein Upgrade Pfad für alle FX 8350 Käufer geben, die werden sich sicher keinen Kaveri kaufen.
Sollten aber die 4 Module im kolportierten Excavator ES so stimmen und entsprechend Druck machen, dann stört es auch nicht, wenn es eine APU sei. ;)
Mit den Geschwindigkeitsangaben des ES wär ich aber vorsichtig, klingt einfach zu gut um wahr zu sein. ???
 
@_tex:
Der angesprochene Wave-Cache ist im Prinzip ja auch ein Instruktions-Cache,
Schreib bitte nicht Wave-Cache sonder nehm noch "Architektur" dazu, klingt sonst irgendwie blöde ^^ Würde vorschlagen das Ganze einfach mit WCA abzukürzen.


@OBrian:
Die sehen da pro Cluster 1 MB L2 vor ... insgesamt rechnen sie mit 16MB, ist schon etwas.
Wenn man das ganze per HMC integriert hätte man auch ganz dick schnelles Riesen-RAM (8 GB @1024 bits sollte ja wohl genügen ^^).
Das wäre schon ne sehr hübsche Kombination ...

@Complicated:
Ja ne, sorry, das meinte ich nicht. GPU integration ist absolut kein Problem, da geb ich Dir absolut recht. Ist auch mit der Grund, wieso ich das dort sehe. Dort ist die ISA sowieso abstrahiert, also kann man die Ur-ISA problemlos austauschen.
Wo ich Probleme sehe ist bei ner APU, und da meine ich v.a. Steamroller mit HSA, sprich den kohärenten CPU+GPU Speicher. Da müsste man dann den CPU-von-Neumann-Zugriff und den WaveCache-Zugriff irgendwie unter einen Hut bringen. Stell ich mir wg. der beiden unterschiedlichen Ansätze schwierig vor, aber vielleicht gehts ja einfacher, als man denkt.
 
Auch das lässt sich im Whitepaper nachlesen ;)
http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf
3. Memory Model

[...]
3.2. Virtual Address Space
Not all memory regions need to be accessible by all compute units.
[...]
3.2.1. Virtual Memory Regions
HSA abstracts memory into the following virtual memory regions. All regions support atomic and unaligned accesses.
•Global: accessible by all work-items and work-groups in all LCUs and TCUs. Global memory embodies the main advantage of the HSA unified memory model: it provides data sharing between LCUs and TCUs.
•Group: accessible to all work-items in a work-group.
•Private: accessible to a single work-item.
•Kernarg: read-only memory used to pass arguments into a compute kernel.
•Readonly: global read-only memory.
•Spill: used for load and store register spills. This segment provides hints to the finalizer to allow it to generate better code.
•Arg: read-write memory used to pass arguments into and out of functions.
Mehr Details im Paper, da ich nicht zu viel hier Quoten will. Es scheint, dass dies alles schon bedacht wurde und die Grundlagen dafür gelegt sind.
Gemeinsamer Zugriff ist möglich wenn nötig und nicht zwingend.
 
Hm, die Frage ist natürlich wie effizient so etwas sein kann, denn man stelle sich vor man hat ein Programm das 2 Pfade hat die am Anfang mit case oder if entschieden werden.
Da wird dann nach Adam Riese schnell mal 50% der Instruktionen "umsonst" durchgeführt.
Was dann zwangsläufig auf den Stromverbrauch geht.
Da habe ich ehrlich gesagt auch Bedenken. Sowas kann sich eigentlich nur bei kurzen Codesequenzen lohnen. Dennoch muss man bedenken, dass damit quasi die Branch Logik und Einheiten wegfallen bzw deutlich reduziert werden. Das spart dann wiederum Fläche und Energie.


Ansonsten, interessantes Thema. Ich denke trotzdem nicht, dass wir eine solche Implementierung in absehbarer Zeit sehen werden. Zumindest was die CPU betrifft. Dafür weicht das Konzept zu sehr von herkömmlichen OoO Designs ab. Ausserdem würde ich erst mal ein paar aktuellere Vergleiche sehen. Der Alpha EV7 ist nun nicht gerade aktuell. Seitdem hat sich doch einiges getan.
 
Ja über CPU muss man glaube ich wirklich nicht diskutieren.

Aber GPU... da fällt mir auch die Sache wieder ein:
Und ohne zu viel verraten zu wollen: Wir haben Mittel und Wege gefunden, um den Wirkungsgrad unserer zukünftigen Chipgenerationen pro Watt zu verdoppeln. Denn egal, ob in Embedded Chips, Tablets, PC-Grafikkarten oder Servern - wer den höchsten Wirkungsgrad pro Watt bietet, hat gewonnen. Einem Spieler mag es egal sein, wie viel Strom seine Grafikarte verbraucht, doch wie sieht es mit der Geräuschkulisse aus? Wenn die Karte gleichzeitig flüsterleise ist, sorgt das für ein noch besseres Spielerlebnis.
http://www.pcgameshardware.de/AMD-R...mit-Dr-John-Gustafson-von-AMD-Teil-2-1065308/
 
Mehr Details im Paper, da ich nicht zu viel hier Quoten will. Es scheint, dass dies alles schon bedacht wurde und die Grundlagen dafür gelegt sind.
Gemeinsamer Zugriff ist möglich wenn nötig und nicht zwingend.

Befriedigt mich noch nicht ganz, das liest sich alles ganz nett, aber die WCA verwaltet den Speicher grundlegend anders. Hab das WCA Paper noch nicht genau gelesen, aber ein HSA-Paper beruhigt mich da nicht.

Könnte in etwa so wie ein Bericht zur Familienpolitik in D sein. Die kann man auch ganz super spezifizieren, aber ganz woanders, z.B: in Hinterindien ist das nicht viel wert, da dort fundamental ganz andere Vorraussetzungen herrschen. So stell ich mir das im Moment vor, aber wie besagt, hab das Speicherkapitel noch nicht im Detail gelesen, nur überflogen, aber die Tatsache, dass das Speichermodell nicht von-Neumann kompatibel ist, ist mMn ein gewichtiger Faktor.

Für die, die es nicht kennen:
https://de.wikipedia.org/wiki/Von-Neumann-Architektur
 
Was die SPEC Benchmarkergebnise angeht, wäre es da nicht möglich, das die von einer für HSA optimierten Version stammen? Das heisst, also auch auf der GPU lauft! Es scheint mir unlogisch das AMD mit Excavator die FPU Leistung grösser macht als bei BD und so das übliche Verhältnis von int zu fp Ergebnissen von ca. 1:0,8 auf 1:1.75 ändert. für den Benchmark ist es ja nicht unüblich das er an neue Architekturen angepasst wird und weiter optimiert wird, die letzte Version ist ja von 2011, und gibt als Änderung an an Intel neue CPU angepasst worden zu sein..
Oder ist das ganz eine unlogische Überlegung.
 
Ich halte von dem Leak nicht viel. Wenns jetzt schon Excavator Samples gäbe, dann hätte man die Ende des Jahres rausgebracht und nicht nen ollen Piledriveraufklatsch in Form vom Warsaw.
Wenn man die Benches glaubt, kann man auch das geleakte Die-Foto von Letztens glauben, und das hatte pralle FPU-resourcen 2x256bit FMACs und 4 Thread SMT auf der FPU. Als Beweis kann man die Werte dann aber auch nicht hernehmen,denn das geleakte Foto hat der Chinese sicher auch gekannt ...
 
Befriedigt mich noch nicht ganz, das liest sich alles ganz nett, aber die WCA verwaltet den Speicher grundlegend anders. Hab das WCA Paper noch nicht genau gelesen, aber ein HSA-Paper beruhigt mich da nicht.
Hmmm ich bin nicht sicher was dich stört, doch unter Abschnitt 2.2.5 Memory ordering des WaveScalar Papers wird ausgiebig auf von Neumann Architektur eingegangen und auch wie das funktioniert mit Programmiersprachen die eine solche vN-Architektur erwarten.
Schau vielleicht erst mal dort rein bevor ich noch mehr irrelevante Infos recherchiere ;)
.
EDIT :
.

Es scheint mir unlogisch das AMD mit Excavator die FPU Leistung grösser macht als bei BD und so das übliche Verhältnis von int zu fp Ergebnissen von ca. 1:0,8 auf 1:1.75 ändert.
Wieso erscheint das unlogisch? Wenn die GPU reale Rechenoperationen ausführen soll, dann muss das Verhältnis sich ja drastisch ändern bei entsprechendem Programmcode wenn HSA greift. Das Potential der GPU ist ungleich höher als der CPU.

Wie kommst du auf das 1:0,8 Verhältnis und mit welchem Code ist dieser definiert?
mit/ohne AVX? mit/ohne OpenCL?
 
Wenns jetzt schon Excavator Samples gäbe, dann hätte man die Ende des Jahres rausgebracht und nicht nen ollen Piledriveraufklatsch in Form vom Warsaw.
Gerade das ist eher ein positives Indiz: Kommt Excavator erst in weiter Ferne, muß man noch was auf Steamrollerbasis bringen, aber kommt XV relativ bald, kann man mit PD noch eine Weile überbrücken. Da Intel in 2014 mit DDR4 auf der Serverplattform anfangen will und es so verfügbar wird, kann AMD damit auch eine neue (APU-)Serverplattform launchen und da gleich XV als CPU-Kerne einsetzen. Wäre eine gute Zäsur, um mit allem aufzuräumen (HT, DDR3, alte CPU-Architektur).
 
Also das seh ich aber anders. Wenn Excavator wirklich so ein Wurf ist, muss es jetzt mit dem neuen Prozess Samples geben, damit man den auch 2015 fertig hat. Das wird bei der Komplexität sicher bis Rev.C dauern bis das Massenproduktionstauglich ist. Und man wird zu 99,999% dafür auch den 28SHP verwenden. Das Canceln der großen Komodo und SR-Prozessoren hat eben auch einiges an Entwicklungsfähigkeit für Excavator freigemacht. Man darf nicht vergessen, dass man Exc. erst in einem neuen Fertigungsprozess auflegen wollte (20nm SHP alias 16nm AMD/IBM SOI-Fertigung?). Das Vorziehen von Excavator im "alten" Prozess ist der logische Schritt. Für Excavator wäre es 2014 einfach zu knapp gewesen, dashelb gibts noch mal den Warschau-Kern. Als Überbrückung reicht das noch mal.
 
Zuletzt bearbeitet:
Zurück
Oben Unten