AMDs Bulldozer 50 Prozent schneller als Core i7? (Update)

Status
Für weitere Antworten geschlossen.
Das ist natürlich klar - aber die Relation bleibt ja solange bestehen, wie der X6 nicht mehr Kerne als der X4 einsetzen kann. D.h. selbst wenn 4 Threads (!) parallel genutzt werden, dürfte der 2600k bis zu 30% schneller sein.

Schon richtig. Aber:

Bei DualCore Anwendungen war es noch häufig so, dass man ganz grob eine Teilaufgabe rausgesucht hat und die in einen zweiten Thread gepackt hat. Bei neuer Software ist es aber so, dass man immer häufiger auf Frameworks (z.B. OpenMP) setzt, die die Zahl der Threads erst zur Laufzeit festlegen, je nachdem was für eine CPU vorhanden ist. Es wird also nicht mehr auf eine feste Anzahl an Threads optimiert, sondern man versucht soweit es sinnvoll ist, auf möglichst viele Threads zu optimieren. Natürlich nimmt bei vielen Programmen der Ertrag mit immer mehr Threads ab, aber das grundsätzlich nur noch 1,2 oder 4 Threads explizit unterstützt werden, wird immer seltener.

Du vergisst, dass BD eine Hochfrequenz-Architektur ist. Selbst bei 8 aktiven, aber nicht voll ausgelasteten Kernen soll er schon +500MHz Turbo bekommen. Wenn du jetzt die Hälfte der Module abschaltest, sollte deutlich mehr drin sein. Unter der Annahme, dass der Quadcore bei 4 Threads den Turbo nicht aktiviert, hätte er einen relativ großen Taktfrequenznachteil, der den IPC Vorteil evtl. ausgleicht oder gar überkompensiert. Welche Methode jetzt schneller ist, werden erst die Tests zeigen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
lol.

wenn man nen phys. 8 Kerner AMD Bulldozer mit nem phys. 4 Kerner (i7-950) vergkleicht ist es ja klar, dass der AMD mehr Power hat.

50 % Mehrleistung ei doppelter Anzahl an Kernen ist finde ich zu wenig.
Naja, wobei das halt bei AMD keine echten Kerne sind. 1 Modul mit CMT, 2 Threads und 2MB L2 ist so groß wie ein Intel Kern mit SMT, 2 Threads und 2,25 L2+L3. Also aus Kernsicht sehe ich da keinen unfairen Vorteil für AMD. Das Einzige, was Du anführen könntest, wäre der zusätzliche L3, der dem AMD Chip zur Verfügung steht.

Ich bin mir nicht ganz sicher, ob das wirklich die beste Methode ist, denn man kann keine einzelnen Kerne, sondern nur Module komplett abschalten.
Wenn ich also 4 Threads hätte, könnte ich entweder alle Module laufen lassen und dann 1 Thread pro Modul benutzen oder eben nur 2 Module benutzen, die dafür dann aber höher takten. Bei den genannten 180% für die Benutzung beider Kerne eines Moduls, würde ein zusätzlicher Turbo von 10% bereits ausreichen um das zu kompensieren und ich denke bei einer halb abgeschalteten CPU sollte durchaus mehr als das drin sein.
Ist ein Argument, in Verbindung mit nem Turbomode ist es vielleicht eher schlecht. Aber eventuell ist genau das der Unterschied zw. Server/Desktop. Gut möglich, dass man im Dekstopbereich darauf pfeift und die paar Watt mehr Leakage des 2ten, clock- aber nicht powergated INT Clusters in Kauf nimmt.
Irgendwo muss es dann ja auch den ominösen Elektrikunterschied zw. AM3 und AM3+ geben.
Das ist eine gute Frage. 2 Module haben den Vorteil von deutlich mehr Ressourcen, hauptsächlich bei SSE/AVX und L2-Cache. Das breitere Frontend wird sich vermutlich nicht so stark auswirken. Andererseits können 2 Threads im gleichen Modul schneller kommunizieren durch den gemeinsamen L2-Cache. Zusätzlich ist es evtl. eine höhere Turbo-Stufe drin, wenn man dadurch Module komplett abschalten kann.
Doch das breite Front-End ist mit *das* Allerwichtigste, des ganzen BD Designs. Wichtig sind weniger die Pipelines, sondern das Front-End, um die Pipelines (sinnvoll) mit möglichst korrekten Daten zu füllen. Meiner Meinung nach ist das *das* Feature des Modulansatzes. Denn bei einer längeren Pipeline braucht man u.a. ne gute Sprungvorhersage, da falsche Vorhersagen extra viel Kosten. Irgendwo stand mal, dass die Decoder aber nur ~20% ausgelastet wären, d.h. beim Kerndesign ist das eine knifflige Angelegenheit, um eine Balance zw. Kosten/Nutzen zu finden.

