Spekulationsthread: Was kommt 2011+

Mein Prognose ist schon seit längerem Nehalem IPC, das muss reichen und mit dem RRC, dem CMP-Fusion und den ganzen neuen Prefetcher und dem breiten Dispatch (wozu auch immer der jetzt gut sein wird ^^) denke ich, dass das auch durchaus drin ist. Den Rest muss dann der Takt und/oder FMA4/XOP erledigen.

Für Letzteres sollte es für den Endanwender wenigstens nen tollen, langen SiSoft Sandra Balken zu bestaunen geben, da deren Rechenleistungsbenchmarks immer an CPUs angepaßt werden *chatt*

ciao

Alex
 
Triskaine schrieb:
Ich meine damit tendenziell die Single-Thread performance, wobei IPC natürlich mehr als nur das ist.
Um AMD's Willen hoffe ich doch stark auf einen annehmbaren Sprung, so ca. 15 %, ansonsten müsste AMD schon mit 5,0+ GHz anrücken um mit Sandy Bridge konkurrieren zu können.
Zum Vergrößern anklicken....
Wie häufig kommt eigentlich Single-Thread überhaupt noch vor??!!!!

Gibts dazu Zahlen bzw. Statistiken?

Das wäre interessant zu wissen.

Denn durch das CMT & SMT - Konzept sowie Turbo-Modus muss man ja
Single-Thread ... (ohne Turbo)
Multi-Thread ... (Ohne Turbo)
Anwendungen ... (mit Turbo)
testen. Und dann wäre halt interessant, welcher der Drei Tests am meisten Gewicht für Pauschale Aussagen hat.

@Opteron
Nur noch eine naive Frage
1xComplex & 1xFastpath,
Was heißt Fastpath. Bedeuted Fast ein doppelter Takt alias Hochtakt(-Design)?
 
aylano schrieb:
@Opteron
Nur noch eine naive Frage
1xComplex & 1xFastpath,
Was heißt Fastpath. Bedeuted Fast ein doppelter Takt alias Hochtakt(-Design)?
Zum Vergrößern anklicken....

Ne Fastpath sind die x86 Befehle die in einem Rutsch in eine MacroOp umgewandelt werden können.
Aus nem früheren Kanter Artikel:
Like the Pentium Pro, the K7/8 has an internal instruction set which is fairly RISC-like, composed of micro-ops. Each micro-op is fairly complex, and can include one load, a computation and a store. Any instruction which decodes into 3 or more micro-ops (called a VectorPath instruction) is sent from the pick buffer to the microcode engine. For example, any string manipulation instruction is likely to be micro-coded. The microcode unit can emit 3 micro-ops a cycle until it has fully decoded the x86 instruction. While the microcode engine is decoding, the regular decoders will idle; the two cannot operate simultaneously. The vast majority of x86 instructions decode into 1-2 micro-ops and are referred to as DirectPath instructions (singles or doubles).
Zum Vergrößern anklicken....
http://www.realworldtech.com/page.cfm?ArticleID=RWT051607033728&p=4

Dabei gilt:
Vectore Path = Complex
DirectPath = FastPath

Das sind nur AMD/Intel Nomenklaturunterschiede. Sicherlich auf unterster Ebene ein kleines bisschen unterschiedlich, aber so genau muss man das hier jetzt nicht breit treten ;-)

Laut den Patenten hat BD jetzt eventuell 4 Blöcke á 1xFP & 1xComplex, und die Blöcke können unabhängig voneinander operieren. Das steigert den Durchsatz für Complex Instr. ungemein, v.a. blockierte eine complex. Instr. nicht alle anderen Decoder, wie es bisher der Fall ist.

ciao

Alex
 
Zuletzt bearbeitet:
Nach der Berechnung wäre ein Nehalem aber auch "nur" 14% vor Deneb mit der IPC.
Und wir hatten hier schon mehrfach Diskussionen wo 20% und mehr gefallen sind. Kommt also wohl ziemlich deutlich auf die Benchmarks an.
Nehalem IPC wäre ok, wobei etwas mehr ja auch nicht so abwegig ist wenn man bedenkt wie grundlegend anders BD im Vergleich zu K10 ist (und wie lange daran herumentwickelt wurde), und schon K10 hat gegenüber K8 deutlich über 10% geschafft und das war "nur" ein besserer Refresh.
Daher hat BD schon durchaus ddie Vorraussetzungen mit modernem Prefetching, Goodies wir Loop-Cache und dergleichen einiges mehr herauszuholen, oder zumindest konsistenter zu sein in der Leistung... also womöglich steigt die absolute IPC nicht sehr deutlich, aber dafür die durchschnittliche. *noahnung*
 
