Test Test: Intel Core i7-980X Extreme Edition

[Complication]

Ich denke man sollte als Fazit zusammenfassen, dass eine CPU die Abstürzt bei einer Anwendung wenn eines der meist beworbenen Features aktiviert ist definitiv keine 980,- € Wert ist.

Ich würde das einen gravierenden Hardware-Fehler nennen, ähnlich dem C1E Bug bei den Phenom II CPUs von AMD vor dem C3 Stepping. Aber vor allem wirkt das für mich wie ein Architektur Problem das nicht weiter nach oben skalierbar ist, zumindest wenn SMT aktiv sein soll.

Ergänzung (20. März 2010)

bzgl. Atom:

The Intel Atom is a small low-power processor which is used in small netbook computers and embedded applications. It has two cores capable of running two threads each. The execution units of the Atom are much smaller than the i7. It sounds like a weird idea to share the already meager execution units between two threads. The rationale is that the Atom lacks the out-of-order capabilities of the bigger processors. When the execution unit is waiting for an uncached memory operand or some other long-latency event, it would have nothing else to do in the meantime unless there was a second thread it could work on.

Die langen Latenzen bei in-order-execution geben die Räume für SMT Optimierung.

 

[y33H@]

Wo hast du das mit den Abstürzen her?

 

[Complication]

Na aus diesem Test über den wir uns hier gerade unterhalten:
https://www.computerbase.de/2010-03...extreme-edition/4/#abschnitt_zu_viele_threads

Damit war klar, dass dieses Spiel nicht auf Hyper-Threading allergisch reagiert, sondern auf zu viele Threads. Mehr als vier Threads werfen das Spiel aus der Bahn, die Performance sinkt. Behält man dies im Hinterkopf, wird klar, dass mit dem „Gulftown“ quasi der Angstgegner des Spiels am Start ist. Und es kam, was kommen musste: das Spiel versagt bei sechs Kernen mit einem Crash kurz nach dem Start den Dienst.

Das hat mich ja erst so verwundert dass ich mich auf die Suche nach einer logischeren Erklärung gemacht habe als die unlogische Schlußfolgerung das Spiel wäre schlecht programmiert.
Edit: und das würde sich nur bei Intel-CPUs mit SMT auswirken.

 

[frankpr]

Schon interessant, wie man sich ein Fazit hinbiegen kann.
Aus dem Text geht eindeutig hervor, daß das Problem nicht bei der CPU, sondern beim schlampig programmierten Spiel liegt. Sonst würde die überwiegende Anzahl der Softwaretitel nicht anstandslos laufen.

 

[y33H@]

@ Complication

Und dann ist natürlich die CPU schuld Auf Ideen kommen manche ...

 

[Complication]

Aus welchem Text geht das hervor?

 

[y33H@]

Aus deinem? Eine Software kann schließlich schlecht einen "gravierenden Hardware-Fehler" haben ...

Ich würde das einen gravierenden Hardware-Fehler nennen

 

[Complication]

Ja aber wenn du meinen Text liest würde ich sagen der Hardwarefehler ist in der CPU und nicht in allen Softwareprodukten zu suchen die nicht SMT optimiert sind.

 

[Konti]

Womöglich ist beides wahr:
- Manche Software ist einfach schlecht programmiert und führt mit SMT zu Abstürzen.
- SMT könnte wahrscheinlich noch in der Hinsicht optimiert werden, selbst zu erkennen, wann es nicht funktioniert.

Grundsätzlich ist SMT aber schon ne tolle Sache.

 

[Hancock]

