Archiv verlassen und diese Seite im Standarddesign anzeigen : CMT und SMT sinnvoll kombinierbar? [Split]
Undertaker
2010-09-10, 22:16:19
Split von hier: Wird der neue Bulldozer möglicherweise ein Flop? (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=490608)
Ich denke eher, dass sich CMT und SMT prinzipiell auch durchaus ergänzen könnten: Ersteres stellt ja z.B. im Integerbereich zusätzliche Ressourcen zur Verfügung, während letzteres für eine bessere Auslastung sorgt - zusammengenommen verbände man beide Vorteile miteinander. :)
angenommen ein Modul hätte 2fach SMT, wie hoch würde ein SMT Thread eines integer Core an Leistung bringen? auch wie Nehalem ca. 30%?
Das ist sicherlich nicht der Grund - bis auf AA2 gibt es keinen Fall, wo SMT noch Leistung kostet.
Wer redet denn von Spielen ???
Ich dachte eher an sowas:
My understanding is that SMT is almost always a boon for FP throughput.
Depends on the code. A program that relies heavily on a
well scheduled and cache blocked dense linear algebra
library will often lose performance running more than one
thread per core.http://www.realworldtech.com/forums/index.cfm?action=detail&id=112693&threadid=112460&roomid=2
Sowas solls auch noch geben. In P4 Zeiten gabs viele Firmen, die von HT abrieten, kA inwieweit das jetzt noch bei Nehalem der Fall wäre.
angenommen ein Modul hätte 2fach SMT, wie hoch würde ein SMT Thread eines integer Core an Leistung bringen? auch wie Nehalem ca. 30%?
Vor längere Zeit stand mal irgendwo, dass +20% eigentlich immer wegen der RAM Latenzen drin wären. Das sollte damit das Minimum sein.
Allerdings verbaut AMD nen dicken L2 Cache inkl. aggresiven Prefetchern, ein Trace Cache liegt auch noch in der Luft, dann noch die Spekuliererei ... also sie unternehmen vermutlich alles Erdenkliche um die Piepes zu füllen. Möglich, dass sie dadurch selbst das Minimum auf 10% drücken würden.
In jedem Fall gilt aber, dass SMT den INT Cluster wieder verkomplizieren, und somit wieder Taktspielraum kosten würde.
In der Gesamtkalkulation somit vielleicht negativ.
Das ist alles natürlich nur Spekuliererei - Endabrechnung sehen wir dann wenn das Ding draußen ist, und die ersten IPC Mixe kalkuliert werden. Ich glaub Nehalem liegt maximal bei 1,5-1,7. Wenn Bulldozer bei 1,5 läge, dann wärs schon Spitze ^^
Eventuell spielt v.a. bei nem Hochtaktdesign noch ein weiterer Punkt rein:
SMT lastet ja auch den Kern besser aus, Übertakter berichten dann auch immer von schlechteren OC Werten. Will man bei AMD eventuell auch nicht haben - lieber Blasen in der Pipeline die wie ne Art Microkühlung funktionieren ^^
Ausnahme wären vielleicht nur die Server CPUs, z.B. die aktuellen MCs mit 12 Kernen. Die schieben @2,3 GHz ne ruhige Kugel.
Langfristig wird AMD beim nächsten Shrink wohl auf 32kB L1 gehen. Möglicherweise das letzte Quentchen, dass die IPC anhebt und SMT überflüssig machen würde.
Ein Quadmodul für die LarrabeeNI wäre auch interessant, 4 INT Cluster und 4 FMACs, die zusammen an 512bit rechnen könnten, oder an 4x128bit, oder 2x256 etc. pp ... aber erst mal schauen, was jetzt aus Larrabee wird.
Aber abwarten ... alles hochspekulativ z.Zt.
ciao
Alex
Undertaker
2010-09-10, 23:13:59
Wer redet denn von Spielen ???
Ich dachte eher an sowas:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=112693&threadid=112460&roomid=2
Sowas solls auch noch geben. In P4 Zeiten gabs viele Firmen, die von HT abrieten, kA inwieweit das jetzt noch bei Nehalem der Fall wäre.
Das erwähnte Spiel ist nunmal der einzige noch bekannte Fall, wo SMT Probleme bereitet. Mit dem P4 und SMT unter Windows XP darfst du das nicht vergleichen - unter Win7 bzw. im Firmenbereich auch 2K8 ist das Thema gegessen, SMT wird erst verwendet, wenn alle Kerne bereits genutzt werden - keine Verluste bei der Singlethreadleistung. :) Wenn AMD auch bei BD auf SMT verzichtet ist es entweder bei einem 2-ALU-Design nicht wirklich gewinnbringend, oder aber es fehlten bisher die Ressourcen zur Umsetzung.
Das erwähnte Spiel ist nunmal der einzige noch bekannte Fall, wo SMT Probleme bereitet.
Jo, aber Spiele interessieren nicht, eben weil das mittlerweile erwiesernermaßen wirklich kein Prob. mehr ist ;-)
Wenn das überhaupt hakt, dann nur unter 100% Vollast auf allen Kernen - das schafft kein Spiel.
Mit dem P4 und SMT unter Windows XP darfst du das nicht vergleichen - unter Win7 bzw. im Firmenbereich auch 2K8 ist das Thema gegessen. :)
Ich glaub Dir gerne - aber bitte Link :)
Ich setzt Dir das mal vor die Nase:
Step 2: Processor
All other things being equal, start with the fastest available single-CPU system that fits your budget. Prior to SolidWorks 2006, dual processors had very limited benefits, helping only on a system where you run a lot of applications at the same time. With SolidWorks 2006 and later, many functions in the CAD system have been re-architected to take advantage of multiple processors and dual-core processors. So dual-CPU systems used to be a waste of money for parametric CAD, but that's no longer the case.
In our experience hyper-threading is a waste of performance. It treats a single processor as two, effectively cutting your performance in half for those tasks which cannot be run in parallel. You should disable this feature on your system for better results with SolidWorks.
http://www.capinc.com/pages/support/tips_hardware.cfm
Stand: Zwar immerhin 2008 (gibt noch ne Menge alten Zeugs von 2005, aber das is dann wirklich Asbach). Aber wie auch immer, 2008 war auch noch PräNehalem Ära ... Naja versuch Du mal Dein Glück mit google ;-)
Wenn AMD auch bei BD auf SMT verzichtet ist es entweder bei einem 2-ALU-Design nicht wirklich gewinnbringend, oder aber es fehlten bisher die Ressourcen zur Umsetzung.
Was mir gerade noch einfällt: Die pauschalen 20% von oben galten für nen ganzen Kern, also inkl. FPU. Letztere wird aber bei Bulldozer aber ja sowieso SMT-like geteilt.
Ergo ist es sehr gut möglich, dass der SMT Aufwand allein für die 2 INT Pipes den Nutzen in der Tat nicht wert wäre. Da hat AMD durch die saubere INT <> FPU Aufteilung womöglich einen Vorteil.
Undertaker
2010-09-10, 23:45:06
Wonach googlen, wenn es in der Tat keine Fälle mehr geben sollte? :confused: Wenn ich in Tonnen von Reviews noch nie eine Anwendung unter Win 7 gesehen habe, in der SMT Leistung kostet, und auch sonst bisher niemand ein Beispiel nennen konnte, ist die Lage doch klar, zumindest bis jemand das Gegenteil belegen kann. Wenn du meinst, mal einen problematischen Fall gesehen zu haben, dann immer her damit. :) Aber wie gesagt:
Unter Win7/2k8(r2) wird SMT erst verwendet, wenn alle Kerne bereits genutzt werden.
Aber es mindert halt in ein paar Fällen auch die single-thread Leistung.
-> Kann damit nicht mehr passieren. Wo es Probleme gibt, sind die durch die zu großen Threadzahlen bedingt - das ist dann aber keine SMT-Problematik, sondern würde bei CMT oder echten Kernen gleicher Zahl identisch passieren. Erkennt man ja immer schön daran, wenn man in so einer Anwendung den nur 2/4 Kern/Thread-starken Clarkdale und die SMT-Auswirkungen dort vergleicht.
Ganz abgesehen davon: Selbst wenn es irgendwo doch einen uns bisher unbekannten Fall gäbe, wo SMT mal 5% Leistung kostet - wie gesagt, wir kennen keinen - dann wird das durch die hundertfache Zahl an Fällen mit Gewinnen von 20-30% mehr als aufgewogen. Und abschaltbar ist es im Notfall ja immernoch.
Ergo meine Theorie: Womöglich ist SMT in aktuelle AMD-Designs nicht so trivial zu integrieren. Der Speedup wäre architekturbedingt womöglich bei nur 10 oder 15%, der Flächenbedarf nur wenig geringer. Da steckt man die Manpower zunächst eher in andere und dringendere Baustellen.
Gibt doch Tests die Zeigen das man SMT vernachlässigen kann:
http://www.computerbase.de/artikel/prozessoren/2009/test-intel-core-i5-750-core-i7-860-und-core-i7-870/19/#abschnitt_assassins_creed
boxleitnerb
2010-09-11, 09:45:18
*facepalm*
GPU-Limit...schau doch, wie schön alle beieinander sind :freak:
Das ist sicherlich nicht der Grund - bis auf AA2 gibt es keinen Fall, wo SMT noch Leistung kostet. Und auf so ein popeliges Spiel oder OSs vor Win7 wird man sicherlich keine Rücksicht mehr nehmen müssen. ;)
Imho der wahrscheinlichste Grund gegen SMT ist, dass es bei dem Design mit nur zwei ALUs wohl so schon eine höhere Auslastung gibt und SMT-Gewinne damit deutlich kleiner ausfielen. Ein weiteres ganz reeles Problem sind womöglich auch die Entwicklungsressourcen: Auf einen Schlag SMT und CMT einzuführen, hätte BD womöglich noch weitere Monate verzögert. ;) Vielleicht ja mit nachfolgenden Modellen?
Wie stur kann man eigentlich sein? Ein Fall reicht um zu beweisen das es Leistung kosten kann. Zumal AMD in einem Modul eben keine zwei vollwertigen Kerne verbaut, deshalb würde SMT selbst im Optimalfall weit weniger bringen als bei Intel.
Win7 optimiert das ganze zwar weil nur mehr SMT verwendet wird wenn keine Kerne mehr frei sind, das prinzipielle Problem das man zwei "intensive" Threads (also Threads die die ALUs stark auslasten) nicht parallel durch einen Kern jagen sollte bleibt davon aber unberührt. SMT bringt dann viel wenn man zwei "simple" Threads (die meistens durch load/store limitiert sind) durch einen Kern jagen kann. Da 99% der Spiele kaum vier Threads vernünftig auslasten glaube ich schon das es da durch Win7 kaum mehr zu Problemen kommt.
Wenn die Sache so einfach wäre wie du sie darstellst dann könnte man ja auch problemlos vier oder mehr Threads durch einen Kern jagen, kostet ja nichts. Das ist aber mitnichtern so. Es gibt solche Prozessoren zB den SUN UltraSPARC, dort wird aber auch explizit darauf hingewiesen dass SMT Leistung kosten kann unter den oben angegebenen Bedingungen.
Wonach googlen, wenn es in der Tat keine Fälle mehr geben sollte? :confused: Wenn ich in Tonnen von Reviews noch nie eine Anwendung unter Win 7 gesehen habe, in der SMT Leistung kostet, und auch sonst bisher niemand ein Beispiel nennen konnte, ist die Lage doch klar, zumindest bis jemand das Gegenteil belegen kann.
Schon alleine durch logisches Nachdenken sollte einem klar werden das man durch Software nie Hardwareprobleme beheben kann sondern sie immer nur möglichst gut umgehen kann.
Ergo meine Theorie: Womöglich ist SMT in aktuelle AMD-Designs nicht so trivial zu integrieren. Der Speedup wäre architekturbedingt womöglich bei nur 10 oder 15%, der Flächenbedarf nur wenig geringer. Da steckt man die Manpower zunächst eher in andere und dringendere Baustellen.
Bei Bulldozer wurde nahezu alles umgebaut, was du da mit "aktuellen AMD-Designs" willst weiß ich nicht. Würde es Sinn machen wäre es drinnen ganz einfach.
Wonach googlen, wenn es in der Tat keine Fälle mehr geben sollte? :confused: Bei Spielen ja - bei anderen Sachen - unbekannt.
Wenn ich in Tonnen von Reviews noch nie eine Anwendung unter Win 7 gesehen habe, Wieviele professionellen Anwendungen waren da denn dabei ? Die "Tonnen" hören sich nach dem üblichen cb, PCGH, etc. Einheitsbrei an.
Damit wiederlegst Du weder das SolidWorks Teil hier (ich kürz das Zitat mal ab):
In our experience hyper-threading is a waste of performance.noch solche ollen Kamellen, wo es um das Zusammenspiel mehrerer Programme geht:
With both SQL Server and Citrix Terminal Server installations, HT-enabled motherboards show markedly degraded performance under heavy load. Disabling HT restores expected levels, according to reports from within the IT industry.http://www.zdnet.co.uk/news/processors/2005/11/18/hyperthreading-hurts-server-performance-say-developers-39237341/
Wenn bei Deinen Tonnen auch ein paar Gram Gold in Form von prof. Anwendungsszenarien dabei ist, dann her mit den Links, dann ist der Braten gegessen - ausschließen will ich das ausdrücklich nicht, die Prefetcher sind mittlerweile besser und die Caches größer. Aber ohne belastbares Zahlenmaterial weiss man nichts, weshalb ich skeptisch bleibe.
Ergo meine Theorie: Womöglich ist SMT in aktuelle AMD-Designs nicht so trivial zu integrieren. Der Speedup wäre architekturbedingt womöglich bei nur 10 oder 15%, der Flächenbedarf nur wenig geringer. Da steckt man die Manpower zunächst eher in andere und dringendere Baustellen.Die Theorie ist in Ordnung, ich kürz sie ab: Es bringt nichts, bzw. es wäre den Aufwand nicht wert. 10-15% holt man dann auch durch höheren Takt raus, der mit SMT nicht möglich wäre. Wenn ich mich an die OC Leute erinnere, dann kommt das sogar gut hin.
ciao
Alex
Undertaker
2010-09-11, 11:50:52
Bei Spielen ja - bei anderen Sachen - unbekannt.
Ähm, also mal langsam. Wir stellen nicht eine Theorie auf und sehen sie so lange als nicht widerlegt an, bis jemand das Gegenteil beweisen kann - das ist nämlich schlicht nicht möglich. Andersherum wird ein Schuh daraus: Solange wir keinen Fall kennen, wo es ein Problem gibt, existiert es auch nicht.
Also: Liefere einen Fall, und das Thema ist geklärt. :)
Wieviele professionellen Anwendungen waren da denn dabei ? Die "Tonnen" hören sich nach dem üblichen cb, PCGH, etc. Einheitsbrei an.
Es gibt doch genügend Seiten wie Anandtech, die auch professionelle Anwendungen testen. Da sind die Profite im Regelfall sogar mit Abstand am höchsten.
Es bringt nichts, bzw. es wäre den Aufwand nicht wert. 10-15% holt man dann auch durch höheren Takt raus, der mit SMT nicht möglich wäre. Wenn ich mich an die OC Leute erinnere, dann kommt das sogar gut hin.
Das ist allerdings nicht so ganz korrekt: Ein höherer Takt wird immer ineffizienter sein als eine höhere Auslastung. Soll heißen: Dort, wo mit SMT die Leistung steigt, wäre das Ergebnis ohne SMT mit höherem Takt schlechter. Dafür brauchst du nur in die OC-Foren schauen, SMT kostet im Regelfall etwas um die 5% Maximaltakt - bringt aber in üblichen Belastungstests wie Prime 20%+.
Btw: Wir müssen auch AA2 streichen, auf einem 2-Kerner bringt es Leistung (http://www.computerbase.de/artikel/prozessoren/2010/test-intel-core-i3-530-540-und-core-i5-661/25/#abschnitt_armed_assault_2_arma_ii).
Damit haben wir unter Win7 keinen einzigen Fall mehr. So lange wir also nichts anderes finden - dein Link im letzten Posting ist mit Datum 2005 wieder gegenstandslos - sehe ich das Thema als geklärt. :)
Das ist allerdings nicht so ganz korrekt: Ein höherer Takt wird immer ineffizienter sein als eine höhere Auslastung.
Das kommt ja wohl auf die Architektur und Rahmenbedingungen an.
Ähm, also mal langsam. Wir stellen nicht eine Theorie auf und sehen sie so lange als nicht widerlegt an, bis jemand das Gegenteil beweisen kann - das ist nämlich schlicht nicht möglich. Andersherum wird ein Schuh daraus: Solange wir keinen Fall kennen, wo es ein Problem gibt, existiert es auch nicht.
Also: Liefere einen Fall, und das Thema ist geklärt. :)
Es gibt doch genügend Seiten wie Anandtech, die auch professionelle Anwendungen testen. Da sind die Profite im Regelfall sogar mit Abstand am höchsten.
Das ist allerdings nicht so ganz korrekt: Ein höherer Takt wird immer ineffizienter sein als eine höhere Auslastung. Soll heißen: Dort, wo mit SMT die Leistung steigt, wäre das Ergebnis ohne SMT mit höherem Takt schlechter. Dafür brauchst du nur in die OC-Foren schauen, SMT kostet im Regelfall etwas um die 5% Maximaltakt - bringt aber in üblichen Belastungstests wie Prime 20%+.
Btw: Wir müssen auch AA2 streichen, auf einem 2-Kerner bringt es Leistung (http://www.computerbase.de/artikel/prozessoren/2010/test-intel-core-i3-530-540-und-core-i5-661/25/#abschnitt_armed_assault_2_arma_ii).
Damit haben wir unter Win7 keinen einzigen Fall mehr. So lange wir also nichts anderes finden - dein Link im letzten Posting ist mit Datum 2005 wieder gegenstandslos - sehe ich das Thema als geklärt. :)
So lol, alles ignorieren und einfach immer wieder das gleiche schreiben und schon "sehe ich das Thema als geklärt". ;D
Also: Liefere einen Fall, und das Thema ist geklärt. :)
Sorry aber:
:freak::freak::freak::freak::freak::freak::freak::freak:
Wenn Du mein obiges Posting gelesen hättest, würdest DU 2 Fälle finden.
Falls ich es Dir wegen einer Sehschwäche fett hervorheben oder vielleicht bunt markieren soll - gib Bescheid.
Ansonsten kann ich mich nur wiederholen:
Auch für Moderatoren gilt die goldene Regel: Erst lesen dann schreiben. Ein "verstehen" dazwischen wäre ebenfalls nicht verkehrt. Falls das nicht möglich ist - dann nachfragen, wies gemeint war. Mach Deinen Gesprächspartner bitte den Gefallen und beherzige das, ok ?
Ansonsten sehe ich mich gezwungen bei nem Kollegen nach nem Skript nachzufragen, dass meine alte Ignorliste wieder reaktiviert - es hat so einfach keinen Sinn.
Danke (für den Fall dass Du es mit dem Lesen versuchen solltest)
Alex
Undertaker
2010-09-11, 12:22:17
Wenn Du mein obiges Posting gelesen hättest, würdest DU 2 Fälle finden.
Ich bitte darum. Und ich hoffe, dass du unsere große Überschrift - Windows 7 - dabei nicht vergessen hast. :)
Das kommt ja wohl auf die Architektur und Rahmenbedingungen an.
Eine höhere Auslastung sollte maximal linear in den Verbrauch eingehen, real eher weniger, da auch Leertakte einen gewissen Verbrauch haben. Eine Taktsteigerung + Spannungserhöhung steigert die Leistungsaufnahme in jedem Fall stärker.
(del)
2010-09-11, 13:33:11
Wonach googlen, wenn es in der Tat keine Fälle mehr geben sollte? :confused:Er meinte wahrscheinlich, so wie ich, den Link der aufzeigt, daß P4/XP da noch schlechter agieren als Nehalem/Win7.
Triskaine
2010-09-11, 21:00:49
Also: Liefere einen Fall, und das Thema ist geklärt.
Ein Fall (http://www.anandtech.com/show/3470) mit 10% Verlust durch HT.
Bevor hier jemand nölt das Linpack nur ein Benchmark ist, es existieren im HPC-Bereich viele Anwendungen die ähnliche Kernel mit Matrizenberechenungen verwenden und durch HT an Performance verlieren.
Nicht umsonst vertreibt Intel eine Sechs-Kern Variante von Nehalem-EX, ohne HT, die gerade für den HPC-Bereich gedacht ist.
Durch das Auslesen von Event Countern weiß ich, das (m)ein Phenom I unter Linpack eine durchschnittliche IPC von 2,3 (von Maximal 3) erreicht.
Jedes hinreichend rechenintensive Programm verliert durch HT an Performance, dass das nicht übermäßig häufig der Fall ist, vorallem nicht bei "Mainstream"-Software, zeigt:
1. Das die Extraktion von ILP aus einem Programm genauso von Amdahl's Law limitiert wird, wie die von TLP.
2. Das nur eine kleiner Anteil aller Software, aufgrund bekannter Kosten/Nutzen Problematiken, auf höchstmögliche Performance ausgerichtet ist.
Ob AMD's CMT oder Intels SMT der bessere Ansatz (für Server) ist wird am Ende nur durch den realen Durchsatz bestimmt werden und die dafür aufgewendete Energie.
AMD hat seine Prioritäten gesetzt und die sind nicht auf maximale Singlethread Leistung gerichtet. Wer aber genau das will, kauft sich dann halt Sandy Bridge und zerreißt sich dann in Foren das Maul über AMD's Unfähigkeit.
Botcruscher
2010-09-11, 21:19:43
W7 als Heilsbringer für SMT darzustellen ist auch falsch. Die Verteilung wird zwar besser aber es ändert nichts an prinzipiellen Nachteilen.
Ronny145
2010-09-11, 21:21:31
Ein Fall (http://www.anandtech.com/show/3470) mit 10% Verlust durch HT.
Auch unter Windows 7? Ich glaube Warcraft 3 verliert ebenfalls noch mit SMT Leistung unter Win 7. Den Test dazu gab es in der PCGH.
Undertaker
2010-09-11, 21:43:31
Findest du noch die Ausgabe? :) Das es unter Vista und Vorgänger häufiger Probleme gab, braucht man nicht zu diskutieren - das ist Tatsache.
Ronny145
2010-09-11, 21:46:02
Findest du noch die Ausgabe? :) Das es unter Vista und Vorgänger häufiger Probleme gab, braucht man nicht zu diskutieren - das ist Tatsache.
PCGH 1/2010 Seite 53.
Auch unter Windows 7? Jo, muss so sein, denn Linpack läuft auf allen Kernen Volldampf, da ist der Scheduler egal. Win7 schedult halt erstmal 4 Threads auf 4 einzelne Kerne, das ist toll, wenn man nur 4 oder weniger Threads hat, die mit nem alten Scheduler sonst nur auf 2 bzw. 1 Kernen gelaufen wären - Aber wenn volle 8 Threads laufen, hat das Ganze keinen Effekt.
Linpack geht in die Richtung, was ich schon voher verlinkt hatte:
A program that relies heavily on a
well scheduled and cache blocked dense linear algebra
library will often lose performance running more than one
thread per core.
Zu Warcraft:
Jo, das war mit dem bereits genannten Spiel ne Außnahme: Grund in beiden Fällen: Die Doofies von Programmierer basteln sich selbst ne Threadzuteilung/AffinityMask zusammen, anstatt das dem OS zu überlassen.
Nichts was man SMT ankreiden müßte - nur Dummheit ^^
ciao
Alex
Undertaker
2010-09-11, 22:19:51
Mal ein paar Zahlen dazu:
Kein SMT, 2 Threads: http://www.abload.de/thumb/nosmt28pds.png (http://www.abload.de/image.php?img=nosmt28pds.png)
SMT, 2 Threads: http://www.abload.de/thumb/smt20phk.png (http://www.abload.de/image.php?img=smt20phk.png)
Kein SMT, 4 Threads: http://www.abload.de/thumb/nosmt4aoi6.png (http://www.abload.de/image.php?img=nosmt4aoi6.png)
SMT, 4 Threads: http://www.abload.de/thumb/smt4vovm.png (http://www.abload.de/image.php?img=smt4vovm.png)
Die leicht unterschiedlichen Turbotaktraten vergessen wir mal - was man sieht: Bei 4 Threads ist es egal, ob SMT an ist oder nicht. Bei zwei Threads ist SMT aus ein gutes Stückchen schneller.
Problemlösung: Per Taskmanager die "SMT-Kerne" dem Programm entziehen. Das könnten die Programmierer sogar als billigen Automatismus implementieren, ansonsten muss man sich ein kleines Script schreiben. :)
Bevor ich mir das Ganze näher anschaue wundere ich mich erstmal, wie Du 4 Threads auf nem 2core Prozessor ohne SMT zum Laufen bekommst ... sequentiell ??
Gib mal ein paar Infos, z.B. was Du überhaupt zeigen willst, Zahlen einwerfen kann jeder:
43,55,855,32523, und nicht zu vergessen 24!
;-)
Undertaker
2010-09-11, 22:42:46
Was ist das Problem an 4 Threads auf einem Dualcore ohne SMT? Mein X6 idlet gerade bei 714 Threads. ;)
Die Zahlen sind eigentlich selbsterklärend, bzw. siehe was ich noch dazu geschrieben habe. Mich wundert eigentlich nur, dass bei aktiviertem SMT zwei Threads langsamer sind als 4 Threads, obwohl der Vergleich mit deaktiviertem SMT bei zwei Threads ein besseres Ergebnis zeigt. Das vernachlässigen wir mal, könnte eine simple Messschwankung sein, Differenz zu gering für eine gescheite Interpretation.
Ich muss demnächst nochmal einen etwas längeren Bench fahren...
Nunja, nachdem ein Beispiel gefunden wäre, versuchen wir mal den Bogen zum Thema zu finden:
Selbst wenn es irgendwo doch einen uns bisher unbekannten Fall gäbe, wo SMT mal 5% Leistung kostet [gefunden] dann wird das durch die hundertfache Zahl an Fällen mit Gewinnen von 20-30% mehr als aufgewogen.
Das sehe ich nach wie vor so. Dazu kommt: Das Problem lässt sich schon allein mit dem Taskmanager lösen, per Deaktivierung im BIOS sowieso - das kann es also nicht sein, was gegen den Einsatz in BD spricht. Ich glaube eher an meine bereits erwähnten Theorien hier:
Ergo meine Theorie: Womöglich ist SMT in aktuelle AMD-Designs nicht so trivial zu integrieren. Der Speedup wäre architekturbedingt womöglich bei nur 10 oder 15%, der Flächenbedarf nur wenig geringer. Da steckt man die Manpower zunächst eher in andere und dringendere Baustellen.
Ein Fall (http://www.anandtech.com/show/3470) mit 10% Verlust durch HT.
Bevor hier jemand nölt das Linpack nur ein Benchmark ist, es existieren im HPC-Bereich viele Anwendungen die ähnliche Kernel mit Matrizenberechenungen verwenden und durch HT an Performance verlieren.
Nicht umsonst vertreibt Intel eine Sechs-Kern Variante von Nehalem-EX, ohne HT, die gerade für den HPC-Bereich gedacht ist.
Durch das Auslesen von Event Countern weiß ich, das (m)ein Phenom I unter Linpack eine durchschnittliche IPC von 2,3 (von Maximal 3) erreicht.
Jedes hinreichend rechenintensive Programm verliert durch HT an Performance, dass das nicht übermäßig häufig der Fall ist, vorallem nicht bei "Mainstream"-Software, zeigt:
1. Das die Extraktion von ILP aus einem Programm genauso von Amdahl's Law limitiert wird, wie die von TLP.
2. Das nur eine kleiner Anteil aller Software, aufgrund bekannter Kosten/Nutzen Problematiken, auf höchstmögliche Performance ausgerichtet ist.
Ob AMD's CMT oder Intels SMT der bessere Ansatz (für Server) ist wird am Ende nur durch den realen Durchsatz bestimmt werden und die dafür aufgewendete Energie.
AMD hat seine Prioritäten gesetzt und die sind nicht auf maximale Singlethread Leistung gerichtet. Wer aber genau das will, kauft sich dann halt Sandy Bridge und zerreißt sich dann in Foren das Maul über AMD's Unfähigkeit.
Komm doch nicht mit Fakten, für Undertakter ist die Sache schließlich erledigt. Fakten werden einfach ignoriert. Schon alleine das er sich auf Win7 rausredet beweist das er keine Ahnung hat. Software kann wie schon gesagt niemals Hardweprobleme beheben, sondern sie höchstens so oft als möglich umgehen. Bei rechenintensiven Threads war vollkommen klar das HT natürlich nach wie vor Leistung kostet. Natürlich wird er auch diesen Beitrag wieder ignorieren.
Koshgay
2010-09-12, 08:49:37
Und ich dachte AMD ist der Flop schlechthin :D
Das sehe ich nach wie vor so. Dazu kommt: Das Problem lässt sich schon allein mit dem Taskmanager lösen, per Deaktivierung im BIOS sowieso - das kann es also nicht sein, was gegen den Einsatz in BD spricht.
Natürlich nicht, ist ja auch vollkommen normal das man vor jeder Anwendung die man startet jetzt testet ob SMT Leistung kostet und ggf. den PC für diese Anwendung neu startet und SMT im BIOS deaktiviert. Blöd wird es höchstens bei Server wo mehrere Anwendungen laufen. :ugly:
Auch im Takmanager Threads zuweise ist ja sowas von praxisnah und sicherlich alltäglich. Nein, das kann es also wirklich nicht sein. ;D
Das ist wie immer eine ganz einfach Kosten-Rechnung. Wenn ich schon alle Teile die öfter mal ideln zwischen zwei Kernen share macht SMT keinen Sinn mehr. Der Leistungsgewinn wird selbst in Optimal fällen kaum der Rede Wert sein, Verluste werden weitaus häufiger Auftreten -> deshalb kein SMT.
Das mit Ressourcen zu begründen wo AMD eine wirklich komplett neue Architektur aus dem Boden stampft ist wirkliche hanebüchen.
puntarenas
2010-09-12, 10:15:29
Undertaker argumentiert soweit mein Verständnis reicht schlüssig, dass auch Bulldozer mit seinem CMT-Ansatz noch von SMT (aka Hyperthreading) profitieren könnte und ihr fetzt ihm seitenlang das Spaßargument um die Ohren, dass SMT allgemein nur Probleme macht und häufig Leistung kosten würde. SMT ist übrigens nicht Intel und muss deshalb nicht als Inkarnation des Bösen ausgetrieben werden.
Beispiele für Leistungsverluste durch SMT muss man suchen und es handelt sich offensichtlich um sehr spezielle Software, die heute noch mit SMT verliert. Ein modernes Betriebessystem und ausreichend rechenintensive Threads vorausgesetzt kann man ansonsten die Auslastung der Recheneinheiten entsprechender CPUs erhöhen und dadurch einen Performancegewinn erzielen.
Ich finde die Frage, ob AMD Bulldozers CMT-Design gewinnbringend auch noch mit SMT aufwerten könnte durchaus interessant.
Natürlich nicht, ist ja auch vollkommen normal das man vor jeder Anwendung die man startet jetzt testet ob SMT Leistung kostet und ggf. den PC für diese Anwendung neu startet und SMT im BIOS deaktiviert. Blöd wird es höchstens bei Server wo mehrere Anwendungen laufen. :ugly:
Da offenbar nur sehr spezielle Software betroffen ist, könnten die Entwickler eben dieser Software gezielt Abhilfe schaffen. Ich weiß nicht, ob Windows7 bereits eine Möglichkeit bietet, dem Sheduler solche seltenen Fälle zu signalisieren. Ansonsten wird entweder das kommen oder es werden sich auf Entwicklerseite Designansätze durchsetzen, die dieses seltene Problem erst überhaupt nicht entstehen lassen.
Das mit Ressourcen zu begründen wo AMD eine wirklich komplett neue Architektur aus dem Boden stampft ist wirkliche hanebüchen.
Wenn SMT geeignet wäre, auch das Bulldozer-Design noch weiter aufzuwerten und zwar in einem Verhältnis, das die zusätzlich benötigten Transistoren überkompensiert, dann wäre AMD sicherlich daran interessiert dies auch zu tun. Falls das zutrifft und sie es dennoch unterlassen haben, dann ist naheliegend anzunehmen, dass sie nicht sicher waren dies bereits innerhalb des Entwicklungszeitfensters für Bulldozer erledigen zu können und das ist dann zumindest teilweise ein Ressourcenproblem.
Software kann wie schon gesagt niemals Hardweprobleme beheben, sondern sie höchstens so oft als möglich umgehen.
Software entwickelt sich aber weiter und man kann Unzulänglichkeiten früherer Versionen beheben. Der Windows-Sheduler wurde verbessert und wird auch weiter an aktuelle Hardwareentwicklungen angepasst werden. Die ollen Kamellen wie "Affinity Masks" haben wir doch auch nur der Tatsache zu verdanken, dass Microsoft gelegentlich nicht ganz auf der Höhe der Zeit ist. Dual-Core-Optimizer anyone? Das behob auch kein prinzipielles Hardwareproblem, sondern war ein Workaround um eine Windows-Unzulänglichkeit. Vor kurzem erst konnte man im Linux-Kernel beobachten, wie die Entwickler sich mühten, AMDs Thuban-Turbo ordentlich zu unterstützen, der zündet sehr empfindlich auch nur dann, wenn man die Lastverteilung entsprechend geschickt auslegt. etc. pp.
Bei rechenintensiven Threads war vollkommen klar das HT natürlich nach wie vor Leistung kostet. Natürlich wird er auch diesen Beitrag wieder ignorieren.
Prinzipiell sollte Hyperthreading im schlechtesten Fall einfach keine Vorteile bringen. Ausnahmen mögen die Regel bestätigen, wobei man zuvor noch diejenigen aussortieren sollte, die einfach nur schlecht gefrickelten Code darstellen, bei dem sich dessen Entwickler selbst ein Bein gestellt haben. Was dann übrig bleibt kann man vermutlich getrost als Ausnahmefälle betrachten.
Undertaker argumentiert soweit mein Verständnis reicht schlüssig, dass auch Bulldozer mit seinem CMT-Ansatz noch von SMT (aka Hyperthreading) profitieren könnte und ihr fetzt ihm seitenlang das Spaßargument um die Ohren, dass SMT allgemein nur Probleme macht und häufig Leistung kosten würde. SMT ist übrigens nicht Intel und muss deshalb nicht als Inkarnation des Bösen ausgetrieben werden.
Beispiele für Leistungsverluste durch SMT muss man suchen und es handelt sich offensichtlich um sehr spezielle Software, die heute noch mit SMT verliert. Ein modernes Betriebessystem und ausreichend rechenintensive Threads vorausgesetzt kann man ansonsten die Auslastung der Recheneinheiten entsprechender CPUs erhöhen und dadurch einen Performancegewinn erzielen.
Ich finde die Frage, ob AMD Bulldozers CMT-Design gewinnbringend auch noch mit SMT aufwerten könnte durchaus interessant.
Da offenbar nur sehr spezielle Software betroffen ist, könnten die Entwickler eben dieser Software gezielt Abhilfe schaffen. Ich weiß nicht, ob Windows7 bereits eine Möglichkeit bietet, dem Sheduler solche seltenen Fälle zu signalisieren. Ansonsten wird entweder das kommen oder es werden sich auf Entwicklerseite Designansätze durchsetzen, die dieses seltene Problem erst überhaupt nicht entstehen lassen.
Wenn SMT geeignet wäre, auch das Bulldozer-Design noch weiter aufzuwerten und zwar in einem Verhältnis, das die zusätzlich benötigten Transistoren überkompensiert, dann wäre AMD sicherlich daran interessiert dies auch zu tun. Falls das zutrifft und sie es dennoch unterlassen haben, dann ist naheliegend anzunehmen, dass sie nicht sicher waren dies bereits innerhalb des Entwicklungszeitfensters für Bulldozer erledigen zu können und das ist dann zumindest teilweise ein Ressourcenproblem.
Software entwickelt sich aber weiter und man kann Unzulänglichkeiten früherer Versionen beheben. Der Windows-Sheduler wurde verbessert und wird auch weiter an aktuelle Hardwareentwicklungen angepasst werden. Die ollen Kamellen wie "Affinity Masks" haben wir doch auch nur der Tatsache zu verdanken, dass Microsoft gelegentlich nicht ganz auf der Höhe der Zeit ist. Dual-Core-Optimizer anyone? Das behob auch kein prinzipielles Hardwareproblem, sondern war ein Workaround um eine Windows-Unzulänglichkeit. Vor kurzem erst konnte man im Linux-Kernel beobachten, wie die Entwickler sich mühten, AMDs Thuban-Turbo ordentlich zu unterstützen, der zündet sehr empfindlich auch nur dann, wenn man die Lastverteilung entsprechend geschickt auslegt. etc. pp.
Prinzipiell sollte Hyperthreading im schlechtesten Fall einfach keine Vorteile bringen. Ausnahmen mögen die Regel bestätigen, wobei man zuvor noch diejenigen aussortieren sollte, die einfach nur schlecht gefrickelten Code darstellen, bei dem sich dessen Entwickler selbst ein Bein gestellt haben. Was dann übrig bleibt kann man vermutlich getrost als Ausnahmefälle betrachten.
Schau her puntarenas, man muss natürlich wissen wo SMT Leistung bringt. Es bringt was bei den Decodern die meistens bei weitem nicht voll ausgelastet sind. CMT shared die Decoder zwischen zwei Kernen -> Kein Bedarf. Es bringt was wenn die breit ausgelegten ALUs eines Nehalem nicht voll ausgelastet sind, AMD shared die FPU und verbaut nur 2ALUs pro INT-Einheit. -> Kein Bedarf. Aber es kostet sogar Leistung wenn die Einheiten bereits gut ausgelastet sind weil das hin und herswitchen zwischen zwei Threads ganz einfach Latenzen verursacht, der Cache schneller überläuft, usw.
Mit dem gleichen Argument könnte man sich fragen warum Intel nur zwei Threads pro Kern zulässt und nicht drei oder vier wie der Sun UltraSPARC. Die Antwort ist die selbe wie bei AMD: Es wird öfter Leistung kosten als es Vorteile bringt. Beweisen kann dir das natürlich niemand.
Was man allerdings definitiv sagen kann ist das zusätzlich noch SMT bei Bulldozer mit absoluter Sicherheit deutlich weniger bringen würde wie bei Intel und deutlich öfter Leistung kosten würde wie bei Intel. Die Chance, das SMT bei Bulldozer keinen Sinn macht ist nicht gerade niedrig. Mehr gibt es dazu auch nicht zu sagen, was mich an Undertaker stört ist dieses absolut kindische Behaupten SMT würde ja keine Leistung kosten dank Win7, das wird sogar (zumindest von SUN) öffentlich dokumentiert und auch Intel bietet nicht ohne Grund auch in Servern SMT-lose CPUs aus genau diesem Grund an. Deshalb kann man solche Tatsache nicht einfach wegwischen "es kostet ja keine Leistung und deshalb hat AMD zu wenig Ressourcen" - das ist mit Verlaub lächerlich.
Undertaker
2010-09-12, 10:59:12
Aber es kostet sogar Leistung wenn die Einheiten bereits gut ausgelastet sind weil das hin und herswitchen zwischen zwei Threads ganz einfach Latenzen verursacht, der Cache schneller überläuft, usw.
In so einem Fall sind eigentlich nur die Software-Entwickler gefragt. Wenn wir wirklich mal einen Fall haben, wo die Einheiten nahezu perfekt ausgelastet sind - Linpack z.B., wird nicht umsonst auch als Stabilitätstest verwendet - könnte das Programm auf SMT-CPUs schlicht die Zahl der Threads entsprechend bis auf die reale Kernzahl reduzieren. Stelle ich mir zumindest nicht als unmöglich vor - gerade HPC-Anwendungen werden doch dazu noch ganz speziell auf den genutzten Großrechner hinoptimiert. Dazu kommt die einfach verschwindend geringe Anzahl solcher Beispielfälle. Btw: Alle höherpreisigen Xeons haben SMT. Wäre auch Unsinn, dass wegen einem Leistungsverlust in 1/100 Fällen zu deaktivieren, und auf die Gewinne in allen anderen zu verzichten. Es in einigen günstigen Modellen zu streichen ist simple Produktpolitik, wie der Lynnfield-i5 oder die Pentium-Clarkdales im Desktopbereich. Und eine Deaktivierung per BIOS ist als letzter Rettungsanker immernoch möglich.
Diese Begründung mit bisher 2(?) bekannten Problemfällen (WC3, Linpack - praktische Relevanz für Server -> 0) ist einfach nicht schlüssig. Virtualisierung, Datenbanken, Rendering - das sind alles SMT-Paradedisziplinen und vielfach wichtiger als bisher genannte Negativfälle. Aber:
Mit dem gleichen Argument könnte man sich fragen warum Intel nur zwei Threads pro Kern zulässt und nicht drei oder vier wie der Sun UltraSPARC.
Hiermit lässt sich schon eher eine Begründung aufbauen. Auch SMT kostet Ressourcen, zusätzliche Registersätze sind nicht gratis. Dazu kommt das Gesetz des abnehmenden Ertrages: Steigert SMT in einem Fall die Auslastung von z.B. 60 auf 80%, sind mit zwei weiteren Threads vielleicht nur noch 85-90% möglich - bei vermutlich kaum geringeren Kosten für das Transistorbudget. Je nach Architektur kann ein sweet-spot also bei 4x SMT, vielleicht aber auch schon bei 2x SMT oder ganz ohne SMT liegen - weil die Gewinne einfach zu gering wären. Bei Bulldozer mit nur zwei ALUs vielleicht ganz besonders.
Das ist zumindest eine imho schlüssige Theorie. Das man über SMT erst mit kommenden Nachfolgern nachdenkt, würde ich aber auch nicht einfach vom Tisch wischen. Warum hat AMD statt des Phenom I nicht den Athlon II in 65nm auf den Markt gebracht? Der hat weniger Transistoren und ist bei gleichem Takt schneller... Warum bringt man den Turbomodus erst mit Thuban? Natürlich kostet jeder Fortschritt und jedes zusätzliche Feature Entwicklungsressourcen, die nach Prioritäten gestaffelt abgearbeitet werden müssen. Nur weil SMT nicht zum Launch integriert ist, muss es nicht nutzlos sein. Ganz prinzipiell in Kombination mit CMT imho schon gleich gar nicht.
Bokill
2010-09-12, 11:22:57
Das ist sicherlich nicht der Grund - bis auf AA2 gibt es keinen Fall, wo SMT noch Leistung kostet. ... Auch IBMs Power-Prozessoren und viele SPARCs neueren Datums sind Multicores mit SMT.
Und auch diese können SMT abschalten/deaktivieren, wenn der Nutzer meint, dass SMT in seiner Anwendung Nachteile mit sich bringt.
Andererseits ist faktisch nur noch AMD alleine auf weiter Flur mit seinen mitohne SMT-Ansatz. MIPS-, Power Architektur-, SPARC- und Intels x86 kennen SMT-Designs.
MFG Bobo(2010)
Deinorius
2010-09-12, 11:34:57
Andererseits ist faktisch nur noch AMD alleine auf weiter Flur mit seinen mitohne SMT-Ansatz. MIPS-, Power Architektur-, SPARC- und Intels x86 kennen SMT-Designs.
Wenn du selbst MIPS anführst, solltest du dann auch ARM erwähnen. Die haben auch kein SMT. Und AFAIR ist auch keines für Eagle geplant.
(del)
2010-09-12, 12:46:14
Power... Sparc... Mips... Welche von den CPUs werden noch mit dem Begriff "Workstation" im Hinterkopf erstellt? Recht spezialisierte Anwendungen, ziemlich spezialisierte Betriebssysteme. x86 dagegen ist weiterhin für Wald&Wiesen zuständig. Sie haben sich wahrscheinlich Kosten/Nutzen ausgerechnet und SMT auf die lange Bank geschoben.
Daß AMD die Kernvirtualisierung erstmal da angepackt hat wo es den meisten das meiste bringt liegt auf der Hand. Persönlich schätze ich ein, daß es noch keinen x86-Kernel gibt der einen Bulldozer + SMT merkbar gut bedienen könnte. Genauso wie ich mir denke, daß so ein Bulldozer weniger gewinnen kann als Intel mit HT. Man muß also noch weiter im Modul schon recht kompliziert Transistoren schalten um den Kernel unter die Arme zu greifen.
Bei AMDs Zielgruppen ist das ein Aufwand - um auf einem Modul z.B. 4 Threads laufen zu lassen, wo SMT wahrscheinlich dann weniger als bei Intel bringt - den man wohl erstmal scheut. So ein Trara um an entsprechender Stelle auch Power/Sparc anzugreifen, an welcher man mit Linux/Windows keine müde Chance hat, lohnt sich wohl noch lange nicht.
BlackBirdSR
2010-09-12, 13:34:58
Schau her puntarenas, man muss natürlich wissen wo SMT Leistung bringt. Es bringt was bei den Decodern die meistens bei weitem nicht voll ausgelastet sind. CMT shared die Decoder zwischen zwei Kernen -> Kein Bedarf. Es bringt was wenn die breit ausgelegten ALUs eines Nehalem nicht voll ausgelastet sind, AMD shared die FPU und verbaut nur 2ALUs pro INT-Einheit. -> Kein Bedarf. Aber es kostet sogar Leistung wenn die Einheiten bereits gut ausgelastet sind weil das hin und herswitchen zwischen zwei Threads ganz einfach Latenzen verursacht, der Cache schneller überläuft, usw.
Mit dem gleichen Argument könnte man sich fragen warum Intel nur zwei Threads pro Kern zulässt und nicht drei oder vier wie der Sun UltraSPARC. Die Antwort ist die selbe wie bei AMD: Es wird öfter Leistung kosten als es Vorteile bringt. Beweisen kann dir das natürlich niemand.
Was man allerdings definitiv sagen kann ist das zusätzlich noch SMT bei Bulldozer mit absoluter Sicherheit deutlich weniger bringen würde wie bei Intel und deutlich öfter Leistung kosten würde wie bei Intel. Die Chance, das SMT bei Bulldozer keinen Sinn macht ist nicht gerade niedrig. Mehr gibt es dazu auch nicht zu sagen, was mich an Undertaker stört ist dieses absolut kindische Behaupten SMT würde ja keine Leistung kosten dank Win7, das wird sogar (zumindest von SUN) öffentlich dokumentiert und auch Intel bietet nicht ohne Grund auch in Servern SMT-lose CPUs aus genau diesem Grund an. Deshalb kann man solche Tatsache nicht einfach wegwischen "es kostet ja keine Leistung und deshalb hat AMD zu wenig Ressourcen" - das ist mit Verlaub lächerlich.
Ich glaube, das trifft es doch ganz gut.
Addiert man dazu, die vorhandenen Erfahrungsmängel hinsichtlich SMT, den Abnahemenden Grenzertrag bei mehr als 4 Threads, die Kosten an zusätzlichen Resourcen und Tests - dann hat man schon eine gute Begründung.
Es gibt eben Sachen, da wehrt man sich einfach. Bei AMD war das seit dem Pentium4 eigentlich immer schon SMT. Bei Intel ist es SOI. Das mag nach aussen hin stur aussehen, es gibt aber intern sicher gute Gründe.
Bokill
2010-09-12, 14:01:28
Power... Sparc... Mips... Welche von den CPUs werden noch mit dem Begriff "Workstation" im Hinterkopf erstellt ...Bei MIPS kann man sich in der Tat die Frage stellen, wenn man sich nur die TOP 500 der Supercomputer betrachtet.
Schaut man sich hingegen die Chips von Cavium und RMI an, dann ist der Einwand doch nicht berechtigt. RMI und Cavium haben ausgesprochene Server-Multicores entworfen, die vielfach den Sun Niagaras entsprechen.
Fujitsu will dem noch die Krone aufsetzen mit dem SPARC64 VIIIfx Venus (http://www.engadget.com/2009/05/15/fujitsus-supercomputer-ready-venus-cpu-said-to-be-worlds-fast/) (das geht dann doch wieder Richtung Supercomputer ;)).
Da geht dann auch die z-Serie von IBM unter, wenn man sich nur die Top 100 betrachtet, aber im Enterprise-Segment, also das was Dienstleister für Banken und Versicherungen im Keller stehen haben ... auch da finden sich komplexe Multicores mit SMT-Funktionalität an. Aktuell ists IBMs z196 (http://www.engadget.com/2010/09/06/ibm-claims-worlds-fastest-processor-with-5-2ghz-z196/) Prozessor.
Zugegeben, das ist ein sehr exklusiver Markt. Gemein ist allen diesen Prozessoren, dass sie multiple Arbeitsaufträge haben, womöglich noch mit diversen Virtuellen Maschinen. Das ist das Gegenteil von den bisherigen Arbeitsbereichen der ARM-Prozessoren (klein, kompakt, Einzelgerät für Einzelnutzer).
Aber hier (Enterprise-Webserver) ist eben SMT auch abschaltbar, wenn der Workload sich gegenseitig aus dem Cache kegelt, oder sonst wie sich selbst im Wege steht. IBM geht sogar so weit komplette Einzelkerne im Multicore abzuschalten, wenn dafür ein höherer Takt mehr bringt (oder die Oracle-Lizenz zu teuer ist für multiple CPU-Sockel), der L3-Cache wird dann eben von weniger Prozessorkernen (besser) genutzt.
Was ARM abgeht. Die Prozessorkerne sind vergleichsweise leichtgewichtig. Gut möglich, dass ARM auf SMT verzichtet und lieber einen sandkornkrümelkleinen ARM-Kern ranklatscht. Der Eagle A15 (http://arstechnica.com/business/news/2010/09/arms-eagle-has-landed-meet-the-a15.ars) ist vor kurzem im Sommer 2010 bislang als Chip mit bis zu 8 Kernen und 2,5 GHz mit Virtualisierungstechnik ohne SMT-Funktionalität vorgestellt worden.
Aber was nicht ist, kann ja noch kommen. ECC für die Caches, 64 Bit Genauigkeit der FPU, kohärenter CPU-Interconnect für Multichip/Multisockelsysteme und adressierbarer Speicher bis zu einem Terabyte lassen einen ARM-RISC schon fast richtig "pummelig" werden - schauen wir mal ob ARM auch noch SMT irgendwann für diese speziellen Server-CPUs berücksichtigen wird. Wenns Workloads werden, die schon einem Sun Niagara gut lagen ... warum nicht. Latenzen verstecken kann schon prima sein.
MFG Bobo(2010)
=Floi=
2010-09-12, 14:26:29
geht der scheiß schon wieder an. immer die gleiche leier mit nur EINEM programm. :facepalm:
Was ist wenn mehrere unterschiedliche programme laufen?! Dafür ist imho SMT wirklich gut und dadurch kann man dann den prozessor richtig auslasten und die leistung steigern!
Für das gebotene ist SMT super und man kann auch per software die threads begrenzen, wenn es denn mal wirklich langsamer/schlechter laufen sollte wie mit SMT.
Deinorius
2010-09-12, 15:09:30
Der Eagle A15 (http://arstechnica.com/business/news/2010/09/arms-eagle-has-landed-meet-the-a15.ars) ist vor kurzem im Sommer 2010 bislang als Chip mit bis zu 8 Kernen und 2,5 GHz mit Virtualisierungstechnik ohne SMT-Funktionalität vorgestellt worden.
8 Kerne? Bis jetzt war immer nur von max. 4 die Rede.
8 Kerne? Bis jetzt war immer nur von max. 4 die Rede.
siehe hier unter Wireless Infrastructure [1.5GHz – 2.5 GHz quad-core, octo-core or larger configurations]:
http://www.arm.com/products/processors/cortex-a/cortex-a15.php?tab=Performance
Deinorius
2010-09-12, 15:57:45
Ah, das wäre dann wohl eher unter Klammer zu setzen, aber gut.
In so einem Fall sind eigentlich nur die Software-Entwickler gefragt.
Theoretisch kann man mit Software immer alle möglichen Probleme umschiffen, dass das in der Praxis nicht immer funktioniert ist ebenso bekannt. Du kannst nicht alles Probleme damit wegschieben das hier die Software SMT umgehen soll.
Gasti
2010-09-12, 17:22:38
Theoretisch kann man mit Software immer alle möglichen Probleme umschiffen, dass das in der Praxis nicht immer funktioniert ist ebenso bekannt. Du kannst nicht alles Probleme damit wegschieben das hier die Software SMT umgehen soll.
Dann muss eben der Betreiber des Rechners SMT in diesen Einzelfällen abschalten.
Aber deswegen SMT nicht grundsätzlich nicht zu nutzen, weil 0.1% der Software damit langsamer läuft ist ganz sicher nicht ratsam.
Eine Kombination von CMT und SMT macht keinen Sinn. Dann doch lieber noch einen 3. Int Core mit nochmals 12,5% mehr Transistoren als <b>2x 5% (also 10%)</b> mehr für SMT für beide Cores.
180% + SMT (bis zu 20%) = 170- 216% (selbst manche Multicore Software wird durch SMT gebremst)
180% + 90% = 270%
Bei nur 2,5% mehr Fläche ca. 65%- 100% mehr Performance.
Vor allem würden "nur" 3. Thread die Shared Units (L2 etc.) sich teilen müssen, im Gegensatz zu 4 Threads.
Das ist doch das "Revolutionäre", das man für 12,5% fast die Leistung eines DualCores bekommt. Was will ich dann mit -10 bis 20% wenn ich 5%-8% mehr Transistoren investieren muss.
SMT sieht im Taskmanager schön aus, aber seit DualCores so verbreitet sind ist der Mehrwert sehr gering.
Wenn CMT das hält was es verspricht, wird Intel wahrscheinlich in Zukunft auch von SMT abkommen. Ich bin sehr gespannt ob es das hält was es verspricht ;-)
(del)
2010-09-12, 22:13:59
Zugegeben, das ist ein sehr exklusiver Markt.Und da wird oft noch code aus den 80ern gemanagt ;) Da ist es einfach mit SMT schöne Blumentöpfe sammeln. Zwischen "Workstation" und "Superkomputer" hätte ich aber noch "Server" im Angebot ;)
@=Floi=
Der Scheiß? Es ist scheißegal wieviele Programme laufen. Hier geht es entweder um Threads oder single threaded Prozesse und es ist scheißegal zu welchem Programm sie gehören.
also wenn die 80% von CMT stimmen sind 3 oder 4 integer pro Modul sinnvoller als SMT, wir werden es sehen.
Auch IBMs Power-Prozessoren und viele SPARCs neueren Datums sind Multicores mit SMT.
Und auch diese können SMT abschalten/deaktivieren, wenn der Nutzer meint, dass SMT in seiner Anwendung Nachteile mit sich bringt.
Andererseits ist faktisch nur noch AMD alleine auf weiter Flur mit seinen mitohne SMT-Ansatz. MIPS-, Power Architektur-, SPARC- und Intels x86 kennen SMT-Designs.
MFG Bobo(2010)
Na ja, wenn man genüngen Threads mit Ausführungseinheiten bieten kann auf absehbare Zeit, warum dann noch ne Krücke wie SMT verwenden? SMT gibts es ja nur deshalb, weil Platz auf dem Die teuer ist... jetzt wird aber mit Ausführungseinheiten langsam lukrativer als ohne Ausführungseinheiten bei SMT... Wie Dresdenboy ja auch schon in seinem P3DNow-Artikel schrieb liegt der Verdacht nahe, dass AMD seit der Fertigstellung des K7 an einer ClusterMT-Architektur arbeitet. Es ist nur nie dazu gekommen, sei es aus Kosten- oder Performancegründen. Also hat man das alte Design einfach weiterverwendet. Nun ist es endlich soweit. Wenn AMD sich seit 2000 mit "CMT" beschäftigt, warum hätte AMD sich mit SMT beschäftigen sollen? Hätte damals, als die langfristigen Planungen entstanden, auch niemand für Möglich gehalten, dass sich diese Architektur bis 2011 verzögern würde ;). Nun ist es einfach so: AMD hat sich nie mit SMT beschäftigt und bringt endlich "CMT" stattdessen.
SMT war auch nie AMDs Problem. Man ist immer gut ohne gefahren, bis zum Core2 und dieser hatte ironischerweise kein SMT ;). Erst bei Nehalem wird das Thema wieder aktuell und jetzt kontert man ja auch endlich.
Ich halte es für unsinnig SMT und CMT zu kombinieren, das Frontend des BD ist schon fett genug. Das würde den Effizienzrahmen bei Weitem sprengen, da bin ich mir sicher.
Nun ist es einfach so: AMD hat sich nie mit SMT beschäftigt und bringt endlich "CMT" stattdessen.
SMT war auch nie AMDs Problem.
Naja - das klingt jetzt so, als wären das 2 grundverschiedene Sachen.
Aber wenn man mal den Artikel bei Arstechnica liest (Mir gefallen da ein paar Zahlen nicht, aber der Type hat deswegen sicherlich trotzdem ne gewisse Fachkompetenz), dann ist CMT eher der große Bruder von SMT.
Der Kollege schreibt dort:
AMD's way of breaking the execution unit bottleneck described above is to just replicate the integer execution hardware so that there's one set of integer units per thread. Conventional SMT designs only replicate the storage parts of the processor so that there's, say, one register file per thread; Bulldozer takes it to the next level by replicating the integer units, so that there's one register file and one complete set of integer units per thread.
When you boil it down, the replicated integer hardware is really the main difference between Bulldozer and a conventional two-way SMT design. So Bulldozer isn't "dual-core" in any real sense—it's more like a 1.5-core design, whereas a conventional SMT processor core is really a 1.2-core design.
http://arstechnica.com/business/news/2010/08/evolution-not-revolution-a-look-at-amds-bulldozer.ars
AMD hätte sicherlich SMT integrieren können - im Vergleich zu CMT ist das nach obigem Zitat das kleinere Problem. Sie habens es stattdessen aber halt gleich richtig gemacht und auch die Pipes und L1D Caches dupliziert, um Cache Trashes und andere schlechte Seiteneffekte von SMT zu eliminieren. CMT ist quasi SMT++ ;-)
SMT zusätzlich CMT beim BD Design macht keinen Sinn, da stimme ich dem Gast von vorheriger Seite zu. Mit CMT werden die Decoder schon doppelt genutzt, die FPU auch. Bleiben einzig und allein noch die 2 INT Pipes, die man durch SMT besser nutzen könnte, aber das macht bei ner Spitzen IPC um 1,5, die AMD angepeilt haben dürfte und den kleinen L1D Caches keinen Sinn. Außerdem wären die Decoder und die FPU dann 4fach belastet und das Design durch die doppelten Registersätze wieder komplexer - insgesamt sicherlich ein schlechter Tauschhandel. Man würde sich für etwas bessere Multithreadleistung (ich schätze mal so 5-10%) zuviel Nachteile aufhalsen.
MMn ist BDs CMT Design sehr gut ausbalanciert, ich denke sie haben die richtigen Kompromisse für gute single und multithread Leistung gefunden.
SMT ist mit hoher Wahrscheinlichkeit der größere Designaufwand. Vor allem die Verifikation ist sehr schwer, weil man dauernd aufpassen muss, dass sich die zwei Treads im komplexen Out-Of-Order-Teil der CPU nicht gegenseitig den State verändern. Alles was bei Bulldozer gemeinsam benutzt wird ist In-Order.
Das es "einfach" zu integrieren wäre halte ich für eine maßlose Übertreibung. Bulldozer braucht es aber trotzdem nicht.
SMT ist mit hoher Wahrscheinlichkeit der größere Designaufwand. Vor allem die Verifikation ist sehr schwer, weil man dauernd aufpassen muss, dass sich die zwei Treads im komplexen Out-Of-Order-Teil der CPU nicht gegenseitig den State verändern.
Hmm wie sicher bist Du Dir da, dass das bei SMT nicht auch verdoppelt ist ?Der Kollege schrieb oben doch:
Conventional SMT designs only replicate the storage parts of the processor so that there's, say, one register file per thread
Ok, der Scheduler fällt da nicht darunter, aber was soll da der eine Thread beim anderen ändern ? Dafür gibts doch thread identifiers/Tags.
In der alten SMT Einführung auf RWT steht:
The difficult task of tracking computational results for instructions from separate threads issuing and executing simultaneously is a natural fit with register renaming schemes currently used to work around false register based data dependencies between instructions and support recovery from speculated instruction execution. The problem of selecting instructions from a group of active hardware threads for SMT issue and execution has a relatively simple heuristic solution that provides robust performance over a wide range of workloads with varying degrees of ILP and TLP.http://www.realworldtech.com/page.cfm?ArticleID=RWT122600000000&p=5
Hört sich nicht gerade kompliziert an. Ist das bei x86/intel anders ? Testen muss man das natürlich - aber das muss man bei CMT auch ^^
Alles was bei Bulldozer gemeinsam benutzt wird ist In-Order.Die FPU ? ;)
Das es "einfach" zu integrieren wäre halte ich für eine maßlose Übertreibung.
Immer diese Brutaloformulierungen ... hätte es nicht auch ein mehr sachlicheres "...halte ich für übertrieben" getan ?
Bulldozer braucht es aber trotzdem nicht.
Jo :)
ciao
Alex
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.