Ergebnisse: Leistungsaufnahme

...und in seinem unterirdischen Atom-Segment, wo das Hyper-Threading dem User die teils pissige Performance in erträgliche Regionen hebt.

Mal eine ganz dämliche Frage, weil ich gerade keine Lust habe nachzugooglen:

Haben AMD-Prozis eigentlich was Vergleichbares, was nur anders heißt?

Nein, AMD hat sowas wie Hyper-Treading nicht.

In guten ~ 3 Jahren kommt dieselbe Leistung von Intels aktuellem Einsteigerchip.

Bis zu einem gewissen Zeitpunkt war es so, dass die Software nach Hardware gehungert hat. Heutzutage ist es in den aller meisten Anwendungen umgekehrt. (Spiele mal ausgenommen)

Ich fand das Hyperthreading der Intel-Prozessoren schon immer toll und bin angenehm überrascht, dass selbst bei 6 physikalischen Kernen noch teils deutliche Geschwindigkeitssteigerungen durch HT möglich sind.
Nur die erhöhte Leistungsaufnahme bei eingeschaltetem HT ist nicht so schön. Wie kommt dies? Eigentlich sollte die Leistungsaufnahme durch HT geringer als der Rechenleistungszuwachs ansteigen, aber wahrscheinlich sind zur Verwaltung des Ganzen eine Menge Transistoren nötig...

ähm...?!? irgendwie erschließt sich mir der Sinn dieses "Tests" und vor allem des Fazits nicht wirklich...
Natürlich bringt mir ein Hexacore, bzw. 12 virtuelle Cores nur etwas, wenn ich auch entsprechende Software einsetze, die auch wirklich alles nutzt, was zur Verfügung steht an an Kernen.
Und wie kann ich bitte bei nem knapp 1000€ teuren Prozessor auf die Idee kommen, ihn für "normale" Desktopanwendungen zu benutzen und dann HT abzuschalten, da meine Programme eh nicht alle Kerne ausnutzen würden... ???

Technische Funktionen sind doch eine Einladung sie Ein- und Auszuschalten Mag in der Praxis keinen Sinn ergeben, aber in einem Test gehört das rein. Woher sollte man sonst wissen, wie die Leistungsaufnahme reagiert, welche Software darauf ausgelegt ist und was oder wie viel die Funktionen überhaupt bewirken

Ich kann mich noch an den Pentium 4 erinnern, da gab es zu HT nicht mal richtige Software oder Tests, auch liefen einige Video-Anwendungen ohne HT schneller.

seitdem tomshardware von Media XY übernommen wurde, hab ich mir angewöhnt nur noch die Fazits zu lesen... aber jetzt werd ich nicht mal aus dem schlauf *rofl :-/

-f ;-)

"da zahlreiche Anwendungen mit bis zu acht Kernen ansprechend skalieren"

Leider skalieren die meisten Anwendungen, die ich ständig nutze, nichtmal auf meinem Quad-Core gescheit.

wer sich eine zur zeit knapp 1000€ CPU Leisten kann achtet garantiert nicht auf den Stromverbrauch :-)

Das ist Unfug!

Die langen Pipelines ergeben sich aus der Architektur, die auf hohen Takt optimiert wurde!
Es gibt einen direkten Zusammenhang zwischen Pipeline-Länge und dem maximalen Takt. => Höherer Takt = längere Pipelines. Kurze Pipelines = niedrigerer Takt.
Das ist Bestandteil jeder Vorlesung "Rechnerstrukturen" (oder ähnliche).

Lange Pipelines brauchen allerdings auch viele Rechenzyklen, um geleert zu werden. Daher (unter anderem) war der P4 sehr ineffizient. HyperThreading hat das "optimiert", in dem die nach wie vor langen Pipelines besser ausgelastet wurden. Bekannter Maßen klappte das allerdings nicht immer optimal. So einige Programme liefen mit HT langsamer, viele zeigten keine nennenswerten Unterschiede und einige wurden sogar, wie gewünscht, schneller.

Es ist aber nicht so, wie im Artikel beschrieben! Durch höheren Takt steigt nicht die Auslastung einer Pipeline. Ganz im Gegenteil.