Dass was wegen SMP langsamer läuft, liegt an der halbherzigen Umsetzung der Parallelisierung in den Spielen.
Wenn man z.B. 2 Threads hat, die auf einem 2C4T Prozessor laufen, der Thread Scheduler diese Threads aber auf C1T1 und C1T2 legt, dann wirds natürlich langsamer. Mit deaktiviertem SMT wird dadurch natürlich der Scheduler gezwungen, die Threads auf die verschiedenen Kerne zu legen.
In Windows 7 hat man versucht, dieses Problem zu beheben, was teilweise funtkioniert, aber nur, wenn die Threads gleichmäßig die Auslastung verursachen, also immer die 2 gleichen mit voller Last. Bei einem Spiel ist das aber nicht immer so -> teilweise wieder auf den falschen Kernen.

 

[Complication]

Dass was wegen SMP langsamer läuft, liegt an der halbherzigen Umsetzung der Parallelisierung in den Spielen.

Das glaube ich nicht. Das hat weder mit halbherzig zu tun noch mit schlecht programmiert. Denn offensichtlich kommt Hyperthreading von Intel nicht klar mit OpenMP:
http://de.wikipedia.org/wiki/OpenMP

OpenMP (Open Multi-Processing) ist eine seit 1997 gemeinschaftlich von verschiedenen Hardware- und Compilerherstellern entwickelte Programmierschnittstelle. Der Standard dient zur Shared-Memory-Programmierung in C/C++/Fortran auf Multiprozessor-Computern.

Das betrifft weitaus mehr Software als nur Spiele:
IPP Crypto Sample Performance for OpenSSL too Slow on Hyper-Threading Systems

Intel HT is most effective when each thread that is sharing an HT-enabled core is performing different types of operations and processor resources on the core are under-utilized. The threaded AES functions in the Intel IPP library execute at high efficiency, consuming most of the available processor resources and performing identical operations on each thread. Thus, these multi-threaded functions generally do not fare well if they are allocated to run side-by-side on a single HT core. It is better to have these threads run on separate cores.

Hier schreibt Intel selber dass Hyperthreading unter hoher CPU Last nicht gut funktioniert wenn 2 stark belastete Threads auf den selben Kern zu greifen.

Eine Software die gut parallelisiert programmiert ist, die optimiert schon den Datenfluss so dass möglichst wenig Lücken in den Takten zu finden sind bevor überhaupt SMT ins Spiel kommt -> Die Last steigt pro Kern.
Eine schlecht programmierte Software lässt viele Lücken im Takt wo das SMT Performance optimieren kann.
Spezielle Armed Assault hat eine hohe und dichte Parallelität in den Threads wegen der grossen Anzahl an KIs die verwendet werden.

Je mehr gleiche Daten in den Parallelen Threads desto schlechter für SMT.
Je besser eine Software parallelisiert desto mehr gleiche Daten in den Threads.

Auf Multicore optimierte Software "sortiert"die Daten schon sehr gut, so dass sie nicht noch einmal durch SMT "sortiert" werden - beides zusammen bringt keinen Vorteil. Viele Köche verderben den Brei - den Schluß dann zu ziehen dass dort wo SMT nicht greift die Software schlecht programmiert ist, ist genau das Gegenteil von dem was stattfindet.
Je älter ein Spiel und je weniger auf PC optimiert (Konsolen Portierungen) desto mehr nutzen hat SMT. Zukünftige Software wird immer besser für Multicore Systeme optimiert sein so dass der Nutzen von SMT noch weniger werden wird als er jetzt schon ist.

 

[Hancock]

Und was willste sagen, sagen wir, eine Software, die jeden Kern maximal nutzt, läuft drauf, einmal mit, einmal ohne HT, es wird genau gleich schnell sein (Overhead durch das OS ausgenommen).
Spiele haben aber nicht einfach mal ca. 100 parallele Aufgaben, sondern vielleicht 10. Dadurch kann man nur auf "wenig" Kerne optimieren.

Thus, these multi-threaded functions generally do not fare well if they are allocated to run side-by-side on a single HT core. It is better to have these threads run on separate cores.

-> Wenn zu wenig Threads da sind, und diese ungünstig verteilt werden, sinkt die Performance.

 

[Complication]