Wenn man jetzt 1 Decoder für 2 Kerne verwendet, kann man sich jetzt viel mehr Transistoren im Front-End leisten, da sich die Kosten auf 2 Kerne/Threads verteilen. Bulldozer ist ein Design bei dem alles zusammenpaßt:

Der Modulansatz bedingt eher kleine, platzsparende Cluster, deswegen gibts kleinere, längere INT Pipes mit höhererm Takt, dafür braucht man dann wiederum eine bessere Sprungvorhersage im Front-End bzw. allgemein ein dickes, intelligentes Front-End z.B: mit eine Replay(*) Erkennung, Trace-Cache(**), MacroOp Fusion vielen Buffern und Decodern. Genau das kann man sich dann durch den Modulansatz leisten, womit man wieder am Anfang steht :)

ciao

Alex

(*) Wer Replay nicht kennt, das war *der* Pferdefuß des Pentium4 Designs:
http://www.xbitlabs.com/articles/cpu/display/replay.html

(**) Trace Cache ist noch nicht bestätigt, aber ich behalte weiterhin die Hoffnung, das sowas, oder Ähnliches eingebaut ist, schließlich macht das Front End einen dicken Batzen eines Moduls aus, soviel erkennt man schon von den vorhandenen DIE Shots, und es gibt immernoch keine 100%igen Infos dazu, von MacroOp Fusion mal abgesehen. Hoffentlich lüften sie den Schleier dann auf der ISSCC Ende Feb.
 
Zuletzt bearbeitet:
Ist ein Argument, in Verbindung mit nem Turbomode ist es vielleicht eher schlecht. Aber eventuell ist genau das der Unterschied zw. Server/Desktop. Gut möglich, dass man im Dekstopbereich darauf pfeift und die paar Watt mehr Leakage des 2ten, clock- aber nicht powergated INT Clusters in Kauf nimmt.

Jep, da gibt es verschiedene Möglichkeiten, vor allem, weil man ja auch irgendwann an ein Architektur-abhängiges Taktfrequenz-Limit stößt. Wenn man von z.B. 3,5GHz Grundtakt ausgeht und dann bei halber Abschaltung +1GHz dazu kommt, wie weit soll man denn dann noch hoch gehen bei nur noch einem aktiven Modul gehen. Das Problem, dass ich da sehe, ist eher, dass das vermutlich eher eine Sache des OS-Schedulers wird, das zu entscheiden außer AMD baut so eine Art CPU-Renaming ein :d

Doch das breite Front-End ist mit *das* Allerwichtigste, des ganzen BD Designs. Wichtig sind weniger die Pipelines, sondern das Front-End, um die Pipelines (sinnvoll) mit möglichst korrekten Daten zu füllen. Meiner Meinung nach ist das *das* Feature des Modulansatzes. Denn bei einer längeren Pipeline braucht man u.a. ne gute Sprungvorhersage, da falsche Vorhersagen extra viel Kosten. Irgendwo stand mal, dass die Decoder aber nur ~20% ausgelastet wären, d.h. beim Kerndesign ist das eine knifflige Angelegenheit, um eine Balance zw. Kosten/Nutzen zu finden.

