Benchmarkergebnisse eines Haswell-Prozessors aufgetaucht

[Mick_Foley]

Das ist der Fluch, wenn man ~500 Anschläge die Minute blind auf der Tastatur hämmern kann
Wo andere eben nur zwei drei Zeilen schaffen, schaff ich deutlich mehr. Das spiegelt sich auch in den postings wieder.

Angeber! Wobei ich nichts gegen ausführliche und inhalstvolle Posts habe...

 

[dochurt]

Um mal einen Vergleich zu wagen...
Was nutzen mir zwei Kaffeemaschinen, die doppelt so viel Kaffee zur selben Zeit kochen können, wenn ich nur eine Kanne benötige?

Es gibt Kannen, da bräuchte man schon zwei Maschinen für

 

[G3cko]

SMT kann aber auch zum Nachteil werden. Dann hast du 100 - 20 = 80^^ Ich muss immer an die Benchmarks aus 2004?! denken und das sich nix geändert hat. Die duzenden Postings wie man HT deaktivieren kann. Dann lieber ohne und Geld sparen.

Aber egal wie man es dreht und wendet. Das Problem bleibt bei AMD die IPC und die Verlustleistung. Letzteres bedingt durch den Fertigungsrückstand wohl nicht so einfach zu lösen. Wenn man zumindest den Idle-Verbrauch deutlich verbessert und die IPC steigert, sehe ich hier AMD vor Intel.
Warum? Weil Intel es seit 2007 (4 Cores für ca 200Euro) nicht schafft mehr Kerne im Mainstream anzubieten. Mir ist auch egal ob sie die IPC stetig steigern, weil es das vorher auch gab, neben den Plus an Kernen.

Und wenn ich an die Konsolenports der Zukunft denke, dann werden das 8 Threads mit relativ geringer IPC sein. (8 Cores ~2GHz) Und mehr Kerne sind immer besser, besonders für OS und was da noch so im Hintergrund läuft.

Oder für PhysX welches bei den Konsolen über die CPU läuft. Wer jetzt nicht eine High-End Grafikkarte von Nvidia überteuert kaufen möchte.

Eigentlich war es klar, dass AMD nicht die Mittel wie Intel hat eine neue Architketur wie Bulldozer perfekt in den Markt zu bringen. Interessant wird was man mit Steamroller nun draus macht.

 

[unl34shed]

Nein, das sicher nicht...
Nur anhand aktueller Umsetzungen lässt sich ein dezenter Nachteil erkennen.

Das ist somit extrem Betrachtungsabhängig. 60+60 sind in Summe zwar genau so 120 wie beispielsweise 100+20. Nur besteht der gravierende Nachteil, eben genau mindestens zwei Threads zu benötigen. Wärend die 100+20 Version mit nur einem den deutlich besseren Job machen kann. Dafür bringt die zwei Threadbelastung in Summe aber weniger, weil SMT eben nur weniger Performance absolut dazugewinnt.

Du kannst aber nicht anhand der aktuellen Situation (verschiedene Fertigungsprozesse, Trigate, verschiedene Prozessoren, ...) CMT und HTT vergleichen. Eigentlich müssten es 100+80 (vllt. auch nur 80+70 wegen dem Mehrverbrauch) zu 100+20.

Aber egal wie man es dreht und wendet. Das Problem bleibt bei AMD die IPC und die Verlustleistung. Letzteres bedingt durch den Fertigungsrückstand wohl nicht so einfach zu lösen. Wenn man zumindest den Idle-Verbrauch deutlich verbessert und die IPC steigert, sehe ich hier AMD vor Intel.

Idle-Verbrauch ist doch auf Augenhöhe.

Und wenn ich an die Konsolenports der Zukunft denke, dann werden das 8 Threads mit relativ geringer IPC sein. (8 Cores ~2GHz) Und mehr Kerne sind immer besser, besonders für OS und was da noch so im Hintergrund läuft.