Richtig wäre der Zusammenhang: Für den hohen Takt wurden lange Pipelines konstruiert, deren Auslastung problematisch/schlecht war. Um dieses Problem in den Griff zu bekommen wurde HT eingeführt, was in der damaligen Form aber nur teilweise Verbesserungen brachte.


Was auch gern vergessen wird: Das erste HT aus P4-Zeiten war nur der Vorfahre des heutigen. Es wurde überarbeitet und arbeitet heute effizienter als damals. Ob das nun an einer grundsätzlichen Veränderung am HT liegt oder daran, daß die zu Grunde liegende CPU-Architektur komplett unterschiedlich arbeitet, könnte höchstens Intel beantworten. Von Intel selbst habe ich auf jeden Fall gelesen, daß das HyperThreading der Core i7 (und nachfolgen) CPUs weiterhin die gleiche Aufgabe erfüllen soll, jedoch anders als das HyperThreading der P4s arbeiten soll.


Naja, HT ist HT. Ob da nun etwas überarbeitet wurde ist vielleicht nicht entscheidend, aber zumindest der Quatsch mit den Pipelines könnte korrigiert (oder am besten ersatzlos gestrichen) werden.


---------

Ich bitte um eine Erklärung für den Text auf Seite 9 unter dem Graphen zu "Efficency Run - Total Watt hours"


In dem Graphen ist aber der Vierkerner ohne HT ganz unten mit dem längsten Balken dargestellt und somit der höchsten aufgenommenen Leistung (Core i7-975 3.33 GHz HT off -> 57.4 Wh), während der Sechskerner ohne HT 46.4 Wh und mit HT 46.9 Wh aufgenommen hat.

Ist die Grafik komplett falsch oder sollte es im Text nun nur heißen: "Unter Verwendung des Sechs-Kern-Prozessors..."?


---------

@Mindhack:
Du hast Recht. Da sieht man mal, wie weit die Benchmark-Welt von der Realität des durchschnittsusers inzwischen entfernt ist.
Natürlich kann man Filme oder Raytraycing-Aufgaben wunderbar auf vielen Kernen erledigen lassen. Natürlich gibt es Schachprogramme, die so hervorragend skalieren. Es gibt aber eben auch die andere Software. Einfach diejenige, die "Single-Threaded" läuft.
Da hat es mich beim ersten Artikel über diese CPU auch gewundert, daß einer der Tests, die einfach zeigten, daß nicht jede Software mit der Kernzahl skaliert als Zusatztext sinngemäß bekam: "Dieses Programm hat hier vielleicht den letzten Auftritt in der Benchmarksuite, da es nicht vernünftig skaliert."

Gerade soetwas sollte man durchaus weiterhin testen. Man lässt nunmal nicht den ganzen Tag nur multithreaded-Tasks und optimierte Benchmarks laufen.
Während Dual-Cores auch bei single-threaded Anwendungen einen sehr großen Vorteil brachten (wird ein Kern durch ein Programm blockiert, ist noch ein zweiter Kern für die Hintergrundtasks verfügbar -> Das System bleibt sehr häufig also weiterhin ansprechbar und reagiert flott), ist der Spürbare Vorteile bei einem Quadcore bereits geringer und muß regelrecht nachgemessen werden.
Ja, inzwischen sind viele Programme auf dem Vormarsch, die auch mehr als einen Kern auslasten können... Aber bei steigender Kern-Zahl wird der Unterschied immer geringer.

Das nennt sich Amdahl's law.
Hier eine Abbildung wie die Skalierung mit der Anzahl der Kerne verläuft:
http://software.Intel.com/file/6036

Wir kommen gerade mal in den Bereich zwischen 4 und 8 - noch skaliert alles, was darauf ausgelegt ist, recht ordentlich. Das hört ganz schnell wieder auf. Zumal fast kein Programm, außer vielleicht speziell dafür gedachte Benchmarks und ganz außergewöhnliche Spezialanwendungen, beliebig gut parallelisierbar sind.

