HT oder HT+ beim Athlon64 möglich?

[²Thom]

Der Athlon64 besitzt ja Registersätze für 32 bit und 64 bit.
Nun meine Überlegung: Da eigendlich nichts gegen eine 32 bit Nutzung der 64bit-Register spricht, besteht der athlon 64 im Prinzip aus zwei(bis drei) kompletten 32bit Ausführungseinheiten, die weniger miteinander zu tun haben als die im P4 mit HT. Mit leichten Modifikationen sollte es möglich sein (zweiter oder softwaremässig zweigeteilter Thread-Stack) so was wie HyperThreading zu veranstalten.

Kann jemand meine Idee verstehen/bestätigen?

Soviel ich noch im Kopf habe, hat der 64bit-Teil doppelt so viele Register--- d.h 3x32bit-Einheiten. Auch die Sache, dass der Prozessor ein 64bit Betriebssystem fahren kann und gleichzeitig 32bit-Programme abarbeiten kann bestärkt mich dessen.

[StefanV]

naja, AMD sagte mal vor langer Zeit:

Bevor wir SMT nutzen, packen wir 2 Cores auf einen Prozessor'

Lt. Einigen 'Gerüchten' soll der Speichercontroller das Hammers auch für Dualcores ausgelegt sein, so daß wir bei 90nm eventuell Dual Core CPUs sehen können (welche sich dann allerdings den Cache teilen würden).

[Gast]

Original geschrieben von Stefan Payne
Lt. Einigen 'Gerüchten' soll der Speichercontroller das Hammers auch für Dualcores ausgelegt sein, so daß wir bei 90nm eventuell Dual Core CPUs sehen können (welche sich dann allerdings den Cache teilen würden).

Das sind keine Gerüchte sondern offzielle Angaben von AMD die bei der Vorstellung des A64 gemacht würden ;)

Und zum Thema:
Nein geht nicht ,da die Register nicht unabhängig voneinander sind
Im Kombimodus 64/32 Bit stehen ausserdem nur Teil der Register des 64 Bit Modus zur Verfügung ;)

[Muh-sagt-die-Kuh]

SMT erfordert ein bischen mehr als nur doppelte Register, unter anderem Flags für die Befehle in-flight, einen doppelten Instruction-TLB,...

In anderen Worten: SMT erfordert Modifikationen an der Hardware, der Hammer Kern in seiner aktuellen Form ist definitiv nicht dazu fähig.

[²Thom]

Original geschrieben von Gast

Im Kombimodus 64/32 Bit stehen ausserdem nur Teil der Register des 64 Bit Modus zur Verfügung ;)

Ich meinte ja dass SMT nur für den 32Bit-Mode in Frage kommt und nicht als Dual-Core sondern auf dem existenten Die.


Und zum Kommentar Deines Nachfolgers sage ich, da ich schon mal in Assembler reingeschaut habe, dass es gundsätzlich möglich wäre den Instruction-Cache in der Hälfte aufzutrennen. Entscheidungskriterium (Flag) wäre das erste Bit in der Positionsnummer der Cache-Line. Mit einem speziell angepassten Bios und Kernel sollte so was möglich sein. Nur nutzt man real nicht immer die gegebenen Möglichkeiten. Sowas könnte man aber für ein neues OS nutzen oder für ein Hammer-Extreme-Performance-Linux.
;D

[Bokill]

HT ist schlichtes Marketing...

HT wird vom Hypertransportkonsortiuim übrigens für den Hypertransportlink als Akronym auch genutzt.

Man sollte daher lieber SMT sagen. War übrigens von DEC konsequent durchdacht worden... war für den Alpha EV-8 geplant... schon früher als Intels P4.

