Archiv verlassen und diese Seite im Standarddesign anzeigen : HTT und AMD?
Botcruscher
2009-06-07, 22:43:20
Wie steht es eigentlich um Hyper-Threading bei AMD?
Das AMD Marketing setzt im Moment ja noch auf echte physikalische Kerne. Werden wr HTT bei einer zukünftigen CPU-Generation sehen oder verhindern das Intels Patente? Zu dem Thema findet man interessanterweise fast nichts.
Also ich weiss da genügend, finden hmmm könnte vielleicht schwierig werden ...
Schau Dir mal den Thraed hier an:
http://www.planet3dnow.de/vbulletin/showthread.php?t=354511
Ab Dresdenboys Beitrag wirds zu Deiner Frage interessant.
ciao
Alex
deekey777
2009-06-07, 23:58:36
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=373646
Bzw: http://forum.beyond3d.com/showthread.php?t=54018 und http://citavia.blog.de/
http://support.amd.com/us/Processor_TechDocs/43479.pdf
Wohl Kein SMT bei Bulldozer (siehe Äußerungen bei B3D).
Wo liest du da raus, dass kein SMT drin steckt?
Wo liest du da raus, dass kein SMT drin steckt?
Dazu gibts Statements, dass AMD nix von einer Verschlechterung der single-thread performance hält, nachdem man eh bald xfach CMT hat.
Die Patente weisen jetzt darauf hin, dass der zweite INT Cluster spekuliert, fast so ähnlich wie ein Helper Thread bei Suns Rock.
Vorteil bei AMD ist halt, dass sie dazu keinen SMT-Thread nehmen, sondern eigene Piplines dafür abstellen. Damit wird nichts abgebremst.
Abgesehen davon können die 2 INT Cluster wohl auch 2 Threads bearbeiten, ohne Spekulation.
Wobei es da interessant wird, wie das dann bei nem 6-8Kern Prozzesor aufgeteilt wird. Dresdenboy meinte mal, dass AMD mit den 6-8 Kernen auch nur die Cluster/Threads zählen könnte, denn ein Bulldozer Kern wird auch in 32nm nicht wenig Fläche brauchen.
ciao
Alex
deekey777
2009-06-08, 00:35:53
Wo liest du da raus, dass kein SMT drin steckt?
Ich gar nicht, aber die von B3D (hätte dies hinzufügen sollen).
Aber im P3DF-Thread ist diese News samt Diskussion zu finden:
http://www.planet3dnow.de/vbulletin/showthread.php?p=3925915#post3925915
http://www.heise.de/newsticker/AMD-demonstriert-12-Kern-Prozessormodul--/meldung/136604
Etwa ein Jahr später soll für die gleiche Maranello-Plattform der 32-nm-Prozessor Interlagos mit 12 bis 16 Kernen und neuer Architektur (Bulldozer) herauskommen. Soweit man weiß, wird Bulldozer eine Art Hyperthreading unterstützen – beschränkt auf Integer, mit unabhängigen Funktionseinheiten, aber gemeinsamen Caches. Außerdem soll Bulldozer Intels neue Advanced Vector Extension unterstützen (SSE mit 256 Bit Breite), wobei man sich noch mit Intel über das nächste Patentaustauschabkommen einigen muss.
=Floi=
2009-06-08, 00:40:27
zitat
einer Verschlechterung der single-thread performance
trifft das wirklich zu? unterm strich kommt ja mehr performance raus und nicht weniger und die performance pro thread dürfte wohl nicht wesentlich leiden.
trifft das wirklich zu? unterm strich kommt ja mehr performance raus und nicht weniger und die performance pro thread dürfte wohl nicht wesentlich leiden.
Si claro, lass mal 2 boinc Instanzen auf nen i7 Kern laufen.
Da kommt irgendwie Folgendes raus (Fantasiezahlen):
Ohne HT auf einen Kern:
100 sec für eine WU
Mit HT:
150 sec für 2WUs
Nach 300s hat man somit ohne HT 3 WUs, mit HT dagegen 4.
Mit HT steigt der Rechendurchsatz, aber nicht die einzelne Rechengeschwindigkeit.
Aber irgendwann ist es bei den meisten Programmen (abseits Boinc) halt Schluss mit dem sinnvollen Aufteilen, Amdahl läßt grüßen.
Der zitierte heise Artikel finde ich übrigens schlecht geschrieben. Mit Hyperthreading hat der AMD Ansatz nichts am Hut. Aber naja ... das gemeine Volk meint ja nur das Hyperthreading = 2 Threads auf einer CPU bedeutet, nach der Definition stimmts gerade noch ;-)
ciao
Alex
SMT erzeugt zudem etwas Schedularoverhead, da eben entschieden werden muss, ob der Thread jetzt auf echte oder virutelle Kerne verteilt werden muss. Sonst hätte man mit dem CoreI7 teilweise sehr unterschiedliche und recht komische Ergebnisse, wenn man auf die Threadverteilung nicht achten würde. Deshalb laufen wohl Programme, die von SMT garnicht profitieren, z.B. Spiele, eher ein paar % langsamer. Der Trugschluss ist halt der, dass sich die Leistung eines Kerns verdoppelt. Deshalb ist AMDs nächste Schritt ja auch gut verständlich, die Int-Einheiten zu splitten (2x2 statt 1x3) anstatt einfach nur das Drumherum zu verdoppeln wie bei SMT.
Es ist nunmal der nächste logische Schritt die Kerngrenzen aufzuweichen um ein einheitlicheres Leistungsbild hinzubekommen und auch die Leistung pro Thread zu erhöhen. Damit wird SMT schlicht überflüssig, weil eh genug Threads da sind. Ein Orochi wird wohl aus 4 Bulldozer Kernen bestehen, also 8 Threads mit je eigenen Int-Einheiten, wobei im besten Falle die Leistung eines Kerns (2x2 Ausführungseinheiten) für einen Thread verfügbar sein kann oder eben 8 Threads auf 8 Ausführungseinheiten. Damit ließe sich eine CPU weit besser auslasten als mit SMT, wenn man das ganze speculative-Zeug bedenkt ;). Für den Servermarkt ist zudem eine 12-16-Thread-CPU realisierbar.
Botcruscher
2009-06-08, 18:50:46
Das ist ja mal richtig harte Theorie von Dresdenboys.
PS: Mir fehlt irgendwie die Vorstellungskraft um an einen durchgehenden Vorteil von einfach ein paar mehr "freien Einheiten" zu glauben. Den Rest kann man nicht einfach, ohne Leistungsverlust pro Thread, mit mehr Anweisungen vollstopfen. Bei mehr und vorallem unterschiedlichen Kernen wird das Thema aber extrem zukünftige Architekturen beeinflussen.
Sie sind ja nicht unterschiedlich. Du hast ja im Prinzip im Falle des Orochi 8 gleiche Kerne. Nur dass eben alle 2 davon auch einen dickeren Thread bearbeiten können.
zitat
einer Verschlechterung der single-thread performance
trifft das wirklich zu? unterm strich kommt ja mehr performance raus und nicht weniger und die performance pro thread dürfte wohl nicht wesentlich leiden.
HT bringts nur, wenn auch alle threds ausgenutzt werden können
Botcruscher
2009-06-08, 19:31:28
Sie sind ja nicht unterschiedlich. Du hast ja im Prinzip im Falle des Orochi 8 gleiche Kerne. Nur dass eben alle 2 davon auch einen dickeren Thread bearbeiten können.
Ja, noch sind sie gleich. Bei abnehmenden Ertrag war der Gedanke schon etwas vorraus gegriffen.
Ja, noch sind sie gleich. Bei abnehmenden Ertrag war der Gedanke schon etwas vorraus gegriffen.
Hö? Erklärung bidde ;).
Botcruscher
2009-06-08, 20:00:11
Wenn man anfängt die Kerne aufzubrechen ergeben sich neue Möglichkeiten ala Cell/Larrabee nur wesentlich flexibler. Es wäre zB. möglich in echtzeit Threads auf Spezialeinheiten auszulagern.
Man könnte damit auch einfach Einheiten sparen und die CPU flexibler machen. Bei CPUs mit 16 gleichen Kernen wird eh Ende sein. Kerne mit jeweiligen Spezialeinheiten wären eine Möglichkeit.
Alles so Ideen was in Zunkunft möglich wäre.
=Floi=
2009-06-08, 20:12:35
trotzdem geht der amd gedanke genau in die andere richtung. dort soll die performance pro thread erhöht werden und bei intel geht man in die breite.
dort soll die performance pro thread erhöht werden ... und ausserdem 2 Threads (ohne Verluste) gleichzeitig bearbeitet werden ;-)
Das ist ja gerade das schöne am AMD Ansatz, man verliert keine (single) thread Leistung. Vielleicht minimal, da nur noch 2 Piplines statt 3 pro Thread/Cluster verfügbar sind, aber der Leistungsunterschied zw. 2 und 3 Pipes sind marginal, das läßt sich durch die restlichen Verbesserungen wieder auffangen, z.B: nen Loop Detektor wie bei Intel.
Frage ist, wieviel es für single thread bringt, wenn der 2te Cluster für Thread 1 im vorraus spekuliert .. da bin ich mal gespannt, wie genau das ablaufen wird.
ciao
Alex
=Floi=
2009-06-09, 15:20:12
ich sehe da immer noch keinen vorteil. du brauchst 2 kerne für einen thread und ich laste einen kern besser aus, damit dieser bis zu 30% mehr performance bringt. Bei programmen die wenige threads beanspruchen ist man bei amd besser bedient, aber bei wirklich vielen programmen die auch noch multithreading beherschen ist man bei intel wohl besser aufgehoben und die rechenleistung pro prozessor dürfte dort höher sein. aktuell haben wir eher noch das problem der zu wenigen threads und nicht der zu vielen kerne. das möchte ich hier auch mal anmerken. Bei 16 oder 32 cores würde es sinn machen, aber nicht bei nur 2 oder 4 kernen.
Du überschätzt glaube ich SMT. Du vergleichst also einen 6/12-Kern SMT-CPU mit 8 CMT-Kernen. Was ist jetzt besser? Kann man wohl nicht beantworten. Nur weil es bei SMT 12 virtuelle Kerne sind heißt das noch lange nicht, dass man mit diesen besser bedient ist bei MT.
Wenn man anfängt die Kerne aufzubrechen ergeben sich neue Möglichkeiten ala Cell/Larrabee nur wesentlich flexibler. Es wäre zB. möglich in echtzeit Threads auf Spezialeinheiten auszulagern.
Man könnte damit auch einfach Einheiten sparen und die CPU flexibler machen. Bei CPUs mit 16 gleichen Kernen wird eh Ende sein. Kerne mit jeweiligen Spezialeinheiten wären eine Möglichkeit.
Alles so Ideen was in Zunkunft möglich wäre.
Man teilt ja pro 2 Kerne eine bestonders fette FPU. Man könnte hier noch eine Kryptoeinheit mit anfügen. Man könnte in Zukunft die FPU auch sehr breit parallel auslegen, wie eine GPU eben, und diese mit allen Threads teilen. Das wäre dann eine wirklich fusion ;). Vielleicht ist das auch exakt so gedacht bei Fusion (jedenfalls im Endstadium).
Jedenfalls ist dank an 2 Threads geshareten wohl 256Bit breiten FPU FMA4 möglich.
Bei 16 oder 32 cores würde es sinn machen, aber nicht bei nur 2 oder 4 kernen.
Weiss jetzt nicht, wer mit dem ersten Teil gemeint war, aber jetzt zu obigen Teil mein "Senf":
Für Desktop reichen im Moment 4 Kerne, schau doch mal die i7 Kundschaft an ... die schalten HTh ab, zumindest wenn sie Ahnung haben, da es sonst nur Probleme gibt. Übertakten wird auch besser, die die Auslastung eines einzelnen Kerns sinkt, und Hotspots damit kühler bleiben.
Bei den kommenden Nehalem Dual Cores finde ich Hyperthreading klasse, aber darüber wie besagt ... unnütz.
Einsätze wie Dekodieren und Rendern rechne ich zum Workstation Segment. Selbst da wird AMDs Lösung aber auch nicht so schlecht sein.
@HOT:
Ne Art Kryptoeinheit wird auch mit dabei sein, der AMD Entwickler sagt, dass alle Intel Befehlssatzerweiterungen beim Bulldozer unterstützt werden, die es bis dahin gibt .. dazu gehört auch die "AES" Befehlserweiterung, die Intel mit den 32nm Nehalems nächtes Jahr einführt.
Nicht ganz so komfortabel wie VIAs Ansatz (den Intel natürlich nicht unterstützen will), aber immerhin besser als nichts ...
ciao
Alex
Undertaker
2009-06-09, 17:46:47
Für Desktop reichen im Moment 4 Kerne, schau doch mal die i7 Kundschaft an ... die schalten HTh ab, zumindest wenn sie Ahnung haben, da es sonst nur Probleme gibt.
Das würde ich nicht so pauschalisieren. Zweistellige Gewinne in vielen Anwendungen wären mir weitaus mehr wert als geringe einstellige Verluste in einigen wenigen Spielen - wo der i7 auch so schon Vorteile von gut und gerne mal 50% zu Yorkfield oder Deneb hat.
OC ist natürlich ein Punkt, aber so gewaltig sind die Unterschiede da wohl auch nicht bzgl. SMT an/aus.
=Floi=
2009-06-09, 18:26:54
ich denke wir reden noch immer aneinander vorbei. entweder der prozessor macht den takt mit oder er macht es nicht. wir sollten jetzt aber nicht übers übertakten reden, weil das nicht hierhin gehört. SMT dürfte jegliche weitere taktsteigerung ohne smt locker wettmachen. Durch smt hat man eben noch luft nach oben (bezogen auf software die 5 bis 8 kerne auslasen kann) und sobald eine anwendung mehr wie 4 kerne nutzt profitiert man ganz brauchbar davon. (nur durch eine steigerung der effizienz!)
sicherlich reichen im desktop segmwent noch 4 kerne, aber die tendenzen sind da für mehr und ich würde mich schon über 8 oder 16 kerne freuen. mehr halte ich dann aber auch für zu unrentabel. im gesamten gesehen würde mich aber trotzdem so eine mischung aus SMT und der technik von amd freuen. bei der technik von amd brauche ich aber erst einmal genug kerne um normale MT-anwendungen wirklich zu beschleunigen. dort sehe ich den schwachpunk an der idee. man braucht schon einen großen schnellen prozessor um diesen noch schneller zu machen und bei intel skaliert SMT eher im unteren segment und ist oben eher ein tüpfelchen auf dem i. ;) Bei amd würden sich dadurch quasi die kerne halbieren und wenn dann die richtige software zum einsatz kommt könnte es eben nicht schneller sein. (wenn cache hits etc. limitieren. )
Also im Desktop-Segment war von Intel selber die Rede davon, dass man bis 16 Threads die Performance theoretisch steigern kann im Desktop-Bereich - da ist der Ertrag aber schon derart gering ggü. 8 Threads, dass sich das nicht lohnt. PC-Software ist eben nicht bis sonstwohin parallelisierbar, im Gegenteil, man braucht die CPU ja auch garnicht für wirklich massiv parallelen Code, dafür gibts ja auch OpenCL oder andere Techniken. Sicher werden die 4 Threads irgendwann von fast jedem Proggie ordentlich ausgenutzt werden und Programme teilweise bis 8 Threads gut skalieren. Weiter gehts aber eben nur im professionellen Bereich (16-32 Threads). Von daher finde ich die Lösung mit möglichst wenig Leistungsverlust pro Kern gepaart mit möglichst viel Leistung pro Thread ziemlich optimal. Der Weg muss im Prinzip in Richtung der Integration von 8 Threads in einen Kern gehen, sodass man sowohl pro Thread als auch bei vielen Threads die Leistung optimal ausnutzen kann. SMT ist im Prinzip ne "Bauernlösung", weil man hier nur die Unzulänglichkeit die Funktionseinheiten nicht optimal mit Code füttern zu können mit einer MT-Krücke ausbügelt. Das funktioniert aber einfach nicht mehr, wenn man sowieso zuviele Threads zur Verfügung hat, ab da wirkt SMT halt nurnoch Nachteilhaft. Man sieht das hervorragend an der Spieleleistung des Nehalem 4-Kerners. Ehrlichgesagt denke ich auch, dass SMT beim Clarkdale überbewertet wird. Sicherlich wird es was nutzen, es stellt sich aber die Frage wieviel das sein kann. Der CoreI7 ist halt kein P4, der es nicht gebacken bekommt seine Pipelines zu füttern. Das wird ähnlich aussehen wie beim Nehalem, nur verstärkt. Aus den 5% Leistungsvorteil bei nicht-Spielen werden dann 10-15%, aber ich glaube nicht, dass auch hier SMT bei Spielen sonderlich positiv reinhauen wird, maximal 5-10% Leistungsvorteil (und das ist schon optimistisch). Wer jetzt erwartet, dass ein Clarkdale im Prinzip ein 4-Kerner ist, ist einfach auf dem Holzweg. Er ist lediglich in der Lage seine 2 Kerne etwas besser auszulasten und das nichtmal umsonst. Mal sehen, was die bessere Variante ist: Ein echter 4-Kerner wie der Propus oder ein pseudo-4-Kerner wie Clarkdale.
Im Profisegment ist das ein bisschen was anderes, weil da einfach andere Arten von Software eingesetzt wird bei der Threading einfacher zu realisieren ist und/oder mehr Geld in die Optimierung von Code gesteckt wird.
Undertaker
2009-06-09, 19:20:11
Man sieht das hervorragend an der Spieleleistung des Nehalem 4-Kerners.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=455727
Worauf sprichst du da an...?
Generell ist SMT eine äußerst praktische Sache, mehr Leistung für ~5% mehr Diefläche wirst du kaum bekommen können.
=Floi=
2009-06-09, 19:36:11
auch hier bin ich nicht der meinung. Vor allem Ki und andere sachen könnte man da sehr gut in eigene threads auslagern und dann skaliert die sache auch noch mit mehr als 8 threads. vor allem größere maps mit mehr intelligenteren einheiten würde das zugute kommen. Bei den details kann man noch viel weiter gehen als es jetzt der fall ist und die möglichkeiten werden sicherlich genutzt, wenn die rechenleistung (breitflächig) vorhanden wäre.
nebenbei kann man auch andere programme laufen lassen und ggf. könnte man noch einen server hosten etc. Ihr geht immer davon aus, dass nur EINE anwendung davon profitiert und ich sehe da noch bis 32 threads luft im desktop markt. Dadurch kann man einfach den browser und andere programme offen lassen und trotzdem ein spielchen machen. wenn mahrere MT programme laufen dann steigt auch ganz schnell der benötigte bedarf an threads. bisher ist man auch mit der strategie im server- und desktop-bereich die gleichen prozessoren zu verwenden ganz gut gefahren und es profitierten beide seiten.
der i7 wird schon noch seine vorteile zeigen. beim core 2 war es ja auch nicht anders und heutzutage macht der A64 X2 garkeinen stich mehr gegen ihn.
das größte problem ist eben die teure programmierung und der vorhandene codebestand.
reunion
2009-06-09, 20:01:10
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=455727
Worauf sprichst du da an...?
Generell ist SMT eine äußerst praktische Sache, mehr Leistung für ~5% mehr Diefläche wirst du kaum bekommen können.
Wie kommst du auf die 5%? Beträchtliche Dinge der Pipeline müssen wohl doppelt ausgelegt werden. Wenn ich einen Yorkfield-Core mit einem Nehalem-Core Vergleiche komme ich auf beträchtliche Zuwächse. AFAIK <20mm² vs. 25mm². Und so viel hat sich da nicht geändert am Kern selbst.
Welche "beträchtlichen Dinge" sind das denn deiner Meinung nach?
Ich würde auch nicht auf mehr als 10% zusätzlich bei SMT wetten.
BlackBirdSR
2009-06-09, 20:27:05
Wie kommst du auf die 5%? Beträchtliche Dinge der Pipeline müssen wohl doppelt ausgelegt werden. Wenn ich einen Yorkfield-Core mit einem Nehalem-Core Vergleiche komme ich auf beträchtliche Zuwächse. AFAIK <20mm² vs. 25mm². Und so viel hat sich da nicht geändert am Kern selbst.
So viel ist es nicht. Beim Pentium4 bediente man sich z.B dem Trick µOps der beiden Threads zu unterschiedlichen Takten einzuschleusen. Der Schwerpunkt liegt dann nicht in der Steigerung des momentanen Durchsatzes, sondern in der Steigerung des Durchsatzes pro Zeiteinheit. Das beinhaltet auch alle Situationen, wo einer der beiden Threads warten muss. Hier war für den P4 immens viel zu holen.
AnarchX
2009-06-09, 20:37:29
Wenn ich einen Yorkfield-Core mit einem Nehalem-Core Vergleiche komme ich auf beträchtliche Zuwächse. AFAIK <20mm² vs. 25mm². Und so viel hat sich da nicht geändert am Kern selbst.
Laut Hans de Vries:
Penryn - 22mm² (http://www.chip-architect.com/news/Intel_Core_family_picture.jpg)
Nehalem -24,4mm²
(http://chip-architect.com/news/Shanghai_Nehalem.jpg)
Also doch ein etwas geringerer Unterschied.
Da läge durchaus Potential für AMD mit wenig Aufwand ihre CPUs gerade für den Servermarkt entsprechend zu verstärken. Aber da ist AMDs Strategie wohl etwa eigen, wie man auch am Istanbul mit nur 5MiB nutzbaren L3-Cache sieht.
Undertaker
2009-06-09, 21:16:22
Wie kommst du auf die 5%?
Die 5% waren eine Zahl, die man bei P4 lesen konnte, daran wird sich grundlegend nicht viel geändert haben.
wie man auch am Istanbul mit nur 5MiB nutzbaren L3-Cache sieht.
Wegen HT Assist? Oder frisst da noch etwas den L3 weg...?
Wie kommst du auf die 5%? Beträchtliche Dinge der Pipeline müssen wohl doppelt ausgelegt werden. Wenn ich einen Yorkfield-Core mit einem Nehalem-Core Vergleiche komme ich auf beträchtliche Zuwächse. AFAIK <20mm² vs. 25mm². Und so viel hat sich da nicht geändert am Kern selbst.
Da brauchts überhaupt nicht viel wg. SMT, beim P4 sprach Intel mal von 4% wenn ich das recht in Erinnerung habe.
Die Piplines bleiben unangetastet, dass ist doch der Witz an SMT, dass das *vorhandenen* Resourcen ausnützt ;-)
Was doppelt ist sind nur ein die Teile zur Threadverwaltung, das wars.
Der Rest der Die Vergrößerung geht beim i7 auf ganz andre Konten, da wurde nicht nur SMT integriert :)
Die 5% waren eine Zahl, die man bei P4 lesen konnte, daran wird sich grundlegend nicht viel geändert haben.
Doch, durch die Die Shrinks dies mittlerweile gab plus das Wachstum des Intel Dies ansich, sollte das mittlerweile noch (viel) weniger sein ;)
Da läge durchaus Potential für AMD mit wenig Aufwand ihre CPUs gerade für den Servermarkt entsprechend zu verstärken. Aber da ist AMDs Strategie wohl etwa eigen, wie man auch am Istanbul mit nur 5MiB nutzbaren L3-Cache sieht.
Na den Probefilter kannst Du auch abschaltet, das empfieht AMD auch bei 2P Systemen, da bringts logischerweise eh nichts. Da hat man dann die vollen 6MB.
Bei 4P überwiegt deutlich der Vorteil :)
Das Teil ist schon praktisch und aufgrund der exklusiven Cache Architektur halt notwenig.
Intel gehts auch nicht besser, die verbraten durch die inklusiv Architekur auch 1MB des L3, da ja auch die Daten der 4x256kB L2 abgelegt werden müssen (Die L1s lass ich mal weg). Bei 32nm soll das ganze dann auf 512kB Cache anwachsen .. und dann auch noch 6 Kerne ... also dann 3MB Verschnitt ... toll.
(Nur nebenbei, es lassen sich bei AMD auch 2 oder gar 4 MB des L3s für den Probefilter reservieren, aber default ist 1 MB, steht irgendwo in nem AMD pdf).
ciao
Alex
Intel gehts auch nicht besser, die verbraten durch die inklusiv Architekur auch 1MB des L3, da ja auch die Daten der 4x256kB L2 abgelegt werden müssen (Die L1s lass ich mal weg).
Das ist so auch korrekt, der L1-inhalt ist schließlich auch in L2. Das ganze hat aber auch große vorteile, wenn ein nehalem-kern einen cache-miss im L3 hat, kann er davon ausgehen dass die benötigten daten nicht in der CPU sind und das ganze aus dem RAM laden.
Mit einer exklusiven architektur musst du nach dem L3-miss erstmal überprüfen ob die daten nicht möglicherweise (verändert) in einem der anderen kerne liegen.
Das ist so auch korrekt, der L1-inhalt ist schließlich auch in L2. Das ganze hat aber auch große vorteile, wenn ein nehalem-kern einen cache-miss im L3 hat, kann er davon ausgehen dass die benötigten daten nicht in der CPU sind und das ganze aus dem RAM laden.
Mit einer exklusiven architektur musst du nach dem L3-miss erstmal überprüfen ob die daten nicht möglicherweise (verändert) in einem der anderen kerne liegen.
Jo dafür gibts ja jetzt den Probe Filter... um den gings ja gerade. Kostet auch MBs, aber bei Intel eben auch, deswegen hatte ich Intel erwähnt, da sich AnarchX anscheinend daran störte, dass L3 vergeudet werden würde. Welcher Ansatz jetzt besser ist ... kA, wird sicherlich auch von den diversen Programmen abhängen.
Wenns z.B. um aufgesplittete Probleme geht, bei der jeder Kern nur an seinem Datenpool ackert, dann seh ich AMD vorne, denn der Probe Filter kann dann klein bleiben, während man bei Intel keine Wahl hat. Da werden die MBs ohne Einflussmöglichkeit verbraten.
ciao
Alex
auch hier bin ich nicht der meinung. Vor allem Ki und andere sachen könnte man da sehr gut in eigene threads auslagern und dann skaliert die sache auch noch mit mehr als 8 threads. vor allem größere maps mit mehr intelligenteren einheiten würde das zugute kommen. Bei den details kann man noch viel weiter gehen als es jetzt der fall ist und die möglichkeiten werden sicherlich genutzt, wenn die rechenleistung (breitflächig) vorhanden wäre.
nebenbei kann man auch andere programme laufen lassen und ggf. könnte man noch einen server hosten etc. Ihr geht immer davon aus, dass nur EINE anwendung davon profitiert und ich sehe da noch bis 32 threads luft im desktop markt. Dadurch kann man einfach den browser und andere programme offen lassen und trotzdem ein spielchen machen. wenn mahrere MT programme laufen dann steigt auch ganz schnell der benötigte bedarf an threads. bisher ist man auch mit der strategie im server- und desktop-bereich die gleichen prozessoren zu verwenden ganz gut gefahren und es profitierten beide seiten.
der i7 wird schon noch seine vorteile zeigen. beim core 2 war es ja auch nicht anders und heutzutage macht der A64 X2 garkeinen stich mehr gegen ihn.
das größte problem ist eben die teure programmierung und der vorhandene codebestand.
Du machst dir das einfach zu leicht. Bei 16 Threads hast du schon einen derartigen Wasserkopf bei der Verteilung und vor allem Synchronisation, dass schon recht viel Rechenleistung vom OS aus dafür verbraten werden muss, diese Threads überhaupt korrekt zu verteilen um sie zeitnah zu rechnen und, vor allem, die ganzen Recheneinheiten überhaupt auszulasten - man hat verdammt viel Leerlauf bei 16 Threads. Grade bei KI wird die Sync derart komplex, dass man die Thread-Anzahl begrenzen muss, um nicht zuviel Verwaltungsoverhead zu erzeugen und Leerstände zu verhindern. 32Threads sind natürlich technisch möglich aber eben eher Ressourcenverschwendung als Notwendigkeit - der Nutzen bleibt einfach auf der Strecke. Der Break-Even liegt wohl bei 16 Threads, darüber wirds unsinnig für Anwendungen die synchronisiert werden müssen wie z.B. Ki.
Awendungen die keiner Synchro bedürfen (z.B. Renderprogramme oder Codierer) laufen dann aber eh dann auf OpenCL o.Ä., also wird klar, dass eine CPU mit mehr als 16 Threads total unsinnig ist im Desktop-Bereich. Man müsste schon ne neue ISA und vollkommen andere Konzepte im PC-Markt umsetzen, um soviele Threads nutzbar zu machen, das wird aber auf absehbare Zeit definitiv nicht passieren, also bleibt die Kernanzahl eben begrenzt.
Die Erhöhung der Thread-Anzahl bringt im x86-Bereich leider so massive Probleme mit, dass man da schon andere Konzepte finden muss um die Effizienz zu steigern. 8 Kerne sind mMn einfach das Optimum mit der derzeitigen CPU-ISA, mehr ist nett, bringt aber so gut wie nichts und 4 werden sicherlich dann eher Minimum sein.
In Zukunft trennen sich evtl. Server und Desktop-Bereiche eher wieder - nein, sie sind schon getrennt. AMD bietet einen Istanbul an und Intel wird einen Beckton anbieten - beides nicht mal im entferntesten Desktop-tauglich, weil soviele Threads im Desktop auf absehbare Zeit ziemlich unsinnig sein. Wahrscheinlich wird AMD auch einen 16-Thread-BD für Server anbieten, aber in den Desktop-Markt wird das Riesending sicherlich eher nicht wandern.
Undertaker
2009-06-10, 15:03:51
Du machst dir das einfach zu leicht. Bei 16 Threads hast du schon einen derartigen Wasserkopf bei der Verteilung und vor allem Synchronisation, dass schon recht viel Rechenleistung vom OS aus dafür verbraten werden muss, diese Threads überhaupt korrekt zu verteilen um sie zeitnah zu rechnen und, vor allem, die ganzen Recheneinheiten überhaupt auszulasten - man hat verdammt viel Leerlauf bei 16 Threads. Grade bei KI wird die Sync derart komplex, dass man die Thread-Anzahl begrenzen muss, um nicht zuviel Verwaltungsoverhead zu erzeugen und Leerstände zu verhindern. 32Threads sind natürlich technisch möglich aber eben eher Ressourcenverschwendung als Notwendigkeit - der Nutzen bleibt einfach auf der Strecke. Der Break-Even liegt wohl bei 16 Threads, darüber wirds unsinnig für Anwendungen die synchronisiert werden müssen wie z.B. Ki.
Woher nimmst du denn gerade die Zahl 16? Ich denke da nur an die schicke Froblins-Demo von ATI, die mit KI-Berechnungen auf der GPU wohl noch weitaus stärker parallelisiert ist...
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.