Ja sicher, beim Vergleich K10.5 vs. BD spielt das verbesserte Frontend eine große Rolle. Aber bei der Frage, lass ich bei nur 2 Threads beide auf einem Modul laufen oder jedes auf seinem eigenen, spielt das Frontend meiner Meinung nach nicht so eine deutliche Rolle. Vor allem da der Buffer der Sprungvorhersage bei BD ja sowieso schon sehr großzügig bemessen wurde im Vergleich zu früheren Architekturen und die Fetch- und Dekodierleistung bei nur 2-facher Superskalarität eigentlich auch bei 2 Threads/Modul nicht der Engpass werden sollte.
 
Zuletzt bearbeitet:
Jep, da gibt es verschiedene Möglichkeiten, vor allem, weil man ja auch irgendwann an ein Architektur-abhängiges Taktfrequenz-Limit stößt. Wenn man von z.B. 3,5GHz Grundtakt ausgeht und dann bei halber Abschaltung +1GHz dazu kommt, wie weit soll man denn dann noch hoch gehen bei nur noch einem aktiven Modul gehen. Das Problem, dass ich da sehe, ist eher, dass das vermutlich eher eine Sache des OS-Schedulers wird, das zu entscheiden außer AMD baut so eine Art CPU-Renaming ein :d
Naja, also ein Architekturlimit sehe ich (lange) noch nicht. Sandy taktet mit ner relativ kurzen, vermutlich 14 Stage Pipeline und komplexen, großen Kernen bis so~ 4,5 Ghz, das könnte ein Architekturlimit sein. Denn 4,5 Ghz schaffte man auch schon mit nem guten Nehalem. Da sind die aktuellen 4,5 GHz trotz 32nm Prozess schon mager. Von daher sehe ich bei ner 17-18 Stage Pipeline, und den kleinen Clustern genügend Luft nach oben. Nachdem Sandy so 4,5GHz erreicht, sollten BDs OC Grenze höher liegen, ich sag mal um die 5 GHz, auf alle Fälle mehr als Sandy. Das wiederum bedeutet, dass AMD auch bei den Turbo Modi großzügiger sein kann.
Aber tja wieviel jetzt genau, kA .. das müssen wir wirklich abwarten.
Ich denke sie werden Intels SMT Flags verteilen, soviel Leakage erzeugt ein kleiner INT Cluster schließlich auch nicht, und ne Extrawurst wird Microsoft für AMD wohl kaum machen. Aber warten wirs ab.

Ja sicher, beim Vergleich K10.5 vs. BD spielt das verbesserte Frontend eine große Rolle. Aber bei der Frage, lass ich bei nur 2 Threads beide auf einem Modul laufen oder jedes auf seinem eigenen, spielt das Frontend meiner Meinung nach nicht so eine deutliche Rolle. Vor allem da der Buffer der Sprungvorhersage bei BD ja sowieso schon sehr großzügig bemessen wurde im Vergleich zu früheren Architekturen und die Fetch- und Dekodierleistung bei nur 2-facher Superskalarität eigentlich auch bei 2 Threads/Modul nicht der Engpass werden sollte.
Hmm gute Frage .., wie ist das mit der Sprungvorhersage, wird die vielleicht besser, wenn nur 1 Thread läuft ? Wenn ich mich recht erinnere, dann gibts aber 2 Puffer pro Thread, wäre dann egal.
Ansonsten hätte man noch die Exklusivität des L1I Caches un deines eventuellen Trace Caches auf der Habenseite. Aber ob das dann soviel ausmacht, ok da geb ich Dir dann recht, da sollte z.B. der Effekt der alleinigen Nutzung des L2s oder der FPU größer sein.

ciao

Alex
 
Zuletzt bearbeitet:
In meinen Augen muss man bei so einem Vergleich das gesamte Leistungspotenzial der CPUs miteinander vergleichen und das bedeutet - insb. bei BE oder K CPUs, bei denen man einen Aufpreis für einen offenen Multi bezahlt - auch deren Übertaktungspotenzial mit in Betracht zu ziehen.