Das sag ja nicht ich sonder das wird in den Artikeln die ich verlinkt habe beschrieben.
Der Verwaltungsaufwand von SMT kann dazu führen dass die Performance sinkt.

Wenn das Englische nicht nachvollziehbar ist so kann man das hier auch in Deutsch nachlesen - zwar nicht so tief ins Detail doch deutlich genug um zu verstehen dass Software nicht "schlecht programmiert" sein muss um Probleme mit SMT zu haben wie es Intel implementiert. Auch geht daraus hervor dass die Probleme grösser werden je mehr Threads miteinander um den Zugriff auf den Cache konkurrieren:
http://www.tomshardware.de/Core-i7-Nehalem-Architektur,testberichte-240168-5.html

Hingegen würden z. B. zwei intensive Rechenthreads den Druck auf diese Recheneinheiten nur noch erhöhen und dabei auch noch um den Zugang zum Cache miteinander konkurrieren.

Dies scheint mir der Fall gewesen zu sein im Test als 6 Kerne plus 6 zusätzliche Threads bei ArmA 2 zum Absturz geführt hat.

Offensichtlich wird hier "Nicht für Nehalem optimiert" gleich gesetzt mit "schlecht programmiert" - das ist schlicht falsch. Man würde auch nicht Dirt2 als schlecht programmiert bezeichnen weil es kein PhysX hat oder Batman AA weil es kein Tessellation hat:
http://www.tomshardware.de/Core-i7-Nehalem-Architektur,testberichte-240168-6.html

Die Programmierer sollten nur sehr genau aufpassen, da auf dem Nehalem nicht alle Threads gleich sind! Um diese harte Nuss zu knacken, liefert Intel einen Weg, eben diese genaue Topologie des Prozessors zu bestimmen (Anzahl der physischen und logischen Prozessoren). So können die Programmierer das Affinitätssystem der Betriebssysteme nutzen, um jeden Thread einem Prozessor zuzuordnen. Man kann davon ausgehen, dass das für Videospiele kein Problem darstellen würde, da die Programmierer aufgrund des Funktionsmodus ähnlich dem Xenon (der Prozessor der Xbox 360) bereits länger so arbeiten, aber im Gegensatz zu Konsolen, wo die Programmierer einen Zugang von sehr niedrigem Niveau haben, wäre es auf einem PC immer der Ablaufplaner der Threads des Betriebssystems, der das letzte Wort hätte.

 

[Hancock]

ArmA stürtzt wohl ab, wenn es zu viele Kerne hat, wg. Deadlock oder interner Programmierfehler. Wie bei GTA IV, dass nur lief, wenn man es erst auf 1 Kern legte und dann nach dem Starten wieder alle aktivierte.

Das mit der Cache ist halt ein Problem, dass man überall hat, lass mal aufm Quad 4 mal SuperPI laufen. Eig sollte es gleich lang dauern (ist ja Single Threaded) aber es wird langsamer -> Cache. Dadurch sinkt natürlich bei dem OpenSSL die Performance, durch den guten Code wirds aufm Kern nicht schneller, wird aber durch die Cache langsamer -> insgesamt langsamer, also zwei gute Sachen, die in der Kombination auch mal zum schlechten führen können.

 

[Complication]

ArmA stürtzt wohl ab, wenn es zu viele Kerne hat, wg. Deadlock oder interner Programmierfehler.

Das habe ich nun mehrfach hier im Thread gelesen - gibt es auch eine Quelle für diese Vermutung?

Und Viele Threads sind etwas völlig anderes als viele Kerne. Lies doch mal wenigstens einen der Links die ich hier gepostet habe, damit zumindest das Gefühl einer Diskussion mit Fakten entstehen kann.

 

[gruffi]

Ein alter SC Pentium 4 skaliert mit SMT fast so gut wie ein Atom. An IoD liegt es nur bedingt.

Nun ja, "fast" ist doch stark übertrieben. Ausserdem hatte Netburst eine elendig lange Pipeline. Das ist mit aktuellen x86 CPUs überhaupt nicht vergleichbar.