Ge0rgy schrieb:
also womöglich steigt die absolute IPC nicht sehr deutlich, aber dafür die durchschnittliche. *noahnung*
Zum Vergrößern anklicken....
Lol, IPC ist per se ein Durchschnitt (wenn auch keiner weiss, aus welchen Programmen ^^).

Ich denke aber, dass das eigentlich überall steigen sollte - zumindest mit nem RRC. Eventuell hat man sich den zwar noch gespart, dann weiss ich nicht - aber ich glaubs nicht, denn für ein Hochtakt Design ist sowas eingentlich ein Muss. Von daher bin ich optimistisch.

Im 3DC meinte jemand, dass der Intel Vorteil v.a. auch aufgrund des besseren Speichersubsystems vorhanden wäre, da wird ja jetzt auch per Prefetcher und den memory disambiguation Teil nachgelegt, von daher bin ich für den Fall ebenfalls optimistisch.

So schlimm kanns gar nicht kommen. Das einzige Problem das ich im Moment noch sehe ist GF's 32nm Prozess *g*

ciao

Alex
 
Zuletzt bearbeitet:
Ok, dann formulieren wir es anders...
die im querschnitt über x breit gefächerte Anwendungen erzielbare IPC.
Es nützt nix wenn im extremfall bei 1 einzigen, seltenen Programm eine super IPC rausspringt, wenn dafür beim Gros der Wald- und Wiesensoftware nichtmal ein viertel davon erreicht wird...

Das meinte ich damit... die Balken die in Deneb eh schon lang sind, müssen nicht noch dramatisch länger werden, aber diejenigen in denen Deneb sich schwertut könnten in BD hoffentlich etwas nach oben hin zulegen, damit das ganze Feld näher zusammenrückt... das ergäbe in der Summe auch einen deutlichen Nutzen für den anwender ohne dramatische Peak-werte
 
Ge0rgy schrieb:
Das meinte ich damit... die Balken die in Deneb eh schon lang sind, müssen nicht noch dramatisch länger werden, aber diejenigen in denen Deneb sich schwertut könnten in BD hoffentlich etwas nach oben hin zulegen, damit das ganze Feld näher zusammenrückt... das ergäbe in der Summe auch einen deutlichen Nutzen für den anwender ohne dramatische Peak-werte
Zum Vergrößern anklicken....
Solange die Balken nicht aufgrund diverser Intel Compilerflags zu niedrig waren, sehe ich da (inkl. RRC) kein Problem ;-)
Bin mal gespannt, ob der Itunes Konverter mit Bulldozer SSE4.1 nutzen wird, oder nicht ^^

ciao

Alex
 
Opteron schrieb:
... Ich denke aber, dass das eigentlich überall steigen sollte - zumindest mit nem RRC. Eventuell hat man sich den zwar noch gespart, dann weiss ich nicht - aber ich glaubs nicht, denn für ein Hochtakt Design ist sowas eingentlich ein Muss. Von daher bin ich optimistisch ...
Zum Vergrößern anklicken....
Ich wills mal so formulieren.

Da AMD zeitgleich und nicht mit zwei Jahre Latenz die aktuellste Ausführung von Intels Vektor-Instruktionensatz namens AVX nutzt, wird der kleine x86-Scheinriese selbst bei einer hypothetischen "schlechtestmöglichen" K10-Architektur, mit AVX, SSE4.1 und SSE4.2 und ja auch SSSE3 in der "IPC" zulegen.

Ich nehme aber mal schlicht an, dass der Bulldozer um so mehr von einer Vektor-Maschine profitiert, weil schon mit Anbeginn der Bulldozerentwicklung an einer mächtigen Gleitkommaeinheit gearbeitet hat (ganz altes Stichwort "Tarantula, etwas jüngeres Stichwort SSE5).

Und weil SSE4.1 und SSE4.2 schon längst bei den wichtigeren Softwareanbietern berücksichtigt ist, wird der Bulldozer sich ins gemachte Bett setzen ... ohne dass da ein neuer Instruktionensatz AVX im Spiel ist.
Womöglich gehört dann auch noch AES-Beschleunigung dazu ... wobei man hier anmerken darf, dass auch VIA schon mit Padlock vor Intel sich der Kryptobeschleunigung angenommen hat. Aber Intel meidet ja Fremdlösungen an der eigenen ISA x86, wie der Teufel das Weihwasser.

MFG Bobo(2010)
 
Zuletzt bearbeitet:
Außer sie heißen x86-64 ;D

Soweit ich mich erinnere geht VIAs PadLock-Engine aber auch einiges über Intels AES-NI hinaus....
Nunja...wer weiß schon wie lange AES noch eingesetzt wird... DES war auch mal unknackbar ;)
 
Bobo_Oberon schrieb:
Ich wills mal so formulieren.

Da AMD zeitgleich und nicht mit zwei Jahre Latenz die aktuellste Ausführung von Intels Vektor-Instruktionensatz namens AVX nutzt, wird der kleine x86-Scheinriese selbst bei einer hypothetischen "schlechtestmöglichen" K10-Architektur, mit AVX, SSE4.1 und SSE4.2 und ja auch SSSE3 in der "IPC" zulegen.

Ich nehme aber mal schlicht an, dass der Bulldozer um so mehr von einer Vektor-Maschine profitiert, weil schon mit Anbeginn der Bulldozerentwicklung an einer mächtigen Gleitkommaeinheit gearbeitet hat (ganz altes Stichwort "Tarantula, etwas jüngeres Stichwort SSE5).

Und weil SSE4.1 und SSE4.2 schon längst bei den wichtigeren Softwareanbietern berücksichtigt ist, wird der Bulldozer sich ins gemachte Bett setzen ... ohne dass da ein neuer Instruktionensatz AVX im Spiel ist.
Zum Vergrößern anklicken....
Inklusive den ganzen Befehlssatzerweiterungen müssen wir nicht diskutieren, ich erwarte v.a. bei Spec mit den XOP und FMA4 Teilen einen starken Sprung, der Intel erschrecken wird, Open64 Compiler sei Dank :)

Aber beim Rest ist mir Bange, dass die schönen SSSE3 & SSE4.X Betten für AMD Dank "Compileroptimierung" unereichbar bleiben und BD eher auf dem harten Teppichvorleger landet.

Ein Beispiel z.B: das oben erwähnte ITunes, das hat nachweislich Intel SSE4.1 Befehle ... bin gespannt, wie das laufen wird. Immerhin kann mans ja mittlerweile ja per VM problemlos nachweisen.

ciao

Alex
 
K10.5 hat im Durchschnitt 20% mehr IPC als K8
in seltenen Anwendungen sind es auch mehr.
 
Ich denke Apple "optimiert" nicht so stark auf Intel, da die ja wahrscheinlich größtenteils den Clang Compiler einsetzen. Und das Gerücht, dass Apple auch bei den CPUs auf AMD setzen möchte gibt es ja immer noch.
 
@Opteron

Ein Frage habe ich noch
The vast majority of x86 instructions decode into 1-2 micro-ops and are referred to as DirectPath instructions (singles or doubles).

Also,
Irgendwie hört sich die Trennung von Direktpath und Vetorepath sowie der Erhöhung von 3 auf 4 Decoder (4+4 statt 3+1) im Front-End nach einer Verarbeitungs-Verdopplung x86-Befehle an, was dann aufgrund des 2. Integer-Core böntigt wird??
Kommt das hin?
 
aylano schrieb:
@Opteron

Ein Frage habe ich noch
The vast majority of x86 instructions decode into 1-2 micro-ops and are referred to as DirectPath instructions (singles or doubles).

Also,
Irgendwie hört sich die Trennung von Direktpath und Vetorepath sowie der Erhöhung von 3 auf 4 Decoder (4+4 statt 3+1) im Front-End nach einer Verarbeitungs-Verdopplung x86-Befehle an, was dann aufgrund des 2. Integer-Core böntigt wird??
Kommt das hin?
Zum Vergrößern anklicken....
Ne, die Complex Decoder werden verdoppelt, ja - aber wie oben drüber steht, sind die laufen die meisten x86 Befehle über die FP Decoder. Irgendwo war mal ne Übersicht, da hatten complex Instr. nur nen Anteil von 1% *lol*
Sieht so aus als ob AMD da in Zukunft also diesen Anteil erhöhen möchte. Das Thema hatten wir schon vor ner Zeit mit Dresdenboy diskutiert, such mal nach "Known Good Code" oder KGC.
Kurz: Eventuell bekommt man in Zukunft ne neue Befehlssatzerweiterung per BIOS Update geliefert.

ciao

Alex
 
Opteron schrieb:
Sieht so aus als ob AMD da in Zukunft also diesen Anteil erhöhen möchte. Das Thema hatten wir schon vor ner Zeit mit Dresdenboy diskutiert, such mal nach "Known Good Code" oder KGC.
Kurz: Eventuell bekommt man in Zukunft ne neue Befehlssatzerweiterung per BIOS Update geliefert.
Zum Vergrößern anklicken....

Spinnen wir das noch ein wenig weiter: Wie wäre es mit einem weiteren kleinen integrierten FPGA als zusätzliche ALU ........
 
Meckel schrieb:
Spinnen wir das noch ein wenig weiter: Wie wäre es mit einem weiteren kleinen integrierten FPGA als zusätzliche ALU ........
Zum Vergrößern anklicken....
AMD hat vor Jahren mal die Firma Vantis für programmierbare Logik erworben und dabei Geld verbrannt.