Bevor wir Rechner mit 128 vollwertigen CPU-Kernen sehen werden, wird es wohl Rechner mit unterschiedlichen Spezialkernen, also z.B. DSPs, geben, die in ihren Einsatzgebieten ein Vielfaches schneller und deutlich effizienter arbeiten, als jeder x86er. Dann gibt es vermutlich auf jeder "CPU" ein paar Vektor-Recheneinheiten und auch diverse andere spezialisierte Kerne, die je nach Aufgabe eigene Codeschnipsel bearbeiten. Man muß sich dann nur von dem heutigen CPU-Konzept verabschieden, wobei bereits heute spezielle Einheiten integriert sind: FPU oder eben auch die neue AES-Engine. Das sind sozusagen nur die ersten Vorboten.
"Viel hilft viel" stimmt eben nicht so ganz... Bis man den typischen Mediamarkt-Käufer, der damals bei "Kaufen Sie ECHTE 3 GHz!" feuchte Augen bekommen hat und der nun blind der Kernzahl hinterherrennt klargemacht hat, daß es nicht nur auf die Anzahl, sondern auf die Art der Kerne ankommt, werden noch ein paar Jahre vergehen.
Würde mich nicht wundern, wenn dann sehr einfallsreiche Zählmethoden für die CPU-Kerne Einzug halten. Die Marketingexperten werden heute vermutlich schon unruhig, wenn sie daran denken, daß jede kleine Recheneinheit als spararater Kern gezählt werden könnte...

Mal ganz davon abgesehen, was dieser Test einzig und alleine aufzeigt ist: DASS die meisten Software-Devs, es immer noch nicht verstanden haben, Ihre Produkte an die CPU/OS dementsprechend anzupassen. Die Vorgaben von Intel diesbezüglich sind eindeutig, seit nun mehr als 6 Jahre bekannt und auch deffiniert. Stellt man als Entwickler, seine Programmiersprache, meist aus Kostengründen, nicht um, um so auf die Paralellisierung sowie Hyperthreating einzugehen, können natürlich auch keine Produkte entstehen, die diese Technik effizient nutzen.!!

Wenn ich z.B. sehe das ein 7-Zip-Packer, kostenlos!, super mit MultiCPU als auch prefekt mit Hyperthreating skalliert und ein kommerzieles Produkt wie WinRAR, dass nicht mal ansatzweise gebacken bekommt, ist doch für mich klar was Sache ist.

Jeder der diesen Test hier anschaut und ein wenig technisches Verständniss in Bezug zu dieser Materie besitzt oder sich mal mit MultiCPU und Hyperthreaing beschäftigt hat oder auch selber soft-proggt/entwickelt, weiss genau woran es liegt.!!

Vom Prinzip her lässt sich bis zu 99% aller Softwareprodukte paralellisieren, wenn der/die Entwickler die Zeit und Gedult für diese Umstellung bekommen, aber nur WENN!. Viele Hersteller wollen es einfach nicht kapieren und alles unötig lange rauszögern.

Multi/Paralell-CPUs usw usw sind die Zukunft und dem entsprechend muss man die Weitsicht besitzen, in diese zu investieren. Schliessendlich sieht man hier in diesem Test nur genau dass.!!

Würden diese Programme alle richtig entwickelt und umgestellt, würde man hier in diesem Test, sehen dass es sich lohnt, sofern die Entwickler es auch richtig umsetzen. Somit hat man vielleicht einen marginal wenig höheren Stromverbrauch, dafür aber viel weniger CPU-Zeit, weil sich das ganze nur in der Gesamtheit aller benutzten Programme in verbindung mit den benutzen CPUs und OS wiederspiegeln kann.!!
Daher muss dann die wirkliche Einsparung von/in Zeit und Watt gerechnet werden, die die CPU normalerweise ohne Paralellisierung und Hyperthreating, verbraten würde.!! Und dass ist sehr sehr viel mehr, ganz zu schweigen davon, wieviel weniger die CPUs dadurch weniger rechnen könnten, weil sie viel mehr ausgelastet sind. Dass fehlt bei diesem Vergleich vollkommen.!!

Nun sag noch einer, dass stimmt nicht? Dann geh mal bitte bei Intel auf ne Schulung dann lernst es vielleicht noch...

MfG PWX

Verwechselst Du da vielleicht WinRAR und WinZIP? AFAIK ist WinRAR seit geraumer Zeit, zumindest in der 64bit-Version, auch auf mehrere Kerne optimiert... oder vertue ich mich da nun grundsätzlich? Lasse mich gern korrigieren.