Offensichtlich wird hier "Nicht für Nehalem optimiert" gleich gesetzt mit "schlecht programmiert" - das ist schlicht falsch.

Stimme dir da vollkommen zu. Entwickler arbeiten weitestgehend unabhängig von der Hardware. Für Parallelisierung stehen dabei Threads zur Verfügung. Und wenn das Betriebssystem es nicht schafft, diese vernünftig zu verteilen und die CPU dann nicht gut läuft, dann ist das Problem nicht nur bei der Software zu suchen.
SMT mag ja für diverse Anwendungsfälle ganz nett und relativ einfach zu implementieren sein. Es ist aber kein Heiliger Gral. Es ist wohl so ziemlich die ineffektivste und anfälligste Hardware-Threading Technologie, die es momentan gibt. Da verwundert es nicht, warum AMD und ARM das vor langer Zeit schon zu den Akten gelegt haben. Und bei anderen sind die Nachteile genauso unverkennbar. So ist IBMs 4-fach SMT im Power6 auch eher kontraproduktiv, wenn es um HPC geht. Da erhoffe ich mir deutlich mehr von CMT.

 

[y33H@]

Nun ja, "fast" ist doch stark übertrieben.

Im Mittel +40% und ein Atom +50%. Das kommt schon hin bei aktuellen Spielen - täusch die da mal nicht.

 

[Hancock]

@gruffi:
Bei Bulldozer soll aber wieder SMT kommen ...

Ich hab kein ArmA 2, was passiert aber, wenn jemand das Game mal Suspended startet auf 8 Kerne legt und dann Resumed?
Oder was passiert, wenn man SMT an macht und dann die Kerne per msconfig auf 8 begrenzt, läuft es dann noch? (m.W. ja) Hat jemand mal die Threadverteilung auf die Cores ausgelesen? Wahrscheinlich haben die da rumgefrickelt, wodurch es mit mehr Kernen nicht mehr will.

Und noch was, ich hab die Links gelesen und auch verstanden. Die sind ja nicht so kompliziert.

 

[gruffi]

Im Mittel +40% und ein Atom +50%.

40% oder 50% was? Märchensteuer? Wenn ich mich richtig entsinne, waren das beim P4 durchschnittlich 10%, bei Atom kann man durchaus von 20% durchschnittlich sprechen. Intel selbst gibt als maximalen Boost für SMT aktuell 30-35% an. Aber auch das ist eher die Ausnahme als die Regel. Ein Beispiel dafür wäre POV-Ray.

Bei Bulldozer soll aber wieder SMT kommen ...

Nein, kommt nicht. Und schon gar nicht wieder. AMD hatte noch nie eine CPU mit SMT und das wird zumindest für die Bulldozer Generationen genauso zutreffen. Bulldozer basiert auf dem bereits erwähnten CMT. Ähnliches hatte Sun schon beim Rock. Allerdings war das vielmehr ein Hybrid aus CMT und SMT.

 

[Complication]

Ich hab kein ArmA 2, was passiert aber, wenn jemand das Game mal Suspended startet auf 8 Kerne legt und dann Resumed?
Oder was passiert, wenn man SMT an macht und dann die Kerne per msconfig auf 8 begrenzt, läuft es dann noch? (m.W. ja) Hat jemand mal die Threadverteilung auf die Cores ausgelesen? Wahrscheinlich haben die da rumgefrickelt, wodurch es mit mehr Kernen nicht mehr will.

Und noch was, ich hab die Links gelesen und auch verstanden. Die sind ja nicht so kompliziert.

Na wieso fragst du dann immer wieder Sachen die schon längst hier im Thread beantwortet oder in dem Test stehen?
Die Antwort auf die msconfig und 8 Kerne Begrenzung:
https://www.computerbase.de/forum/t...x-extreme-edition.705213/page-11#post-7555524