Eigentlich ist ein riesen großer, schneller Kern meist besser, aber da IPC und Takt irgendwann ausgeschöpft bzw. die Steigerung ineffizient wird, müssen halt mehr Kerne her. Ob parallel oder seriell gerechnet wird ist meist egal, solange das Ergebnis stimmt. Mehrere Kerne dürften nur bei Echtzeit Systemen wichtig sein, wo mehrere zeitkritische Prozesse parallel laufen.

Oder für PhysX welches bei den Konsolen über die CPU läuft. Wer jetzt nicht eine High-End Grafikkarte von Nvidia überteuert kaufen möchte.

PhysX dürfte sich in Konsolen nicht durchsetzen, da es properitärer Misst ist und vor allem da nur noch AMD-GPUs verbaut werden. Da dürfte sich eher Havok durchsetzten und die arbeiten AFAIK mit AMD zusammen und müssten auch GPGPU können.

 

[Undertaker 1]

Du kannst aber nicht anhand der aktuellen Situation (verschiedene Fertigungsprozesse, Trigate, verschiedene Prozessoren, ...) CMT und HTT vergleichen. Eigentlich müssten es 100+80 (vllt. auch nur 80+70 wegen dem Mehrverbrauch) zu 100+20.

Bei gleichem Energie- und Flächenbudget wirst du bei einem CMT-Ansatz immer schwächere Einzelkerne als bei einem SMT-Ansatz haben, ganz einfach weil der Flächen- und Energiebedarf der 2. Int-Einheit gedeckt werden muss.

 

[G3cko]

Idle-Verbrauch ist doch auf Augenhöhe.

Zur Zeit stimmt das ja. Haswell wird aber auf 22nm setzen und den Schwerpunkt auf der Leistungsaufnahme haben.
Pilldriver wird wahrscheinlich auf mehr Kerne setzen und auf 28nm.

Wäre zu wünschen wenn es Idle so bleibt. Komplettes OC-System im Idle unter 50Watt wäre nice. Volllast ist mir egal.

PhysX dürfte sich in Konsolen nicht durchsetzen, da es properitärer Misst ist und vor allem da nur noch AMD-GPUs verbaut werden. Da dürfte sich eher Havok durchsetzten und die arbeiten AFAIK mit AMD zusammen und müssten auch GPGPU können.

Bist du dir da sicher?
NVIDIA Newsroom - Releases - NVIDIA Announces PhysX and APEX Support for Sony Computer Entertainment's PlayStation 4 - NVIDIA Newsroom

Obwohl nVidia innerhalb dieser Konsolengeneration keinen einzigen "Design-Win" erringen konnte, wird man wenigstens mit der PhysX-Technologie (erneut) präsent sein: So hat nVidia bekanntgegeben, daß die kommende Sony PS4 nVidias PhysX unterstützen wird. Im Fall der PS4 und ihrer AMD-Grafiklösung wird PhysX auf der PS4 dann allerdings rein über die Rechenleistung der CPU laufen, was besonders PhysX-lastige Szenen eher ausschließt. Mittels CPU-beschleunigtem PhysX ist nVidia im übrigen schon auf der Playstation 3, der Xbox 360 sowie der Wii präsent (wahrscheinlich auch der Wii U), insofern ist diese Meldung keine große Aufregung wert. Interessanter wäre natürlich, wenn PhysX auch auf dem AMD-Grafikchip der PS4 nutzbar wäre, aber dafür müsste nVidia über seinen eigenen Schatten springen, was wohl nicht passieren wird.

 

[boxleitnerb]

PhysX@CPU ist nicht proprietär.

 

[unl34shed]

@Undertaker1:
Ich sag ja nichts gegenteiliges, deswegen ja die 80+70 in der Klammer
Singlethreaded könnte man die Kerne theoretisch per powergate abschalten, mit ein paar anderen Nachteilen...
Bleibt nur noch das Flechenproblem, wobei sich hier die Frage stellt, ob man nicht die 12% (laut AMD) für die mehr Leistung drauf packt.