Klar, der uninformierte Kunde aus dem Mediamarkt wird selbst eine CPU, für die er den Aufpreis zum Übertakten gezahlt hat, nicht übertakten. Aber wen interessieren die uninformierten Kunden. Wir zählen ja wohl alle zu den Informierten.
Ich kann es nur nochmal sagen, wenn dich Übertaktung interessiert, dann schaue bitte in den entsprechenden Unterforen nach. Hier ist das erstmal nebensächlich. Die CPUs werden so verglichen, wie sie die Hersteller spezifizieren und verkaufen.

Also was ist unter dem Strich schneller: Westmere, der in den seltensten Fällen mal 10-15% schneller als SB sein dürfte, oder SB die in der Regel bis zu 30% schneller ist?
Ich glaube, du verwechselst etwas. Sandy Bridge ist in Anwendungen, die nur wenige Threads erzeugen, ein paar Prozent schneller als der 6-Kern Westmere. In stark multithreaded Anwendungen ist der 6-Kern Westmere hingegen bis zu 30% schneller. Unterm Strich hat der 6-Kern Westmere definitiv mehr Leistungskapazitäten. Was aber auch nicht sonderlich verwunderlich ist. Schliesslich hat er 50% mehr Kerne. Das kann man mit dem bisschen mehr IPC und Takt von Sandy Bridge bei 4 Kernen nicht wettmachen.


wenn man nen phys. 8 Kerner AMD Bulldozer mit nem phys. 4 Kerner (i7-950) vergkleicht ist es ja klar, dass der AMD mehr Power hat.

50 % Mehrleistung ei doppelter Anzahl an Kernen ist finde ich zu wenig.

Das wird dieses mal wieder so sein. Intel zwar teurer aber dafür leistungsfähiger. AMD dafür billig und nicht so leistungsfähig
Man sollte doch vorher den Thread zumindest mal grob überfliegen. Das wurde mittlerweile mehrfach diskutiert. Hier wird kein 8-Kern Bulldozer verglichen, sondern ein 4-Kern Bulldozer (Zambezi). Sowohl Zambezi als auch i7-950 haben 4 CMP Kerne und 8 logische Prozessoren. Der Bulldozer mit 8 CMP Kernen, Interlagos, ist eine Server CPU und soll erst Q3 kommen. Voraussichtlich wird Zambezi zwar als 8-Kerner verkauft, nur sind diese Kerne eben nicht 1:1 mit Intel vergleichbar. Wenn man sich mal rein die Dimensionierung (Vorsicht, nicht Performance!) anschaut und einen simplen CMP Kern, zB beim K10.5, als 100% betrachtet, dann liegt ein Intel Kern bei etwa 120% und ein "AMD Marketing Bulldozer Kern" bei 80%.
 
Naja, also ein Architekturlimit sehe ich (lange) noch nicht. Sandy taktet mit ner relativ kurzen, vermutlich 14 Stage Pipeline und komplexen, großen Kernen bis so~ 4,5 Ghz, das könnte ein Architekturlimit sein. Denn 4,5 Ghz schaffte man auch schon mit nem guten Nehalem. Da sind die aktuellen 4,5 GHz trotz 32nm Prozess schon mager. Von daher sehe ich bei ner 17-18 Stage Pipeline, und den kleinen Clustern genügend Luft nach oben. Nachdem Sandy so 4,5GHz erreicht, sollten BDs OC Grenze höher liegen, ich sag mal um die 5 GHz, auf alle Fälle mehr als Sandy. ...

Ich glaube, du hast einen Zahlendreher in deinem Beitrag. Die 4,5 Ghz für SB müssten ja wohl eher 5,4 Ghz heissen, wenn es ums Architekturlimit geht.
 
Zuletzt bearbeitet:
In meinen Augen muss man bei so einem Vergleich das gesamte Leistungspotenzial der CPUs miteinander vergleichen und das bedeutet - insb. bei BE oder K CPUs, bei denen man einen Aufpreis für einen offenen Multi bezahlt - auch deren Übertaktungspotenzial mit in Betracht zu ziehen.