Das kann ich so nicht stehen lassen. Das klingt so, als wenn jede Software auf einem N-Kern-Prozessor durch Anpassung des Codes auch um ein vielfaches schneller werden könnte.
Das ist falsch. Ja, man kann bestimmt in einigen Programmen einiges parallelisieren, insgesamt ist dies jedoch immer nur ein Teil des Codes. Sprich: Es gibt immer Teile im Code, die nicht parallelisierbar sind, was nicht daran liegt, daß die Programmierer zu schlecht wären, sondern schlichtweg daran, daß das Problem nicht aufgespaltet werden kann. Beispiele hierfür sind alle iterativen Vorgänge und einfache Vergleiche (a=b, ab). Zudem frisst das Thread-Management auch wiederum etwas Leistung, so daß bei vielen kleineren Programmen es tatsächlich sein kann, daß man insgesamt single-threaded besser fährt.

Das soll aber nicht heißen, daß ich es toll finden würde, daß so viel single-threaded programmiert wird! Um Gotten Willen, nein! Gerade bei komplexeren Programmen, auch gern Computerspielen, finde ich es teilweise schlimm, daß selbst heute noch single-threaded gearbeitet wird, wobei mit steigender Komplexität der Software auch immer mehr Raum für Parallelisierungen geschaffen wird. Natürlich skaliert das dann nicht linear mit der Kernzahl, aber viele Programme könnten deutlich besser laufen und die Hardware besser nutzen.

Und zu Intel und den Schulungen:
http://en.wikipedia.org/wiki/Amdahl%27s_law

Amdahl's law besagt, daß auch sehr gut parallelisierender Code ab einer gewissen Kern-Zahl nicht mehr, oder zumindest nicht mehr nennenswert skaliert. Das Original-Dokument habe ich vor Jahren bei Intel gefunden. Inzwischen ist es bei Wikipedia "eingetragen", da ist der Links also brauchtbar.
In der oberen Grafik kannst Du die Skalierung sehen. Die rote Linie dürfte grob dem entsprechen, was man bei "gewöhnlicher, gut parallelisierbarer Software" erwarten darf. 90% oder gar 95% parallelisierbarer Code klingt für mich nach den Anwendungen wie Raytracing, Wettersimulationen und die Anwendungen, für die bisher Supercomputer eingesetzt werden.
Bei diesem Graphen muß man sich jedoch auch vor Augen halten, daß es ein idealisiertes Modell ist, bei dem noch einige Latenzen außer Acht gelassen wurden.

Parallelisierung: Ja, natürlich! Soweit wie möglich und sinnvoll einsetzbar. Aber Wunder vollbringt das noch lange nicht und wenn die Kernzahlen weiterhin so steigen wie in den letzten paar Jahren, dann wird sich ganz schnell eine Enttäuschung breit machen. Spätestens ab 32 Kernen verpufft die Leistung nämlich, selbst wenn man 90% parallelisierbaren Code hat. Selbst von 8 zu 16 Kernen ist der Leistungszuwachs bereits minimal.

Gerade deswegen wird es in Zukunft spezialisierte Kerne geben und nicht mehr, wie heute, einfach nur x86er Kerne. Die einzelnen Kerne können dann in ihrem Spezialgebiet die Leistung vervielfachen und somit die Gesamtrechenleistung der CPU deutlich steigern - stärker, als es mit der doppelten Anzahl an Rechenkernen möglich wäre.
DSPs, Vektorrechenkerne und sonstige Spielereien werden also Einzug halten. Wenn man dann acht x86er Kerne und eine Hand voll Zusatzkerne zur Verfügung hat, dürfte die tatsächlich verfügbare Rechenleistung deutlich über derjenigen liegen, die eine 16-kern-CPU bereitstellen könnte.

Als Beispiel nehme ich da gerne die neue AES-Engine in dern Intel-CPUs. Das ist im Grunde schon eine solche kleine zusätzliche Recheneinheit, die ein Vielfaches der Geschwindigkeit herausholt, die ein gesamter x86er sonst schafft. Das ist die Zukunft.