Aber trotzdem bleibt es dabei: 32nm Bulldozer ist ein anderes paar schuhe als ein 22nm core-iX und deswegen kann man nicht anhand dieser Implementierungen auf die Effizienz der beiden Designs schließen.

@PhysX:
Ok, das ist mir neu, dass sie es für die Konsolen pushen. Haben aber auch keine große Alternative außer das ganze AMD zugänglich zu machen (was sie nie machen wegen). Und auf der CPU läuft das ganze aber langsamer als auf einer GPU.

 

[Mick_Foley]

@PhysX:
Ok, das ist mir neu, dass sie es für die Konsolen pushen. Haben aber auch keine große Alternative außer das ganze AMD zugänglich zu machen (was sie nie machen wegen). Und auf der CPU läuft das ganze aber langsamer als auf einer GPU.

Was meinst du wohl warum die neuen Konsolen acht Kerne haben, die nicht auf die Bulldozer-Architektur basieren. Da sollten wohl durch aus ein zwei Kerne nur für den Spaß zur Verfügung stehen.

 

[unl34shed]

richtig, das wird auf einem Prozessor mit ähnlicher Pro-Takt-Leistung wie BD aber nur 2GHz ab gehen wie Schmitts Katze

 

[Mick_Foley]

richtig, das wird auf einem Prozessor mit ähnlicher Pro-Takt-Leistung wie BD aber nur 2GHz ab gehen wie Schmitts Katze

Nach der Logik sollte man um PS4 und Xbox 720 generell einen großen Bogen machen. Du vergisst, dass die neuen Quasi-PCs kein BS ala Windows mit dem dazu gehörigen Gepäck mit sich rumschleppen und mir wäre neu, dass Physixy über die CPU schon mal an mehrer Kerne gebunden war, die nur dieses ausgeführt haben. Unterschätze nicht die Möglichkeiten eines einheitliches Systems und dem damit verbundenen Optimierungs-Potenzial.

 

[G3cko]

Physikberechnung lässt sich hervorragend parallelisieren. Deshalb eignet sich eine GPU ja auch so gut dafür. Der Haken ist nur, - Nvidia möchte Grafikkarten verkaufen.

Nvidia bremst PhysX auf der CPU aus [Update]

Man wird schon Wege finden die Hardwareverkäufe im PC-Bereich aufrecht zu erhalten ohne den Aufwand für Entwickler großartig zu erhöhen. Klappt doch mit Tesslation auch hervorragend, nicht? Auf dem 2Ghz 8 Kerner dann super Physik und auf dem PC braucht man eine High-End Graka.

 

[mr.dude]

Nutzlos würde ich SMT nun nicht nennen

Ich schrieb ja auch meist nutzlos im Client-Markt. Oder siehst du grosse Diskrepanzen im Alltag zwischen i5 und i7 oder i3 mit und ohne HTT?

Mir persönlich aus Anwendungssicht nutzt ein CMT Modul nix, wenn bei halber Auslastung auch nur halbe Leistung bei rum kommt, wärend die Konkurenz bei halber Auslastung (Core + SMT) deutlich mehr umsetzen kann.