da sich 950 und AMD auch ohne BE 1a übertakten lassen müsstest die dann auch immer @ oc mitrechnen, und dann würde jeder intel non K von AMD einfach nur vernichtet werden ^^.

Also wenn du das so sehen willst von mir aus mir solls nur recht sein ^^
 
Zuletzt bearbeitet:
da sich 950 und AMD auch ohne BE 1a übertakten lassen müsstest die dann auch immer @ oc mitrechnen, und dann würde jeder intel non K von AMD einfach nur vernichtet werden ^^.

Also wenn du das so sehen willst von mir aus mir solls nur recht sein ^^

Genau das würde ich tun. Und genau deshalb empfielt z.B. auch der angebliche Intel Fanboy Anandtech in seinem SB Artikel AMD anstelle von einigen Intel non-k Modellen zu kaufen.

Ich wollte AMD auch nicht ans Bein pinkeln, ich habe lediglich auf den Beitrag von Duplex geantwortet, in dem Stand "in Cinebench ist Westmere 6C/12T gute 29% schneller als Sandy Bridge 4C/8T" - was schlichtweg falsch ist (siehe hier).

Aber bitte entschuldigt, wenn ich eine neutrale - faktenbasierte - Sicht auf die Dinge behalte und nicht in einen Hype einstimme.
 
Zuletzt bearbeitet:
nunja insgesamt ganz sinnig ist es ja nicht anderseits muss man auch sehen das solche Leute die anandtech lesen auch größtenteils leichtes OC betreiben können. Also soweit ist die aussage schon richtig hier in der Diskussion ist sie doch erstmal eher falsch da man grundsätzlich darüber diskutiert und aufm gesamt markt sind die OCler extrem in der minderheit
 
nur mit dem passenden chipsatz ;-) ( 5% ist nun doch wirklich noch kein oc ) und selbst da absolut kein vergleich zu was normal möglich ist
 
Zuletzt bearbeitet:
Öhm, mit welchem Chipsatz denn nicht? Auch auf einem H67 kann ich einen i5 2500 auf Multi 37 und ~105MHz BCLK laufen lassen, das sind immerhin etwa 3,9GHz und damit ~15% mehr als der normale 4-Kern Turbotakt von 3,4GHz.

Verglichen zu den K-Modellen ist das natürlich nicht sonderlich berauschend, es gibt aber durchaus auch andere CPUs die nicht wirklich mehr Potential haben.
 
Naja, also ein Architekturlimit sehe ich (lange) noch nicht. Sandy taktet mit ner relativ kurzen, vermutlich 14 Stage Pipeline und komplexen, großen Kernen bis so~ 4,5 Ghz, das könnte ein Architekturlimit sein. Denn 4,5 Ghz schaffte man auch schon mit nem guten Nehalem. Da sind die aktuellen 4,5 GHz trotz 32nm Prozess schon mager. Von daher sehe ich bei ner 17-18 Stage Pipeline, und den kleinen Clustern genügend Luft nach oben. Nachdem Sandy so 4,5GHz erreicht, sollten BDs OC Grenze höher liegen, ich sag mal um die 5 GHz, auf alle Fälle mehr als Sandy. Das wiederum bedeutet, dass AMD auch bei den Turbo Modi großzügiger sein kann.

Hmm, ok, Architekturlimit war wohl der falsche Begriff. Worauf ich eigentlich hinaus wollte war, dass ich mir nicht sicher bin, ob bei sehr hohen Taktraten (evtl. > 5GHz) nicht irgendwann der Stromverbrauch bzw. die Hitzeentwicklung überproportional ansteigt. Denn es nutzt ja nichts, wenn man einen Kern mit > 5GHz takten könnte, es aber dann zu einem Hotspot kommt. Nur weil ich durch 8 Kerne insgesamt 125W jagen kann, heißt das ja noch nicht, dass auch ein einzelner Kern 125W Verlustleistung dauerhaft aushält. Aber ich denke da wird man einfach abwarten müssen.

Ich glaube, du hast einen Zahlendreher in deinem Beitrag. Die 4,5 Ghz für SB müssten ja wohl eher 5,4 Ghz heissen, wenn es ums Architekturlimit geht.

