Test Test: Intel Core i7-980X Extreme Edition

Nein: Wozu der Screen mit 4,3 GHz wenn man den Takt beim benchen nicht halten kann und nur die 4 GHz verwendet?
Und welcher Turbo soll den sich noch zuschalten wenn die Power Control Unit( PCU) die CPU runter drosselt? Sie lief bei dem anderen Test mit lediglich 3,6 GHz obwohl 4 GHz OC eingestellt waren - negativer Turbo? ;)
Cinebench skalioert zwar nicht linear doch bei 4-Kern CPUs ist der Faktor ca. 3,8 fache der 1-Kern Performance also ca. 5% niedriger als bei optimaler Skalierung.
In eurem OC-Test ist @4 GHZ ein plus von 1000 Punkten und bei 6 Kernen ein Plus von 4000 Punkten -> das ist 30% weniger als zu erwarten wäre. Das ist schon ein gravierender Unterschied auf den ihr gar nicht eingeht.

Also entweder ihr schaut beim benchen nicht wo sich die Frequenz der CPU bewegt oder ihr habt das einfach mal verschwiegen dass die Frequenz runter geht wenn die 6 Kerne übertaktet werden. Da ich davon ausging dass bei einem OC bench grundsätzlich die Frequenzen eine Rolle spielen und daher auch beobachtet werden habe ich wohl den falschen Schluß gezogen? dann tut es mir Leid - ich wollte hier keine Absicht unterstellen. Doch es ist nicht das erste mal dass eure Zusammenfassung was anderes sagt als eure eigenen Testergebnisse.

Es sind ja auch die Programmierer von Software Schuld dass ein aktiviertes Hyperthreading zum Absturz führt. Welche dieser Aussagen stimmt denn in der Schlußfolgerung?
Diese:
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.
Oder diese 2 Sätze später:
Mittels msconfig wird aus dem Core i7-980X kurzerhand eine CPU mit nur vier Kernen und insgesamt acht Threads. Und siehe da, mit dieser Konstellation funktioniert das Spiel wie zuvor. Dass man ArmA II ohne Hyper-Threading und damit auch „nur“ mit sechs realen Kernen problemlos betreiben kann, muss an dieser Stelle wohl kaum gesondert erwähnt werden.
heisst das nun das 6 echte Kerne nicht mehr als 4 Threads verwenden? Und 4 Kerne plus 4 Threads sind auch weniger als 4 Threads?
Etwas widersprüchlich würde ich sagen. Oder irreführend möchte ich sagen.
Ergänzung ()

Vielleicht um das kurz klar zu stellen:
Ich will damit nicht sagen dass eure Tests nichts taugen oder dass die 6-Kern CPU von Intel schlecht wäre. Ich finde die Leistung bei Standard Takt recht beeindruckend. Doch finde ich dass man die Limits ruhig auch offen nennen kann und nicht den Eindruck erwecken muss dass hier kein Limit nach oben besteht beim OC - das ist hier nun mal gegeben bei 6 Kernen.
 
@ Volker
Die CPU drosselt. Wenn dann müsste man den Turbo ausschalten um die Werte zu bekommen, die im Test stehen. Das Fazit dazu passt imho nicht.
Also am besten den Turbo bei starkem Übertakten ausschalten und gut ist.

Die beiden Sätze oben sagen nur, dass SMT die Performance senkt. 6 Native Kerne oder 4 native Kerne jedoch nicht, vielleicht unglücklich formuliert.
 
@complication

Wenn der Turbo aus ist scaliert die Cpu mit der spannung extrem gut(rede vom hardcore oc mittels LN2 oder Dice und in gewissen Maß auch Wakü).

Sie scaliert sogar so gut das einige gute OCer(hwbot Wettkämpfer) diese schon mehrfach über den Jordan gejagt haben, weil es scheinbar kein wirkliches Limit beim TAkt gibt...nur halt ein Limit bei der Spannung.

Wenn du dir den i7 920-960 als Gegenbeispiel anschaust scalieren die irgendwann garnicht mehr mir der Spannung und Takt und du musst aufhören zu steigern. Das ist schon ein ziemlicher Fortschritt/Pluspkt für die 32nm Fertigung.