Wann hat Intel HTT eingeführt? 2001? Wann hat AMD CMT eingeführt? 10 Jahre später? Netburst hatte zu Beginn auch noch genügend Probleme mit der Technik. Bitte bewerte CMT nicht anhand der aktuellen Bulldozer Implementierung. Da gibt's noch so einige Kinderkrankheiten, im gesamten Design. Warte mal noch die eine oder andere Generation ab. Das CMT-Design steht erst am Anfang der Entwicklung. Man wird auch singlethreaded noch gut zulegen. Ich denke, du wirst schon noch die Vorteile von CMT zu sehen bekommen. Bei halber Auslastung ähnliche Performance, bei voller Auslastung aber mehr. Das ist die Zielsetzung. Übrigens, falls du meinst, dass bei einem Thread die Hälfte der Einheiten des Bulldozer Moduls brach liegt, dann liegst du falsch. Man kann die Arbeitsweise sehr flexibel je nach Workload auslegen. Steamroller bekommt zB eine zweite Decoder-/Dispatcher-Einheit, die aber auch für den selben Thread arbeiten kann. Auch könnten beide Integer-Cluster für den selben Thread arbeiten, Stichwort SpMT. AMD hat da einiges an Patenten in der Schublade. Bei Intel und speziell Haswell frage ich mich allerdings, ob die Rechnung langfristig aufgeht. Es ist mMn keine Lösung, das Backend einfach immer weiter zu verbreitern. Das macht die Anbindung immer komplexer und komplizierter und kann Probleme verursachen, zB geringere Taktbarkeit. Bulldozers CMT sollte auch problemlos auf 3 oder 4 logische Prozessoren mit guter Skalierung erweiterbar sein. Vielleicht ist die Jaguar CU mit ihren vier Kernen schon sowas wie ein Vorbote. Zwar noch nicht auf Ebene der Pipeline, aber zumindest an einem gemeinsamen L2 bzw L2-interface. Sicherlich spannend, was da Automatisierungstools in Zukunft noch hergeben. Das sieht bei HTT eher weniger praktikabel aus. Sicherlich könnte man auch das auf 3-fach oder 4-fach aufbohren. Nur sind die Gewinne degressiver.

Um mal einen Vergleich zu wagen...
Was nutzen mir zwei Kaffeemaschinen, die doppelt so viel Kaffee zur selben Zeit kochen können, wenn ich nur eine Kanne benötige?

Dann schaltest du eben nur eine Kaffeemaschine ein und hast auch nur eine Kanne. Wo ist das Problem?

Zur Zeit stimmt das ja. Haswell wird aber auf 22nm setzen und den Schwerpunkt auf der Leistungsaufnahme haben.
Pilldriver wird wahrscheinlich auf mehr Kerne setzen und auf 28nm.

Ivy Bridge setzt bereits auf 22nm, falls dir das entgangen sein sollte. "Pilldriver" nennt sich übrigens Piledriver und ist bereits auf dem Markt. Du meinst vermutlich den Nachfolger Steamroller, der in Q4 in Form von Kaveri erscheinen soll. Idle ist aber sowieso schon ziemlich niedrig. 1-2 W fallen bei gängigen Desktopsystemen kaum noch ins Gewicht. Das fällt quasi unter Messungenauigkeit. Bei Haswell geht's bei den verbesserten Stromsparmechanismen eher um mobile Geräte. Vermutlich will man Haswell auch für Tablets & Co nutzen. Da können dann auch mW entscheidend sein. Jaguar zeigt schon recht gut, was da auch mit x86 möglich ist. AMD gibt power gated eine Verlustleistung von <10mW an.

PhysX@CPU ist nicht proprietär.

Doch. PhysX ist proprietär, egal ob @CPU oder @GPU. Du meinst vielleicht hardwareabhängig. Das stimmt schon eher, zumindest bedingt.

 

[moshqued]

Ich seh das ganze seh einfach so halt SMT und gut was auch immer auf jedenfall GPU at CPU und dann ist das auch hardwareabhängig und halt Watt unterschied neh.

 

[unl34shed]

Ich seh das ganze seh einfach so halt SMT und gut was auch immer auf jedenfall GPU at CPU und dann ist das auch hardwareabhängig und halt Watt unterschied neh.

what?

@Mick_Foley:
Mir ist klar, dass Konsolen ein minimal OS haben und Software gezielt optimiert werden kann.
Aber trotz der ganzen Optimierung werden sie sicher nicht an eine Desktop CPU mit ca. 4GHz ran kommen, außer sie haben eine richtige bremse rein gebaut um ihre GPUs zu verkaufen.

 

[Mick_Foley]

@Mick_Foley:
Mir ist klar, dass Konsolen ein minimal OS haben und Software gezielt optimiert werden kann.
Aber trotz der ganzen Optimierung werden sie sicher nicht an eine Desktop CPU mit ca. 4GHz ran kommen, außer sie haben eine richtige bremse rein gebaut um ihre GPUs zu verkaufen.

Natürlich kommen die an eine 4 Ghz CPU nicht ran, nur sollte man das Potenzial auch nicht komplett unterschätzen. Acht Kerne mit Minimal-BS haben schon viel Luft, wenn der Entwickler sich mühe gibt. Wobei ich allerdings nicht hoffe, das die nächsten Konsolen wieder 7 Jahre am Markt bleiben. Das dürfte die Entwicklung der Hardware wieder immens einschläfern, weil ja jetzt schon jeder 500€ Desktop-PC mehr Leistung bietet...

 

[[HOT]]

Haswell setzt auf Breite, nicht auf Sparsamkeit. Es ist der "verzweifelte" Versuch noch mehr aus SMT herauszubekommen bei möglichst wenig IPC-Verlust. Das Backend verbreitern bringt der IPC nichts, da dort kein Engpass liegt im SingleThreading, nur SMT wird damit besser, weil man Engpässe und Blockaden verhindert. Ich sehe Haswell eher als "SMT-Fix", sodass SMT in jeder Lebenslage nachteilsfrei nutzbar ist. Dennoch ist die Technlogie der superdicken Kerne langfristig eher eine Sackgasse. Die Zukunft liegt darin, möglichst viele Transistoren einzusparen bei möglichst wenig IPC-Verlust. Intel macht derzeit das Gegenteil, nutzt seinen Fertigungsvorteil aus (22nm FinFET) und garniert das Ganze mit weiteren Stromspartechniken um Idle und Teillast weiter zu optimieren, während AMD dazu gezwungen ist, schon die IPC zu beschneiden um Transistoren einzusparen. BD ist die erste Ausprägung der neuen Strategie, war aber fehlerhaft, erst Piledriver ist Version 1 Final gewissermaßen. Der Weg ist durchaus gangbar, Piledriver ist zwar nicht wirklich konkurrenzfähig, was aber in erster Linie an der Fertigung liegt. Würde man Piledriver auf 22nm FinFET umsetzen wär das Bild ein ganz anderes.
Ich vermute auch, dass AMD daran arbeitet gleich 4 Threads in ein Modul hineinzubekommen. Letztendlich wird das auf Designs hinauslaufen, bei dem Frontends und Backends flexibel zugeteilt werden können und man dadurch einige Einheiten, vor allem die Stromfressenden und Transistorreichen, einsparen kann. Das hätte auch den Vorteil, dass man die HSA-GPU gewissermaßen als "Backenderweiterung" mitnutzen kann. Die Zukunft liegt in der Flexibilisierung der CPU-Bestandteile, native Nutzbarmachung der Parallelfähigkeiten der Grafikchips und maschineller Transistoreinsparung- und optimierung bei längerfristig laufenden Fertigungszyklen.

Hinzu kommt auch noch eine Überlegung, die man angesichts der neuen Konsolen anstellen sollte: Diese forcieren jetzt knallhart die Optimierung der Spiele auf 8 Threads. Das ist eine neue Qualität, da Jaguar ungefähr auf Core2-Niveau ist (mit seinen 2 Issues wohlgemerkt, das ist ne Leistung), aber eben mit maximal 2GHz laufen dürfte. Das ist eine Kombination aus recht wenig IPC, weil wenig Takt, und viel Multithreading. Natürlich wird das auch auf die PC-Spiele abfärben, erst recht, wenn man bedenkt, wie M$ sich die Spieleentwicklung und der Integration der XBox-Techniken auf der PC-Plattform anschaut. Das bedeutet, dass in Zukunft mehr Spiele reagieren könnten wie Crysis3 reagiert hat, nämlich problematisch auf SMT bei Nutzung von 6-8 kohärenten Threads.
Anwendungen, sofern man auf BD halbwegs Rücksicht genommen hat, laufen ja jetzt schon konkurrenzfähig schnell. Und das alles muss man angesichts eines aufkommenden Steamroller sehen, der BD Vers.2, also optimiert, in neuem Fertigungsprozess daherkommt.

 