Natürlich könnte man OC Ergebnisse mit in so einer Betrachtung mit einfließen lassen, aber darum geht es ja nicht, denn AMD wird genauso Sicherheitsreserven einbauen wie es Intel bei SB getan hat.
 
Ich wollte AMD auch nicht ans Bein pinkeln, ich habe lediglich auf den Beitrag von Duplex geantwortet, in dem Stand "in Cinebench ist Westmere 6C/12T gute 29% schneller als Sandy Bridge 4C/8T" - was schlichtweg falsch ist
Nö, ist vollkommen richtig, was Duplex sagt. Zumindest, wenn wir die CB Ergebnisse als Basis nehmen. Gibt auch noch weitere Anwendungen bei CB, die in etwa das gleiche zeigen, wie Autodesk 3ds Max 2011, Paint.NET oder x264 HD Benchmark Test 2. Das sind übrigens auch die Anwendungen, die ausgezeichnet mit den Kernen skalieren.
 
Mag ja sein, aber welches Programm, das viel Leistung braucht, ist heute noch single-threaded?

Die absolute Anzahl der Threads spielt doch keine Rolle...
Der Punkt ist der, kann eine Anwendung die Berechnungen so aufsplitten, das eben mehrere Dinge gleichzeitig berechnet werden können oder eben nicht!?

Auf heutigen PCs laufen im Hintergrund hunderte Threads, die mehr oder weniger Leistung fordern. Das Problem ist die Abhängigkeit zueinander. Wartet Berechnung B auf das Ergebnis von Berechnung A, so bringen zwei Threads absolut gar nix, es muss sowieso hintereinander abgearbeitet werden.

Schaut man sich da beispielsweise mal Spiele an, KI und Physik kann man hervoragend mit der Coreanzahl skallieren lassen. Das Spiel ansich selbst, eher schlecht, denn es gibt irgendwo eine Basis, auf die alles aufbaut.
Wohingegen beispielsweise Cinema 4D eine Szene in so viele Einzelteile zerhackstücken kann, das eben alle Cores ausgelastet sind, denn jegliche Berechnungen dieser Teile sind voneinander unabhängig. Es ist halt das Problem des dynamischen Inhalts. Statischer Inhalt lässt sich massiv auf mehrere Berechnungen aufsplitten. Dynamischer Inhalt wird nie wirklich gut mit der Anzahl der Cores skallieren.
 
Natürlich könnte man OC Ergebnisse mit in so einer Betrachtung mit einfließen lassen, aber darum geht es ja nicht, denn AMD wird genauso Sicherheitsreserven einbauen wie es Intel bei SB getan hat.

Wobei Intel bei Sandy Bridge weit mehr als eine Sicherheitsreserve lässt. ;) Wie weit man eine CPU ausreizen kann, wenn es der Markt erfordert, zeigt z.B. der X4 970, der selbst mit Spannungserhöhungen in den meisten Reviews nur etwa 15% maximale Taktsteigerung schafft.
Wenn man diese Reserve auf Sandy Bridge umschlägt, sollten selbst im aktuellen Stepping locker noch deutlich schnellere Modelle möglich sein, nur sind diese momentan vollkommen unnötig - man würde sich die eigene High-End Plattform Gulftown unnötig kanibalisieren.

Je nach dem, wie Bulldozer abschneidet und in welchem Marktsegmenten er platziert würde, könnte man solche Reserven bei Bedarf recht zügig ausschöpfen.

Mag ja sein, aber welches Programm, das viel Leistung braucht, ist heute noch single-threaded?

Es gibt Tonnen an professioneller Software, welche gar nicht oder nur sehr unzureichend parallelisiert ist. Aus eigener Erfahrung kann ich momentan von SimulationX oder Autodesk Inventor berichten, wo man mit zusätzlichen Kernen rein gar nichts reißen kann, aber jedes zusätzliche MHz oder höhere IPC die Produktivität massiv steigert.
 