Wegen Limit Post von dir...just for info:)
 
dirky8 schrieb:
Wenn der Turbo aus ist ...
Was ich genau so auch geschrieben habe - man soll keinen Turbo suggerieren der nicht einspringt sondern genau das Gegenteil macht wenn er aktiv ist:
http://www.au-ja.de/review-intel-core-i7-980x-15.phtml
Allerdings sorgte die Power Control Unit (PCU) dafür, dass die gewünschte Taktrate nur dann anlag, wenn nur ein oder maximal zwei Kerne belastet wurden. Kamen weitere Kerne ins Spiel, wurde der Multiplikator bis auf 27 und der Takt auf 3,60 GHz reduziert. Dies zeigt sich auch deutlich bei den Ergebnissen unserer Benchmark-Messungen.
Auch hat sich das skalieren auf den hier gezeigten Benchmark bezogen wo die Taktrate offensichtlich gedrosselt hat und nicht auf die CPU im Allgemeinen.
 
Hatte dich schon verstanden. Denke das es aber sicherlich ein Fehler in der Interpretation der Ergebnisse war. Kann passieren bei der Menge an Informationen und der Kürze der Zeit. Geht mir hin und wieder auch so wenn ich vile Messergebnisse habe bei Projekten und/oder einfahren von neuen Produktionslinien. Kann halt vorkommen und ich denke in Volkers Fall auch kein grosser Patzer(kostet ja kein Geld;)).
 
JanEissfeldt schrieb:
Also von wegen wirtsschaftskrise und so, die Leute kaufen den egal wie teuer. :lol:
Sie schauen eher wie teuer und kaufen sich dann Kopf schüttelnd was anderes :evillol:
 
Schau dir den Gewinn von Intel an und vergleiche ihn mit dem Umsatz von AMD. :evillol:
 
Complication schrieb:
Sie schauen eher wie teuer und kaufen sich dann Kopf schüttelnd was anderes :evillol:
So ist das. Es dürfte generell auch recht wenige Exemplare geben. Intel scheint wohl noch unzureichende 32 nm Kapazitäten zu haben. Und das, was man hat, wird vorrangig für Clarkdale reserviert. Von "Beliebtheit" ist das nun wirklich meilenweit entfernt. Nun ja, es ist halt typischer Fudo Quatsch. Wenn man keine News hat, muss man sich irgendwas zusammenbasteln.
 
dirky8 schrieb:
Sie scaliert sogar so gut das einige gute OCer(hwbot Wettkämpfer) diese schon mehrfach über den Jordan gejagt haben, weil es scheinbar kein wirkliches Limit beim TAkt gibt...nur halt ein Limit bei der Spannung.
Das war allerdings nur bei den ES Samples der fall, bei denen sind schlicht und einfach alle Schutzmechanismen ausgeschaltet. Deshalb sind eben auch einige gestorben.
Die Serienmodelle lassen sich im direkten Vergleich dazu zum großen Teil deutlich schlechter übertakten. Wer keinen ES hat, hat zur AOCM vermutlich relativ schlechte Karten.
 
CHAOSMAYHEMSOAP schrieb:
Schau dir den Gewinn von Intel an und vergleiche ihn mit dem Umsatz von AMD. :evillol:
Ja ich bin sicher dass Intel Aktien langfristig die besseren sind im Gegensatz zu AMD :)
Aber gehört das nicht eher in ein Finanzforum? ;)
 
Wer keinen ES hat, hat zur AOCM vermutlich relativ schlechte Karten.

Ja, aber es mir eh wurscht. Da immer mehr die Schere auseinandergeht zwischen den Leuten die sowas bekommen und den NormalExtremeBenchern. Glücklicherweise gibt es je auch bei hwbot Kategorien. Aber genaues wissen wir am 24.04.
Und du kannst ja auch noch den CaseWeitwurfContest gewinnen;) Aber 2000l lN2 und mehrere 100kg Dice klingen gut. Werde wohl auch kommen wenn es Studi und Arbeit zulässt.
 