[Mick_Foley]

Der Vergleich hinkt irgendwie gewaltig. AMD hat bei Bulldozer im Endeffekt auch nur einen klassischen Kern aufgebohrt und um einen Integer-Kern erweitert, als nächstes wird man den Kern bzw das Modul weiter aufbohren um eine zweite FPU einzubauen. Wo spart AMD da gegenüber Intel Transistoren?

Und Piledriver wird halt nicht in 22nm gefertigt und auch für 28nm hat man sich bei Steamroller wieder Globalfoundries an die Backe gebunden, die schon den tollen 32nm Prozess hinbekommen haben...

 

[dochurt]

Bin mal gespannt, ob AMD mit 28nm an den Verbrauch vom i7-870 @45nm ran kommt

 

[Undertaker 1]

Der Vergleich hinkt irgendwie gewaltig. AMD hat bei Bulldozer im Endeffekt auch nur einen klassischen Kern aufgebohrt und um einen Integer-Kern erweitert, als nächstes wird man den Kern bzw das Modul weiter aufbohren um eine zweite FPU einzubauen. Wo spart AMD da gegenüber Intel Transistoren?

AMD macht zieht bei CMT jetzt wohl auch die Notbremse und macht einen Schritt zurück, wie man z.B. am zweiten Decoder erkennen kann - man hat offensichtlich erkannt, dass Single-Thread-Leistung bzw. IPC in aktueller Software zu wichtig ist, als das man sie komplett vernachlässigen könnte. Irgendwie ist es schon bezeichnend, das Kabini das Modul-Konzept überhaupt nicht aufgreift; gerade in dieser Klasse kommt es nämlich auf geringe Fläche und hohe Energieeffizienz drauf an - zwei Punkte, die bei allen Bulldozer-Ablegern bisher ziemlich schlecht ausgefallen sind. Generell ist es bei CMT einfach höchst ineffizient, dass man den Chip nur bei hoher Parallelisierung halbwegs ausgelastet bekommt, die schmalen Kerne viel zu hoch takten muss (energetisch höchst ineffizient) und in vielen Fällen viele Einheiten komplett brach liegen; in solchen Situationen ist SMT einfach technologisch im Vorteil. Haswell dagegen steigert gleichermaßen die IPC und vmtl. auch den SMT-Gewinn und wird die Latte bei Perf/Watt und Perf/mm² bzw. Perf/Transistor in dieser Leistungsklasse wohl nochmal höher legen.

 

[[HOT]]

Wie gesagt, Version 1 mit holprigem Fertigungsprozess. Ein BD-Modul ist nicht so groß und hat auch nicht viele Transistoren im Verhältnis. Dafür gibt es aber gigantische Cache-Mengen, was die Transistorzahl ja drasdisch nach oben treibt. Da liegt der eigentliche Pferdefuß. Ein Ivy hat ja viel weniger Cache als ein BD. Hätte man 32nm mit ULK gebaut, wär das kein Energieproblem geworden und es wär mehr Takt für iNB und Cache möglich gewesen, denn grade beim Cache hat ULK gewaltige Vorteile (siehe Thuban-NB-Takte). Leider war ULK nicht praktikabel.

Aber ich stimme zu, dass AMD die Singlethreadingleistung steigert. Aber das ist ganz sicher keine Notbremse sondern notwendige Entwicklung. Notbremse wäre, wenn man jetzt einen K10-Nachfolger angestoßen hätte, das ist bei SR definitiv nicht der Fall, das ist ein lange geplanter BD-Nachfolger und er bestätigt die Richtigkeit des Weges. Und ein BD-Modul ist auch kein Kern mit angeflanschtem Integer-Cluster, das ist einfach Unsinn. Das Frontend macht CMT, nicht der Integer-Cluster. Aber man entließ als Version 1 eben nur die Rohversion, die SR-Änderungen sind die passende Evolution dazu um die Singlethreaded-Leistung auch auf CMT-Basis zu optimieren. Man optimiert bei SR ja nicht einen BD-Kern, sondern macht das Frontend flexibler, also mehr CMT nicht weniger. Die CPU wird nicht dicker dadurch, im Gegenteil, die FPU schrumpft sogar. Gleichzeitig spart man ja bis zu 30% Transistoren mit den neuen Automatisierungstools ein bei SR, das wird mMn vor allem durch die Kopplung der beiden Threads durch CMT ermöglicht.

BD ist kein "Unfall", eigentlich kann man froh sein, dass Piledriver sogar so leistungsfähig ist, wie er ist, ich halte ihn für eine ziemlich gute Version 1 (trotz ULK-Desaster und niedrige NB und L3-Takte), das klappte aber nur, weil man sich auf die Grundzüge des Designs konzentriert hat. Bei SR kann man erwarten, dass den Effizienzgewinn, den man von Bobcat nach Jaguar erreicht hat, auch von BD zu SR erreichen, wenn nicht sogar übertreffen wird. Ein SR-Modul kann um die Hälfte schrumpfen und weniger Transistoren haben ggü. einem BD-Modul (ohne Cache, der Cache schrumpft nur mit dem Fertigungsprozess) und wird trotzdem deutlich leistungsfähiger sein. Die Priorität bei SR liegt mit Nichten bei der IPC-Steigerung, sondern bei der Steigerung der Effizienz.

 

[Mick_Foley]

Das ist kein Blödsinn und mir ist klar, dass der Kern nicht nur angeflanscht wurde. Trotzdem unterstellst du AMD Transitoren-Sparsamkeit und Intel würde dies nicht tun. BD hat 1,2 Milliarden Transsitoren AMD bestätigt: Bulldozer FX nur 1,2 statt 2,0 Milliarden Transistoren - Update: Entschuldigung per Facebook ein Phenom hatte 758 Millionen Transistoren, Transistoren quasi Verdoppelt und Leistung eher nicht, Energie-Effziens auch nicht wirklich verbessert. Ivy Bridge kommt auf 1,4 Milliarden Transistoren wo von 30% auf die iGPU entfallen, bleiben noch ca 980 Millionen Transistoren für den CPU-Part Intel: Ivy Bridge hat 1,4 Milliarden Transistoren - viele davon im Grafikkern [News des Tages]

Und den Cache hat man im Design des BD nun mal vorgesehen und er wird in dem Design und mit der gegeben Fertigung gefertigt, was hätte sein könne ist doch egal, das Spiel kann man mit Intel auch machen.

Transistorensparsamer war bisher definitiv Intel.

Und "bis zu"-Werte bei Tools interessieren mich nicht, entscheidend ist, was dabei am Ende rauskommt.

P.S.: Worum es mir primär geht ist, dass du hier mit zweierlei Maß misst...

 

[dochurt]

Wenn ich mich recht erinnere stimmen die 1,2mrd. Transen auch nicht ^^

 

[Mick_Foley]

Andere Zahlen gibt mir das Internet leider nicht: AnandTech | The Vishera Review: AMD FX-8350, FX-8320, FX-6300 and FX-4300 Tested

 

[mr.dude]

Bin mal gespannt, ob AMD mit 28nm an den Verbrauch vom i7-870 @45nm ran kommt

Mit Sicherheit nicht. Man wäre ja selten dämlich, die Leistungsaufnahme zu erhöhen.

Haswell setzt auf Breite, nicht auf Sparsamkeit. Es ist der "verzweifelte" Versuch noch mehr aus SMT herauszubekommen bei möglichst wenig IPC-Verlust.

"Verzweifelt" würde ich nicht sagen. Es ist halt der einfachste Weg für mehr ILP/TLP, ohne das Design komplett über den Haufen zu werfen und von Grund auf neu zu beginnen. Und so schlecht finde ich Haswell gar nicht mal. Ist zumindest noch in einem vernünftigen Rahmen. Durch die 2. Branch-Einheit ist vielleicht sogar sowas wie SpMT in Zukunft möglich. Vielleicht schafft es ein Hersteller tatsächlich mal, eine Architektur zu entwickeln, die Sprünge praktisch nie falsch vorhersagt und deshalb nie die Pipeline leeren muss. Die Frage ist halt nur, wie Intels Lösungsansatz in Zukunft ausschaut. Ich denke, man wird das Backend nicht endlos verbreitern können. Irgendwann bekommst du physische und thermische Probleme.

 

[y33H@]

Ein 870er ist sparsamer als ein FX-6300 und je nach Benchmark kaum langsamer, idR aber schneller.

 

[dochurt]

Andere Zahlen gibt mir das Internet leider nicht: AnandTech | The Vishera Review: AMD FX-8350, FX-8320, FX-6300 and FX-4300 Tested

AMD is trying to deceive you - you all were PUNKD by them! ~ OBR-HARDWARE

Btw: Moin moin Dudi ^^

 

[newAtioc]

Mit Sicherheit nicht. Man wäre ja selten dämlich, die Leistungsaufnahme zu erhöhen.

Vielleicht meinte er genau das?

 

[mr.dude]

Spoiler

Vielleicht meinte er genau das?

Kann sein. Naja, sollte ja jeder sehen können, dass der i7-870 nicht sparsamer ist, allerdings weniger leistungsfähig.

BD hat 1,2 Milliarden Transsitoren AMD bestätigt: Bulldozer FX nur 1,2 statt 2,0 Milliarden Transistoren - Update: Entschuldigung per Facebook ein Phenom hatte 758 Millionen Transistoren, Transistoren quasi Verdoppelt und Leistung eher nicht

Also Mathematik scheint nicht gerade deine Stärke zu sein, oder? 1200M Transistoren sind lediglich ~58% mehr Transistoren. Weeeeeeiiit entfernt von einer Verdoppelung. Die 758M Transistoren gelten übrigens für den X4. Im Anwendungsrating von CB ist ein FX-8350 56% schneller als zB ein X4 965. Passt also. Der X6 hat übrigens 904M Transistoren, also lediglich ~33% mehr für den FX. Anwendungsrating von CB, FX ~29% schneller. Erneut, passt schon. Wenn man bedenkt, dass Orochi deutlich mehr Cache besitzt, welcher sich bekanntlich nicht 1:1 in der Performance widerspiegelt und nach wie vor der Softwaresupport zu wünschen übrig lässt, geht das zweifelsohne in die richtige Richtung. Mit Nutzung von AVX und FMA kann der FX auch mal locker doppelt so schnell wie der X6 sein. Nur zur Info. Also lass den Quatsch bleiben! Das ist der Haswell Thread.

 

[dochurt]

Ach Mensch Dudi, diskutiere mit jemand anderem, kenne beide aus dem Privaten Umfeld und da ist Bulli in Rev.1/2 immer höher im Verbrauch - Also lass den Quatsch doch einfach sein, unterm Strich in Games/Progs ist der FX8350 mit zweimal zu gedrückten Augen max. 10% schneller, bei einen deutlich höheren Verbrauch trotz kleinerer Fertigung, basta

P.S. Im Spoiler war es noch lächerlicher