Hatte ja auch gewisse Gründe, dass "HT" beim P4 anfangs deaktiviert war... zufälligerweise wurde Compaq von HP übernommen, Compaq sollte deswegen aus kartellrechtlichen Gründen DEC`s Entwickler ausgliedern (Die Alpha- Jungs)... zufälligerweise hatte Intel interesse und kaufte die Entwicklungsabteilung...

rein zufällig wurde das Projekt EV- 8 eingestellt... rein zufällig konnte der P4 plötzlich SMT... rein zufällig konnte nun ein Bedarf für den Itani(c)um festgestellt werden... Alles Zufälle, so ein Glück aber auch.

Durch das Patentaustauschabkommen könnte AMD dies eventuell ebenfalls integrieren, aber nicht nur DEC,Intel sondern andere haben sich verschieden Varianten von SMT ausgedacht. IBM hatte da für den Power5 gar ein intelligentes sich selbst ein und ausschaltendes SMT ausgedacht... ... MIPS hatte ebenso solche Konzepte für spätere Generationen ausgedacht.
CMS "CodeMorphingSoftware" von Transmeta könnte möglicherweise dies gar in Software SMT nachbilden... is aber eine ganz wilde Spekulation von mir.

AMD muss aber geizig sein mit Transistoren, könnte glatt sein dass dies bei den Hämmern nicht so viel bringt (muss schon seine Gründe haben weswegen IBM ein sich selbst ein und aússchaltendes SMT ausgedacht hat)

[StefanV]

Original geschrieben von Bokill
AMD muss aber geizig sein mit Transistoren, könnte glatt sein dass dies bei den Hämmern nicht so viel bringt (muss schon seine Gründe haben weswegen IBM ein sich selbst ein und aússchaltendes SMT ausgedacht hat)

In der Praxis könnte es durchaus vorkommen, daß eine CPU ohne SMT schneller ist (was auch vorkommt).

Der Grund ist, daß einige Teile andere Teile mehr oder midner blockieren könnten...

Das mag auch der Grund sein, warum AMD mal sagte, daß sie auf SMT pfeifen und lieber 2 Cores in ein DIE packen werden.

Und soo viele Transistoren hat eine 'normale' CPU ohne Cache nun auch wieder nicht ;)

Beim K8 dürfte man (Pi mal Daumen) mit 5-6MIO auskommen, wenn man den L1 und L2 Cache sowie diverse Dinge, die man nicht nochmal benötigt, weglässt...

[Bokill]

1. POWER5, UltraSparc IV, and Efficeon: a look at three new processors von Jon "Hannibal" Stokes (http://arstechnica.com/cpu/003/mpf-2003/mpf-2003-2.html)

2. Where going, Intel? (http://www.xbitlabs.com/articles/editorial/display/intel.html)

Eigener thematischer Thread dazu auf P3D
Strategische Überlegungen64Bit; IBM SUN AMD Intel (http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=121172&perpage=25&pagenumber=1)

[Hamster]

Original geschrieben von Stefan Payne
In der Praxis könnte es durchaus vorkommen, daß eine CPU ohne SMT schneller ist (was auch vorkommt).

Der Grund ist, daß einige Teile andere Teile mehr oder midner blockieren könnten...

Das mag auch der Grund sein, warum AMD mal sagte, daß sie auf SMT pfeifen und lieber 2 Cores in ein DIE packen werden.

Und soo viele Transistoren hat eine 'normale' CPU ohne Cache nun auch wieder nicht ;)

Beim K8 dürfte man (Pi mal Daumen) mit 5-6MIO auskommen, wenn man den L1 und L2 Cache sowie diverse Dinge, die man nicht nochmal benötigt, weglässt...


naja, aber zumindest nen 2. l1 cache wirste der 2. einheit doch noch zusprechen, oder?

[CrazyIvan]

@ SP

Is wohl n bissl ne optimistische Schätzung. Gut die Hälfte der Transistoren gehört dem L2-Cache. Der Memory Controller und L1 - Cache dann vielleicht nochmal die Hälfte. Dann bleibt noch 1/4 übrig.

Irre ich mich, oder hatte der Athlon64 nicht bloß 20 - 24 Mio Transistoren... ;D

Gutes Photo gibbet übrigens hier (http://common.ziffdavisinternet.com/util_get_image/2/0,3363,sz=1&i=23051,00.jpg) .

[zeckensack]

Original geschrieben von Hamster
naja, aber zumindest nen 2. l1 cache wirste der 2. einheit doch noch zusprechen, oder? Hat der P4 auch nicht.

[StefanV]

Original geschrieben von CrazyIvan
@ SP

Is wohl n bissl ne optimistische Schätzung. Gut die Hälfte der Transistoren gehört dem L2-Cache. Der Memory Controller und L1 - Cache dann vielleicht nochmal die Hälfte. Dann bleibt noch 1/4 übrig.

Nö, warum??

Ein P4 hat ja auch nur 7,5 MIO Transis...
Nagut, ein K7 hat immerhin 22MIo, dafür hat der aber auch die 4 Fache Menge an L1 Cache...

Und 'nen Cache sowie einige andere Dinge (z.B. HT Link, Speichercontroller) benötigt man nicht mehrfach, kann man also 'abschneiden'.

Original geschrieben von Hamster
naja, aber zumindest nen 2. l1 cache wirste der 2. einheit doch noch zusprechen, oder?

Nö, wäre a) zu teuer und b) nicht wirklich nötig...
Da würd ich eiskalt den gesamten Cache sharen lassen, ev. die Assizivität verbessern...

[BlackBirdSR]

Original geschrieben von Stefan Payne
Nö, warum??

Ein P4 hat ja auch nur 7,5 MIO Transis...
Nagut, ein K7 hat immerhin 22MIo, dafür hat der aber auch die 4 Fache Menge an L1 Cache...


wie kommst du auf 7.5Mio?
Ich komme irgendwie auf 29Mio ohne L2 Cache.

[StefanV]

Original geschrieben von BlackBirdSR
wie kommst du auf 7.5Mio?

Hatte mein Hirn woanders und hab an diverse Dinge gedacht, nur nicht an das, was ich eigentlich sollte :bonk:

Jedenfalls hat 'nur' der 'normale' Pentium 2 aka Deschutes und Klamath 7,5MIO Transis, der Pentium Pro hatte AFAIK 6,5 MIO...

Wie dem auch sei, bitte vergesst meine Transistorschätzungen, die waren irgendwie etwas optimistisch und treffen 'nur' auf den P2 zu *schäm*...

@Stefan Payne

Nächstes mal Hirn anschalten!!!

[Desti]

.

[Hamster]

Original geschrieben von zeckensack
Hat der P4 auch nicht.


der p4 hat aber nur ein core, und wir reden hier von 2 cores auf einem die ;)

[CrazyIvan]

@ hamster

Ich denke, dass hat zecki schon mitgekriegt.
Vielleicht meinte er ja auch nur, dass der P4 keinen "traditionellen" L1 - Cache hat. Der Trace - Cache und der Instruction Cache sind zwar auch sowas in der Art, aber eben kein herkömmlicher L1 - Cache.

Wobei dann meine Frage wäre:
Wäre es nicht ziemlich dämlich seitens intel, bei einem Dual Core diese beiden Caches wieder zu sharen, wo man sie doch grade erst vergrößert hat?
Was bei nem zu kleinen Trace Cache rauskommt, kann man doch AFAIK bei den derzeitigen P4 Cellis sehen.

Oder hab ich da was verhaun ?(

[Hamster]

Original geschrieben von CrazyIvan
@ hamster

Ich denke, dass hat zecki schon mitgekriegt.
Vielleicht meinte er ja auch nur, dass der P4 keinen "traditionellen" L1 - Cache hat. Der Trace - Cache und der Instruction Cache sind zwar auch sowas in der Art, aber eben kein herkömmlicher L1 - Cache.

Wobei dann meine Frage wäre:
Wäre es nicht ziemlich dämlich seitens intel, bei einem Dual Core diese beiden Caches wieder zu sharen, wo man sie doch grade erst vergrößert hat?
Was bei nem zu kleinen Trace Cache rauskommt, kann man doch AFAIK bei den derzeitigen P4 Cellis sehen.

Oder hab ich da was verhaun ?(

eben das mein ich.


wenn man nun den l1 cache mit einer weiteren cpu nuti teilen muss, bleiben nur 2 möglichkeiten: 1. jeder kern hat den anspruch auf die hälfte des caches, oder aber 2. sie müssen die selben daten abrackern.

1.eres lösung wurde einiges an performance kosten und 2.eres noch wesentlich mehr. ausserdem wäre es sehr unflexible. bei einem thread sehr schnell, bei 2 threads ewig träge.

also würde ich jedem kern zumindest einen eigenen l1 cache zur verfügung stellen. zumindest den datencache. den instruktionscache könnten sie sich ja teilen...

[BlackBirdSR]

Original geschrieben von Hamster
eben das mein ich.


wenn man nun den l1 cache mit einer weiteren cpu nuti teilen muss, bleiben nur 2 möglichkeiten: 1. jeder kern hat den anspruch auf die hälfte des caches, oder aber 2. sie müssen die selben daten abrackern.

1.eres lösung wurde einiges an performance kosten und 2.eres noch wesentlich mehr. ausserdem wäre es sehr unflexible. bei einem thread sehr schnell, bei 2 threads ewig träge.

also würde ich jedem kern zumindest einen eigenen l1 cache zur verfügung stellen. zumindest den datencache. den instruktionscache könnten sie sich ja teilen...

also wenn man sich den K8 mal so spontan ansieht.. dann sieht das auf den ersten Blick schon so aus, als teilen sich 2 Cores das komplette Frontend.
-> weniger Transistoren, weniger Aufwand, weniger Verlustleistung.
2 Komplette CPUs auf ein DIE zu packen, ist keine leichte Sache.
Nur das Backend mit den Funktionseinheiten zu integrieren macht durchaus Sinn.
Ich glaube nicht, dass Intel es großartig anders macht.

[Hamster]

Original geschrieben von BlackBirdSR
also wenn man sich den K8 mal so spontan ansieht.. dann sieht das auf den ersten Blick schon so aus, als teilen sich 2 Cores das komplette Frontend.



hab ich was verpasst? wo gibt es den einen k8 mit 2 integrierten cores?

[Bokill]

Schon mal was von der SRQ gehört?

Ist der entscheidende Baustein für Datenpakete für die CPU und der Aussenwelt... natürlich ist die X- Bar auch wichtig.
http://sledgehammers.gmxhome.de/stuff/xbar.jpg

War auf P3D drin
http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=97374&perpage=25&pagenumber=5

[CrazyIvan]

@ Hamster

Na noch gibbet den nich - aber die Pläne dazu liegen schon in der Schublade, behauptet zumindest unter anderen auch der Inquirer (http://www.theinquirer.net/?article=12743) . Aber da der K8 nich so ne lange Leitung (;D) wie der P4 hat, ist es wohl durchaus möglich, die Caches zu sharen. Denn Cache bei der Gelegenheit gleichmal zu vergrößern, ist ja wieder ne andere Sache.

@ BlackbirdSR

Hast Du n Photo, oder beziehste Dich auf die Gerüchte bei Inquirer und Xbit???
Zum P4:
Denkste net, dass die Pipeline zu lang ist, um ohne nen eigenen "L1-Cache" pro Core auszukommen, oder doch zumindest den "einen" Cache mindestens zu verdoppeln? Ich denke, P4 und K8 sind in der Hinsicht doch zwei paar Schuhe...

[BlackBirdSR]

Original geschrieben von CrazyIvan

@ BlackbirdSR

Hast Du n Photo, oder beziehste Dich auf die Gerüchte bei Inquirer und Xbit???
Zum P4:
Denkste net, dass die Pipeline zu lang ist, um ohne nen eigenen "L1-Cache" pro Core auszukommen, oder doch zumindest den "einen" Cache mindestens zu verdoppeln? Ich denke, P4 und K8 sind in der Hinsicht doch zwei paar Schuhe...

Eigentlich beziehe ich mich da auf Diskussionen und Bilder die aus den Patenten vom AMD zum K8 enstanden sind.
Es sieht demnach so aus, als würden die Daten sich nach dem gemeinsamen Pipelinedurchlauf einen Core (0,1) "aussuchen (ausgesucht werden)", und dort bearbeitet.
Ob das noch der Fall ist? Bisher gibt es kaum Infos dazu.

Was die Pipeline angeht, könntest du recht haben.
Allerdings ist es beim P4 ja nicht so schlimm, wegen dem TraceCache und den 2 Drive Stufen die man abziehen kann (die lassen nur warten)
Es wäre dann vielleicht sinnvoll, den Datencache zu verdoppeln.
Den TraceCache doppelt auszulegen halte ich momentan aber für ziemlich aufändig, und kostspielig.

Wir werden es in ca 7 Monaten ja sehen, wenn die Gerüchte stimmen ;)

[CrazyIvan]

Original geschrieben von BlackBirdSR
Es sieht demnach so aus, als würden die Daten sich nach dem gemeinsamen Pipelinedurchlauf einen Core (0,1) "aussuchen (ausgesucht werden)", und dort bearbeitet.


Klingt ja interessant.
Verstehe ich das richtig? Ist also so ne Art Hardware Scheduler, der nach der Speicherung der Daten im Cache entscheidet, in welchem Core diese abgearbeitet werden. Würde das nicht bedeuten, dass man damit auch nen einzelnen Thread auf die beiden Cores aufteilen kann?
Reicht die derzeitige Bandbreite des L1 und des L2 Cache des K8 aus, oder müsste man diese vergrößern, damit nich einer der beiden Cores Däumchen drehen muss?

Hast Du vielleicht noch irgend ne Quelle auf Lager, anhand derer ich mich zu dem Thema ein wenig belesen kann?

[BlackBirdSR]

Original geschrieben von CrazyIvan
Klingt ja interessant.
Verstehe ich das richtig? Ist also so ne Art Hardware Scheduler, der nach der Speicherung der Daten im Cache entscheidet, in welchem Core diese abgearbeitet werden. Würde das nicht bedeuten, dass man damit auch nen einzelnen Thread auf die beiden Cores aufteilen kann?
Reicht die derzeitige Bandbreite des L1 und des L2 Cache des K8 aus, oder müsste man diese vergrößern, damit nich einer der beiden Cores Däumchen drehen muss?

Hast Du vielleicht noch irgend ne Quelle auf Lager, anhand derer ich mich zu dem Thema ein wenig belesen kann?

nichts handfestes.. das Meiste einfach aus irgendwelchen Foren threads.
Ob man da allerdings 1 Thread auf 2 Cores aufspalten kann? Wohl kaum.

[CrazyIvan]

Warum nicht?

Stelle mir das so vor:

Wenn die Daten erstmal im L1 - Cache gelandet sind, kann der Scheduler die nach Belieben aufteilen. Hier was an ne ALU von Core 0, da an die FPU von Core 1. Würde für höhere Auslastung sorgen, schließlich sind 2 kurze Pipelines besser füllbar als eine lange. Wie auch immer. Dem OS kann es doch egal sein, solange man den Output am Ende wieder synchronisiert. Inwiefern das ein Problem ist, wage ich jetzt nicht zu beurteilen.

Aber schließlich bist Du ja auch der CPU-Guru ;D

P.S.

Siehe Sig :schlag:

[BlackBirdSR]

Original geschrieben von CrazyIvan

Aber schließlich bist Du ja auch der CPU-Guru ;D



das macht mich auch nicht intelligenter :D

[GloomY]

Original geschrieben von CrazyIvan
Würde für höhere Auslastung sorgen, schließlich sind 2 kurze Pipelines besser füllbar als eine lange.Diese Aussage ist mit Garantie falsch.

Die Länge einer Pipeline hat doch nichts damit zu tun, wie gut man diese füllen kann. Es kommt darauf an, wie oft ein Befehl fertig wird, das ist mit "Füllung" gemeint. Die Länge der Pipeline bestimmt doch nur, wie lang es dauert, bis ein Befehl - nachdem er vorne reingesteckt wurde - hinten fertig abgearbeitet wieder herauskommt.

Mehrere Pipelines zu füllen ist immer schwieriger als nur eine, da man eine Parallelität bei Befehlen (oder Threads) finden muss. Diese ist aber nicht immer gegeben, deshalb ist es schwieriger mehr Pipelines zu füllen.
Original geschrieben von CrazyIvan
Wie auch immer. Dem OS kann es doch egal sein, solange man den Output am Ende wieder synchronisiert. Inwiefern das ein Problem ist, wage ich jetzt nicht zu beurteilen.Da hätte das OS aber einiges zu tun. Das würde den Performancegewinn sicher wieder auffressen.
Original geschrieben von CrazyIvan
Aber schließlich bist Du ja auch der CPU-Guru ;DGenau deswegen mag ich diese Bezeichnung nicht...

[GloomY]

Original geschrieben von BlackBirdSR
Eigentlich beziehe ich mich da auf Diskussionen und Bilder die aus den Patenten vom AMD zum K8 enstanden sind.
Es sieht demnach so aus, als würden die Daten sich nach dem gemeinsamen Pipelinedurchlauf einen Core (0,1) "aussuchen (ausgesucht werden)", und dort bearbeitet.
Ob das noch der Fall ist? Bisher gibt es kaum Infos dazu.Das heisst, dass das eine CPU wäre, die einfach nur breiter wäre, also die doppelte Anzahl an Ausführungseinheiten besäße. Das Front-End müsste dann aber wohl auch verändert werden, denn bei 2 Threads würde man z.B. wohl schlecht mit 3 x86 Decodern auskommen.
Original geschrieben von BlackBirdSR
Ob man da allerdings 1 Thread auf 2 Cores aufspalten kann? Wohl kaum. Kommt drauf an, ob man die Funktionseinheiten fest den Threads zuordnet oder dies variabel macht. Letzteres wäre quasie der SMT Ansatz der EV8, bloss mit 2 Threads statt mit 4. Ersteres wäre ein klassischer CMP (Chip Multiprozessor) Prozessor.

[Bokill]

Die gegenwärtigen Kommentare von AMD lassen eher die Vermutung zu, dass CMP bzw DP on Die geplant ist... weniger SMT.
Bei sich jeder bietenden Gelegenheit, giesst AMD da seine Hohnsauce darüber. In den Bénchmarkpark von AMD werden bewusst auch Benches hereingepackt, in denen SMT (Intels Hyperthreading) schlecht aussieht... Intel gestaltet natürlich die Benchmarks so, dass SMT besonders gut aussieht.
Flunkern... Lügen... Benchmarks

Ich gehe davon aus, dass sowohl der L1 als auch L2- Cache individuell an den Hammer Kernen angebunden bleibt. Die CPUs quatschen dann besonders heftig über die, schon von mir erwähnte Schnittstelle, SRQ.
Die SRQ bleibt dann einmalig wie auch das Speicherinterface und das Interface mit dem Htr- link.

Als besondere Sparmassname ist dann ein halbierter L2 Cache denkbar. Die Summe des Dual on Die Hammer wäre dann lediglich Hammer1 + Hammerkern2 des K8(ohne L2 Cache, ohne SRQ, ohne Speicherinterface, ohne HTr- Link Interface)

In dieser Konstallation könnten diese (Spar)Exemplare sogar derzeit bei AMD mit vollem Takt schwitzen... nur so eine Spekulation...
Aber es müsste fast nichts Neues erfunden werden, da ja schon die meisten Sachen angedacht waren.

[BlackBirdSR]

Original geschrieben von GloomY
Das heisst, dass das eine CPU wäre, die einfach nur breiter wäre, also die doppelte Anzahl an Ausführungseinheiten besäße. Das Front-End müsste dann aber wohl auch verändert werden, denn bei 2 Threads würde man z.B. wohl schlecht mit 3 x86 Decodern auskommen.


Gute Frage..
der P4 kommt mit 6µOps alle 2 Takte aus.
Aber das sind auch Trace Segmente.

Der K8 kann dagegen nur precoded bits für die Befehle bieten.
Aber gerade beim K8 hat sich eine Menge getan, ohne dass man die Auswirkungen großartig einordnen könnte.
2 neue Pipeline Stufen die sich auf Befehle konzentrieren.
Dazu bessere Branchprediction und 2x64Bit (nicht 128Bit) breiter L2 Cache, viele der Befehle (SSE/2) die beim K7 noch durch den Microcode müssen sind Direct-Path...
SSE2 ist im 64Bit Modus eh anstelle von x87 gesetzt.
Wofür der rießen Aufwand, wenn man nur 3-5% Performance rausholt? Lieber 200MHz mehr oder mehr Cache.

Ist natürlich Alles weit hergeholt. Aber warum nicht?

[haifisch1896]

Geht es hier um Threads in einzelen Programmen oder um Threads allgemein?

Danke,
Hendrik :smokin:

[StefanV]

Original geschrieben von hendrikhey
Geht es hier um Threads in einzelen Programmen oder um Threads allgemein?

Danke,
Hendrik :smokin:

1. Threads...

2. eigentlich gehts um Multicore CPUs...

[CrazyIvan]

Wann war der Zug für mich eigentlich abgefahren?? ;D

Naja, werde mal versuchen, mein gefährliches Halbwissen zu übertünchen...

@ GloomY

Die Länge einer Pipeline hat doch nichts damit zu tun, wie gut man diese füllen kann. Es kommt darauf an, wie oft ein Befehl fertig wird, das ist mit "Füllung" gemeint. Die Länge der Pipeline bestimmt doch nur, wie lang es dauert, bis ein Befehl - nachdem er vorne reingesteckt wurde - hinten fertig abgearbeitet wieder herauskommt.

Mehrere Pipelines zu füllen ist immer schwieriger als nur eine, da man eine Parallelität bei Befehlen (oder Threads) finden muss. Diese ist aber nicht immer gegeben, deshalb ist es schwieriger mehr Pipelines zu füllen.

Stelle mir das sinnbildlich so vor, wie einen Zug, der mehrere abgetrennte Abteile hat und an der Haltestelle alle 5 Sekunden vorwärts fährt, um das nächste Abteil zu beladen. Sollten nicht zu jedem Zeitpunkt Passagiere (Daten) am Bahnsteig (1. Stufe der Pipe) warten, bleibt halt ein Wagon (Pipelinestufe) frei. Somit entstehen Lücken und der der Zug ist nicht optimal ausgelastet. Bei 2 kurzen Zügen wäre das nicht ganz so dramarisch, wenn man davon ausgeht, dass ein Zug immer nur am Bahnsteig anhält, wenn auch wirklich Passagiere dort warten.
Habe ich wenigstens insofern recht, oder kannst Du meine Wissenslücken diesbezüglich vielleicht ein wenig füllen?


Da hätte das OS aber einiges zu tun. Das würde den Performancegewinn sicher wieder auffressen.


Meinte eher, dass in Hardware zu machen. Vielleicht ne Art Minicache, um die Synchronität zu gewährleisten.


quote:
Original geschrieben von BlackBirdSR
Ob man da allerdings 1 Thread auf 2 Cores aufspalten kann? Wohl kaum.

Kommt drauf an, ob man die Funktionseinheiten fest den Threads zuordnet oder dies variabel macht. Letzteres wäre quasie der SMT Ansatz der EV8, bloss mit 2 Threads statt mit 4. Ersteres wäre ein klassischer CMP (Chip Multiprozessor) Prozessor.


Wäre die Verwirklichung so problematisch? Klingt für mich irgendwie nach Nonplusultra - einen Thread auf mehrere Cores aufzuteilen.

@ Hendrik Hey

Ja ganz eigentlich gings hier mal um die Möglichkeit, HT beim K8 einzusetzen. Aber wer über SMT redet, muss ja irgendwann auch die Brücke zu SMP schlagen :schlag:

[SimonX]

Original geschrieben von Bokill

Man sollte daher lieber SMT sagen. War übrigens von DEC konsequent durchdacht worden... war für den Alpha EV-8 geplant... schon früher als Intels P4.



Genau, die aktuellen Desktop-CPU's (Intel, AMD, ...) sind alles Spielzeug wenn man es mit den aktuellen EV7 Alpha vergleicht. Der hat von hause aus eine 12GByte/s Anbindung an den Hauptspeicher (Rambus), 4 mal 25GByte/s Links zu jeweils 4 anderen CPU's bzw. Memory, einen integrierten Memorycontroler, der die 4 25GByte links + das 12GByte Mainmemoryinterface unabhänig von der eigentlichen CPU verwalten kann.

Schade das DEC, Compaq oder heute HP die Alphaentwicklung eingestellt hat. Schon der EV7 ist seiner Zeit voraus.

[Haarmann]

Was ist eigentlich HT? Oder anders, zu was sollte es dienen?

HT wäre vollkommen nutzlos, würde immer die maximal Anzahl Instruktionen in einem P4 auf die Einheiten verteilt. Damit HT also irgendwas positives bewirken kann, muss es brach liegende Einheiten haben. Diese entstehen ev weil der Code dies fürn P4 nicht erlaubt oder weil gerade mal die Daten oder Befehle im Cache fehlen und man wartet auf diese. Nun käme HT zum Zuge und kann die brach liegenden Einheiten von der anderen "CPU" her nutzen - naja, sofern dort die Daten da sind jedenfalls und genau hier haperts. Da heutige CPUs im Endeffekt mehr oder minder Cachechips mit Logik (Flächenanalyse ahoi - the winner takes it all) darstellen, konnte man natürlich nicht jeder logischen CPU nen eigenen Cache spendieren. Die Folge davon ist, dass nun für beide logischen CPUs der gleiche Cache herhalten muss, dessen Trefferrate damit bestimmt nicht gesteigert wird. Grösste Gefahr entsteht hierbei durch Cache Trashing, also CPU0 schmeisst die Daten von CPU1 raus und umgekehrt. Es entsteht nun also die Situation, dass HT was bringt, bei Code, der gut in die halben Caches passt und zur Katastrophe wird, wenn dies nicht der Fall ist. Intel setzt bisher 8 Wege Caches ein. AMD setzt 18 Wege Caches ein (exklusiv Struktur bringt 2+16). Setzen wir nun den Fall, dass AMD HT einsetzen würde, so müssten sich beide logischen Cores den 2 Wege L1 aufteilen, was schief gehen muss. Selbiges wäre ein Celeron NW mit HT aktiviert. Ich denke das Ding würde kaum über die Geschwindigkeit eines P2 233 rauskommen (Simulation Celeron P4 ohne Caches)...
Dementsprechend muss AMD die L1 Caches auch für beide logischen Einheiten separat halten - und dann ist der Rest des CPU Cores einfach nicht mehr gross genug, als dass sich HT bei dieser exklusiven Cache Architektur überhaupt noch lohnen könnte. Somit baut man den restlichen Teil des Cores mit ein, was auch ein "Recycling" erlaubt, falls ein Core tot ist.
Als HT Simulation für nen AMD empfehle ich einfach den L1 mal abzuschalten bei AMD Athlon CPUs... Danach erübrigen sich jegliche Fragen.

[Bokill]

nun Intel.

So ein Zufall auch, dass vorher die Fusion von HP mit Compaq war.

So ein Zufall auch, dass die Alphas den Marketingtod sterben.

So ein Zufall auch, dass EPIC von HP entwickelt wurde zusammen mit Intel.

So ein Zufall, dass HT von intel freigeschaltet wurde, als die Rechte freundschaftich mit DEC/Comaq abgedealt wurden.

So ein Zufall, dass AMD unbedingt ein Nachfolgelink suchte und fand (erfand... den HTr- Link ).

So ein Zufall auch!

Die Welt kann so wunderbar sein, wenn man an "Zufälle" glaubt.

[GloomY]

Original geschrieben von CrazyIvan
@ GloomY


Stelle mir das sinnbildlich so vor, wie einen Zug, der mehrere abgetrennte Abteile hat und an der Haltestelle alle 5 Sekunden vorwärts fährt, um das nächste Abteil zu beladen. Sollten nicht zu jedem Zeitpunkt Passagiere (Daten) am Bahnsteig (1. Stufe der Pipe) warten, bleibt halt ein Wagon (Pipelinestufe) frei. Somit entstehen Lücken und der der Zug ist nicht optimal ausgelastet. Bei 2 kurzen Zügen wäre das nicht ganz so dramarisch, wenn man davon ausgeht, dass ein Zug immer nur am Bahnsteig anhält, wenn auch wirklich Passagiere dort warten.
Habe ich wenigstens insofern recht, oder kannst Du meine Wissenslücken diesbezüglich vielleicht ein wenig füllen?Deine Analogie stimmt nicht ganz. Die Länge des Zugs bestimmt die Kapazität, während bei einer Pipeline eigentlich nur interessiert, was hinten rauskommt. Die Länge ist nur bei Sprüngen interessant.

Das Problem bei zwei Pipelines ist, dass man nicht immer zwei Befehle hat, die man gleichzeitig ausführen kann. Daher ist - unabhängig wie die Pipelines aussehen - die Auslastung von 2 Pipelines generell schlechter als nur von einer.

Man kann sicherlich einen Vorteil aus mehr Pipelines ziehen, jedoch nimmt die Effizienz mit der Anzahl ab. Deshalb lohnt sich auch nur eine geringe Anzahl an Pipelines, da die Auslastung sonst nicht gewährleistet wäre. Normale x86 Prozessoren haben nicht mehr als 3 Ausführungseinheiten (Athlon), EPIC hat durch IPC Maximierung bis zu 6 Ausführungseinheiten. Mehr ist definitiv nur mit gleichzeitiger Ausführung von mehreren Threads (SMT/CMT) sinnvoll.
Original geschrieben von CrazyIvan
Meinte eher, dass in Hardware zu machen. Vielleicht ne Art Minicache, um die Synchronität zu gewährleisten.Ich weiss nicht, ob man das performant in Hardware lösen kann...:|
Original geschrieben von CrazyIvan
Wäre die Verwirklichung so problematisch? Klingt für mich irgendwie nach Nonplusultra - einen Thread auf mehrere Cores aufzuteilen.Oh doch, das ist imho ziemlich schwierig.