Zuletzt bearbeitet:
Ich glaube, du hast einen Zahlendreher in deinem Beitrag. Die 4,5 Ghz für SB müssten ja wohl eher 5,4 Ghz heissen, wenn es ums Architekturlimit geht.
Ja da hast Du recht, ich hatte die Luft-OC Ergebnisse im Forumthread hier im Hinterkopf:
http://www.hardwareluxx.de/community/f139/intel-lga1155-overclocking-ergebnis-thread-776057.html

Aber ... es gibt ja eben noch WaKü Ergebnisse ... nachdem mit Wasser mehr geht, kanns nicht an der Architektur liegen, sondern eher an der zu hohen Verlustleistung, also quasi Temperaturlimit.

Hmm, ok, Architekturlimit war wohl der falsche Begriff. Worauf ich eigentlich hinaus wollte war, dass ich mir nicht sicher bin, ob bei sehr hohen Taktraten (evtl. > 5GHz) nicht irgendwann der Stromverbrauch bzw. die Hitzeentwicklung überproportional ansteigt. Denn es nutzt ja nichts, wenn man einen Kern mit > 5GHz takten könnte, es aber dann zu einem Hotspot kommt. Nur weil ich durch 8 Kerne insgesamt 125W jagen kann, heißt das ja noch nicht, dass auch ein einzelner Kern 125W Verlustleistung dauerhaft aushält. Aber ich denke da wird man einfach abwarten müssen.
Ah ok, Du meintest also auch ein Temp Limit.
Ja das ist auch ne interessante Sache. Dazu gabs erst von Dresdenboy einen Link zu nem Paper, das untersuchte obs besser ist mehr Transistoren (=breiteres Design) zu nehmen, oder über Spannung den Takt einer kleineren Pipeline hochzujagen.

So ein kleiner Kern hat halt den Vorteil, dass es wegen der kleinen Größe weniger Hotspots geben kann, einfach aus dem Grund, da schlicht weniger Transistoren heizen und leaken. Ist dann schon mal ein Vorteil für AMD.
Weiterer Vorteil sollte die längere Pipeline sein. Die Sandy Übertakter geben bis zu 1,55V, um auf die 5,4 Ghz zu kommen. Bei einer längeren Pipeline braucht man aber nicht soviel Spannung für den gleichen Takt, bzw. man kommt mit der gleichen Spannung höher.

Naja wie auch immer, die Taktfrage bleibt weiterhin spannend ;-)
 
wenn man nen phys. 8 Kerner AMD Bulldozer mit nem phys. 4 Kerner (i7-950) vergkleicht ist es ja klar, dass der AMD mehr Power hat.
Immer dieser Blödsinn. Wieoft haben wir das die letzten Tage eigentlichs chon durchgekaut?
 
Natürlich könnte man OC Ergebnisse mit in so einer Betrachtung mit einfließen lassen, aber darum geht es ja nicht, denn AMD wird genauso Sicherheitsreserven einbauen wie es Intel bei SB getan hat.
Jup. Wobei man bedenken sollte, Sandy Bridge hat noch eine IGP, die natürlich auch in die TDP einfliesst. Das erfassen die meisten Reviews gar nicht, da sie nur den CPU-Teil auslasten. Und, Intel gibt auf Folien sogar an, dass Sandy Bridge bei bestimmter Last mehr als die angegebene TDP ausreizt. So viel Sicherheitsreserve, bezogen auf die Thermik, scheint da gar nicht vorhanden zu sein. Intel scheint schon recht nah ans Machbare zu gehen. War beim i7-980X ja genauso, der trotz 32 nm sogar etwas mehr Strom brauchte als i7-975. Wo wiederum die Grenzen der Sandy Bridge Architektur liegen, darüber kann man nur spekulieren. Ebenso bei Bulldozer. Für Endkunden allerdings eh recht uninteressant, da sich erwerbbare Modelle in gängige TDP-Klassen einordnen müssen.