Also dies finde ich sehr aufschlussreich bzgl. Hyperthreading:
http://ht4u.net/reviews/2010/intel_corei7_980x/index7.php
Und endlich mal eine Grafik die das vernünftig darstellt und mit dem Mythos der "logischen Kerne" bei Hyperthreading und schlecht programmierter Software bzgl. Mulicore Support aufräumt:
179805

Bereits unsere vorherigen Test haben gezeigt, dass HTT nicht immer einen Vorteil ist. Manch eine Appikation kann mit dem Feature nicht wirklich umgehen, wodurch sich die Werte verschlechtern. Daran hat sich auch bei den Gulftown-Prozessoren nichts geändert. Hinzu kommen Anwendungen, die von der Überzahl an Kernen - sei es real oder fiktiv - nicht profitieren können. So bleibt HTT zwar ein nettes Feature, doch beinhaltet es auch Tücken.

Wenn also in Tests von "schlecht programmierter" Software die rede ist, so meint der Autor tatsächlich "nicht für Intel optimiert". 6 Kerne bei denen Hyperthreading aktiviert wurde ist nicht mal andeutungsweise mit einer 12-Kern CPU zu vergleichen. Rückschlüße die suggerieren dass die Software daran Schuld wäre wenn die CPU abstürzt sind sehr tendenziös.

Vielmehr Sinn würde wohl die Vermutung machen dass der Cache des 6-Kerners mit den zusätzlichen Threads überlastet ist wenn die Threads eine hohe Datenlast und wenig Lücken zum optimieren haben. Dieses Problem ist ja nicht neu bei Hyperthreading und kommt hier wohl verstärkt zum tragen.
Daher halte ich auch dieses Aussage:
Mit Windows 7 hat sich dies jedoch gebessert, Hyper-Threading führt jetzt nicht mehr automatisch zu einem Performanceverlust – von schlecht programmierten Spielen einmal abgesehen. Doch genau eines dieser nicht so optimierten Spiele haben wir uns näher angesehen.
für mehr als fragwürdig.

Je besser die Multicoreunterstützung einer Software, desto weniger nutzen mit Hyperthreading, da es keine Lücken gibt die von der Funktion genutzt werden könnte:
smt-larrabee-p-n-160331-3-png.179811

http://www.tomshardware.de/Core-i7-Nehalem-Architektur,testberichte-240168-5.html
Um dem abzuhelfen, sucht der SMT Anweisungsparallelität in zwei Threads statt nur in einem, mit dem Ziel, unausgenutzte Einheiten so oft wie möglich zu vermeiden. Diese Technik kann sich als sehr effizient erweisen, wenn die beiden Threads klar voneinander getrennte Aufgaben ausführen. 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. Es versteht sich von selbst, dass der SMT in solchen Fällen gar nichts bringt, sondern die Performance sogar noch verschlechtern kann.
 

Anhänge

  • SMT-larrabee,P-N-160331-3.png
    SMT-larrabee,P-N-160331-3.png
    37,8 KB · Aufrufe: 682
Und wie erklärst du dir die Tatsache, daß IBM und Sun ebenfalls auf SMT (z.T. sogar mit mehr als nur 2 Threads pro Core) setzen?
Entweder sind die Programmierer in der Windows Welt einfach nur unfähig oder Intels HT ist nicht so toll wie das Multithreading bei der Konkurrenz.
 
Würden die Probleme vom HT selbst herrühren, gäbe es keine Software, die gut damit skaliert. Da es aber solche Software gibt (Cinema als Paradebeispiel oder Linux als OS), wird es wohl doch an schlecht geschriebenen Programmen liegen.
dirky8 schrieb:
NormalExtremeBenchern
:D
 
CHAOSMAYHEMSOAP schrieb:
Entweder sind die Programmierer in der Windows Welt einfach nur unfähig oder Intels HT ist nicht so toll wie das Multithreading bei der Konkurrenz.
Da triffst du den Nagel auf den Kopf. ;) Ausserdem ist das auch nicht so richtig vergleichbar, da IBM und Sun eine andere ISA benutzen. Hinzu kommt, dass extensives OoO, so wie wir es in aktuellen x86 CPUs finden, SMT schon sehr entgegen wirkt. Bei In-Order Designs, wie dem Atom, macht SMT mehr Sinn.
 
@frankpr
Den grössten Nutzen hat SMT wenn die Threads der nativen Kerne nicht ausgelastet sind. Nun kann man sich natürlich streiten was gut und was schlecht programmiert ist: wenn jeder Takt so viel Daten wie möglich an die CPU überträgt oder wenn im Takt genug Leerräume sind wo SMT Platz hat zum optimieren? Wären keine lücken zum füllen würde SMT gar keinen Sinn machen.

@CHAOSMAYHEMSOAP
IBM schaltet SMT automatisch ab wenn es nichts nützt oder gar bremst:
http://en.wikipedia.org/wiki/Simultaneous_multithreading#Modern_commercial_implementations
IBM's implementation is more sophisticated than the previous ones, because it can assign a different priority to the various threads, is more fine-grained, and the SMT engine can be turned on and off dynamically, to better execute those workloads where an SMT processor would not increase performance. This is IBM's second implementation of generally available hardware multithreading.
dazu sind Intel CPUs nicht in der Lage - also würde ich einfach mal behaupten dass es eine bessere Implementierung ist.
Auch Sun hat eine andere Art der Optimierung gewählt als Intel:
Unlike SMT, where instructions from multiple threads share the issue window each cycle, the processor uses a round robin policy to issue instructions from the next active thread each cycle. This makes it more similar to a barrel processor. Sun Microsystems' Rock processor is different, it has more complex cores that have more than one pipeline.
Nachteil von SMT:
http://en.wikipedia.org/wiki/Simultaneous_multithreading#Disadvantages
Simultaneous multithreading cannot improve performance if any of the shared resources are limiting bottlenecks for the performance. In fact, some applications run slower when simultaneous multithreading is enabled. Critics argue that it is a considerable burden to put on software developers that they have to test whether simultaneous multithreading is good or bad for their application in various situations and insert extra logic to turn it off if it decreases performance. Current operating systems lack convenient API calls for this purpose and for preventing processes with different priority from taking resources from each other.

There is also a security problem with simultaneous multithreading. It has been proven that it is possible for one application to steal a cryptographic key from another application running in the same processor by monitoring its cache use [3].
Das Sicherheitsproblem war mir allerdings auch neu - das ist aber auch etwas was ich in bisher keinem Artikel gelesen hatte.

Hier eine weitere Quelle die näher erklärt wann SMT sogar bremst - allerdings wohl eher bei gut programmierter Software:
http://agner.org/optimize/blog/read.php?i=6&v=t
In these cases, each of the two threads will run at more than half speed, but less than full speed. The total performance is never doubled by hyperthreading, but it may be increased by e.g. 25%. On the other hand, if the performance is limited by any of the shared resources, for example the instruction fetcher, the memory read port, or the multiply unit, then the total performance is not increased by hyperthreading. Actually, in the worst cases the total performance is decreased by hyperthreading because some resources are wasted when the two threads compete for the same resources. A quick google search reveals several examples of applications that run slower with hyperthreading than when hyperthreading is disabled.

Und hier auch die Programmierer Sicht - hat wohl absolut nichts mit gut und schlecht programmieren zu tun sondern mehr mit Zusatzaufwand für Intel SMT Optimierung:
Obviously, it can be quite difficult for a software programmer to predict whether hyperthreading is good or bad for a particular application. The only safe way of answering this question is to test it. Ideally, the programmer should test his or her application on several different microprocessors with several different data sets and with hyperthreading turned on and off. This is a large burden indeed to put on software developers, and very few programmers are willing to spend time and money on testing how hyperthreading affects their application.
 
Ein alter SC Pentium 4 skaliert mit SMT fast so gut wie ein Atom. An IoD liegt es nur bedingt.
 
Zurück
Oben