Fazit: Reizvolle Idee, aber nicht ganz auf der AMD-Tagesordnung. Tatsächlich gibt es aber die Kombination von FPGAs und Prozessoren. Insbesondere Xilinx hat sich damit hervorgetan. Dabei wurden SPARC, als auch Power-Kerne verwendet.

MFG Bobo(2010)
 
Meckel schrieb:
Spinnen wir das noch ein wenig weiter: Wie wäre es mit einem weiteren kleinen integrierten FPGA als zusätzliche ALU ........
Zum Vergrößern anklicken....

dies wären ja fast wieder Zeiten a la x87er, wo man ggf auch mal nen x87er als Zusatzchip drauf packen konnte ;

Ggfs könnte man ja zusätzl. Recheneinheiten per HTX oder PCIE-Karte anbinden
 
FPGAs in Kombination mit einer CPU sind ein sehr reizvolle Idee und auch extrem Leistungsfähig. Bei Cray gab es ja Zeitweise Rechner, welche zusätzliche FPGAs in den Opteron Sockeln hatten. Der Aufwand für die Programmierung ist aber extrem. Wenn man sieht wie schwer sich die Softwareschmieden mit GPGPU tun, glaube ich kaum das FPGAs irgendeine Chance im Consumer Markt haben. Die lassen sich mit herkömmlichen Programmiermethoden überhaupt nicht mehr erfasssen, im Gegensatz zu GPUs, die noch relativ leicht in bestehende Programme einzubinden sind.
 
Sehr interessanter Artikel zu Bulldozer auf realworldtech: http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333

"...Bulldozer is a high frequency optimized CPU, a so called speed demon. This approach has fallen out of popularity in the x86 world, due to Intel’s misadventures with the Pentium 4. In all fairness though, many of the Pentium 4’s problems were unrelated to high clockspeed and more closely tied to the actual microarchitecture. In the high-end server world, IBM has successfully pursued high clock speeds with the POWER7. So a speed demon approach can work out successfully. Bulldozer has a fairly lengthy pipeline, to minimize the gate delays per stage. AMD was unwilling to share any specifics on gate delays, although some discussions at comp.arch suggest a target of ~17 gate delays vs. ~23 for Istanbul. To tolerate the increased latencies necessary for a high frequency target and to efficiently share resources between cores, Bulldozer introduces decoupling queues between most major stages in the pipeline. ..."
 
BavarianRealist schrieb:
Ist mir da was entgangen? :o

Hab es leider nur überflogen...und so ist mir das wohl entgangen... :]
Zum Vergrößern anklicken....

Passiert, kein Ding ;-)

Überflieg mal das:

orochidiek0uu.jpg

http://www.pcper.com/comments.php?nid=9207

Also der L3 Cache da in der Mitte kommt mir verdächtig kompakt vor ... T-RAM *buck* ?

Ich frag mich ja echt, wieso sowas jetzt noch von GF gezeigt wird ... geht den Jungs dort doch eigentlich nichts mehr an ... naja egal .. hab ja nichts dagegen ^^

ciao

Alex
 
SPawner schrieb:
Man kann ziehmlich gut die Power Gating-Transitorreihen sehen oder?
Zum Vergrößern anklicken....

Öhm wo ?

Ich sehe im Moment erstmal nur den Trace bzw. RRC Chache *em_hurra*

Aber vielleicht täusch ich mich da auch nur ^^

Kleine Wegbeschreibung:
Kern rechts unten
neben dem L2 Cache rechts (oben), unter dem L3 Cache Anteil sollte die erste dicke, große Fläche der 64kB große L1I$ sein.
Senkrecht darunter erwarte ich dann einen Integer Cluster/Core, da sieht man zuerst ein kleineres Speicherareal und einen Level darunter dann ein ca. doppelt so großes.

Ich kann mich sehr gut täuschen, aber ich hoffe mal, dass Block No.1 ca. 8 kB L0/Trace/RRC Cache sind und das darunter dann die bekannten 16kB L1D$.

Mal schauen was die Experten sagen, vielleicht ist das auch nur irgendein anderer Puffer ;)

ciao

Alex
 

Ähnliche Themen

S
HP Victus Gaming Knaller, mit Phoenix aus der Asche?
Antworten
17
Aufrufe
2K
NEO83
NEO83
Onkel_Dithmeyer
News AMD APUs im Wandel der Zeit: Llano | A8-3870K
Antworten
19
Aufrufe
3K
Onkel_Dithmeyer
Onkel_Dithmeyer
E555user
News CDNA Whitepaper - Unterschiede zu RDNA
Antworten
2
Aufrufe
1K
E555user
E555user
pipin
Kontron COM Express® Module mit AMD Ryzen™ Embedded R1000 SoC
Antworten
0
Aufrufe
791
pipin
pipin
eratte
News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)
29 30 31
Antworten
763
Aufrufe
100K
drSeehas
D
Zurück
Oben Unten