Mag ja sein, aber welches Programm, das viel Leistung braucht, ist heute noch single-threaded?
Kommt halt immer auf den Einsatzzweck an. Aber ist schon richtig, die Szenarien, die wirklich Performance brauchen, sind mittlerweile mehrheitlich multithreaded. Sandy Bridge liegt in singlethreaded Szenarien etwa 10-20% vor Gulftown, was man meist noch nicht mal spürt. Das Problem ist vielmehr, viele haben den Sinn von Multicore bisher nur halbherzig verstanden. Es geht dabei nicht nur um Multithreading, sondern vor allem auch um Multitasking. Ein schönes Beispiel hierfür ist immer wieder LAME, eine singlethreaded Anwendung. Man kann natürlich eine Datei umwandeln, um dann festzustellen, dass Sandy Bridge die eine oder andere Sekunde schneller ist als Gulftown. Nur, ist dies wirklich von Bedeutung? Eher nicht. Interessant wird es doch erst, wenn man ein ganzes Album oder gar mehrere Alben umwandeln möchte, was Minuten oder gar Stunden dauern kann. An LAME selbst ändert sich dadurch natürlich nichts, es bleibt singlethreaded. Es können aber beliebig viele Instanzen davon erzeugt werden, wo dann Sandy Bridge wiederum das Nachsehen hat. Und nebenbei bemerkt, sämtliche Streaming Plattformen (Youtube & Co) basieren auf diesen Grundlagen.
 
Jo eben, so sehe ich das auch. AMD wird die Preise schon dementsprechend der Leistung und der Konkurrenz anpassen ;) Von daher wird es dann wahrscheinlich scheiß egal sein, ob man dann für 250 Euro nen Intel holt oder nen AMD.. es sind nun mal beide keine Wohltätigkeitsorganisationen ;) trotzdem glaube ich der Sache mit 50% schneller erst wenn sie raus sind und es bewiesen wurde^^
 
Danke für Aufräumen, schade das Manche leute nich ein wenig gutes an einem Produkt lassen können welches ja noch nichtmal bestätigt ist. Ich hoffe die Cebit lässt endlich auf verlässliche benches hoffen damit endlich ruhe ist mit dem gezanke
 
Zuletzt bearbeitet:
ich bin froh das aufgeräumt wurde.
ich fände es marketing mäßig sehr gut wenn amd die leistung einiger samples zeigen würde^^
 
@Matrox
Du hast jemanden als Fanboy dargestellt, was als Grund zum löschen ausreicht.
 
@Matrox
Du hast jemanden als Fanboy dargestellt, was als Grund zum löschen ausreicht.
Eine PM mit der Bitte das zu ändern hätte gereicht. Das gesamte Posting zu löschen war unnötig :motz:
Komischerweise bei anderen Moderatoren dieses Forum funktioniert das.

Ausserdem habe ich über eine Tatsache berichtet als Fanboy hat er sich selber geoutet :wink:
 
Was haben jetzt derartige Diskussionen hier zu suchen? Kläre das wenn bitte per PN.
 
Ich frage mich nur wie den i7 950 auf den 1156 Sockel bekommen haben bei dem Test .
Hammer und Säge dann passt das ?

Mega

---------- Beitrag hinzugefügt um 16:28 ---------- Vorheriger Beitrag war um 13:41 ----------

Jo eben, so sehe ich das auch. AMD wird die Preise schon dementsprechend der Leistung und der Konkurrenz anpassen ;) Von daher wird es dann wahrscheinlich scheiß egal sein, ob man dann für 250 Euro nen Intel holt oder nen AMD.. es sind nun mal beide keine Wohltätigkeitsorganisationen ;) trotzdem glaube ich der Sache mit 50% schneller erst wenn sie raus sind und es bewiesen wurde^^

Was solls hier wird ein Vergleich gezogen zum i7-950 während längst der 2600K das Maß aller Dinge bei Intel ist und der ist in vielen Dingen auch um einiges schneller .
Ob der Bulldozer dann auch so ein krasses OC Potenzial wie Sandy mitbringt ist auch noch nicht klar .
Also ich bin skeptisch was das betrifft und AMD Intel die Wurst vom Brot klaut !

Mega
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh