Wird AMD permanent gegenüber Intel in Reviews benachteiligt? Bitte Anfang lesen [2|1]

[KILLTHIS]

Irgendwie dreht ihr euch mit euren Diskussionen ständig im Kreis. Es ist doch offentsichtlich das AMD Produkte in einigen Reviews schlechter dargestellt werden als sie tatsächlich sind, das kann man nicht weg diskutieren (man kann schon, wenn man alle Augen inklusive der Hühneraugen zudrückt). Wenn ein Redakteur einen Phenom II 810 der sicher nicht die Speerspitze der Phenom II Familie ist mit einen QX9770 vergleicht und ersteren als miserabel bezeichnet obwohl in den Test maximal 5-10 FPS zwischen den einzelnen Prozessoren liegen kann ich das ganze nicht verstehen. Es ist doch mehr oder weniger bewiesen das Intel Großmärkte dafür bezahlt hat keine Konkurrenprodukte in die Regale zu stellen, wäre es dann abwegig das Intel auch Magazine besticht (oder bestochen hat) die eigenen Produkte in ein besseres Licht zu stellen als Konkurrenzprodukte? Eine andere Erklärung für teilweise unerklärliche Testaufbauten und Testergebnisse könnte auch sein das einzelne Redakteure nicht ganz unparteiisch sind, das gilt für AMD und Intel zu gleichermaßen. Bei den großen Streuungen der jeweiligen Reviews könnte man zumindest davon ausgehen das nicht alles mit rechten Dingen zu geht. Andererseits sollte man nicht jedes Ergebniss überbewerten, Fehler können bei so langwierigen Tests einfach mal auftreten.
Wieso aber einige hier bei jeder Gelegenheit auf AMD einprügeln müssen verstehe ich überhaupt nicht. Ich hatte in den letzten Jahren sicher 20 Core 2 Duo/Quad und Core i7 CPUs in Betrieb und ich kann wirklich nicht behaupten das ich nun zum Phenom einen Einbruch an FPS oder sonstwas erlitten hätte.
Bis vor einigen Monaten war ich auch der Meinung keinen AMD Rechner mehr ins Haus zu holen nur sehe ich aktuell keinen Grund Intel blind zu bevorzugen wie das wohl einige tun.

Dem stimme ich zu. Ich habe ein paar Seiten gelesen und ewig geht die gleiche Offtopic-Sülze von dieser unsäglichen Server-Diskussion um, welche lieber in einem Seperaten Thread behandelt werden sollte.
Und mich würde es auch nicht wundern, wenn Intel Magazine für gute Reviews besticht. Bei Synthethischen Benchmarks sehe ich es gerne ein, dass der i7 einem P2 davonzieht, aber bei Spielen ist das eine andere Sache. Sicherlich, der 955 BE käme lang und breit nicht an einen 975 heran, so denke ich zumindest, aber dem 920 kann er dennoch gut und gerne in einigen Dingen Paroli bieten, so kann ich es zumindest in der Summe sagen, nachdem was ich so gesehen habe. Übrigens finde ich das Topic sehr gut, lob an den Threadersteller, ich muss gestehen, ich habe einige Male bei diesen Reviews nicht aufgepasst und daher sind mir solche Details entgangen. Ich kann mich auch an einige Reviews entsinnen (ich finde sie leider nicht) wo dann als Speerspitze der 940 anstelle des 955 genutzt wurde - was ich aber unsäglich fernab jeglicher Realität empfinde, denn dieser kann sich wohl kaum mit dem 920 von Intel messen.
Da ich aber auch vorher schon einen P2 955 haben wollte, wird meine Entscheidung auch so stehen bleiben, alleine das Preis/Leistungsangebot ist schon der Punkt, weshalb ich AMD vorziehe.

 

[Undertaker 1]

Niemand hat dich zu irgendetwas gezwungen. Du solltest aber langsam mal einsehen, dass andere User in gewissen Bereichen womöglich einiges mehr an Fachwissen mitbringen als du.

Da sich das aber nicht auf dich bezieht, werde ich mich daran nicht weiter beteiligen. Schönen Abend.

p.s.: Von mir aus können wir den Müll oben übrigens gerne jeder entsorgen, auch wenn ich nicht damit rechne das du dazu bereit bist.

Und mich würde es auch nicht wundern, wenn Intel Magazine für gute Reviews besticht.

Vorsichtig mit solchen Formulierungen! Das kann rechtlich schnell mal gefährlich werden.

 

[dr-ami]

Vorsichtig mit solchen Formulierungen! Das kann rechtlich schnell mal gefährlich werden.

Was soll an seiner allgemein gehaltenen Formulierung verwerflich sein? Intel ist nicht unbedingt dafür bekannt die Konkurrenz mit fairen Mitteln zu schlagen, das Urteil der EU und anderer Staaten belegt das doch warum sollte sich die Ausnutzung der Marktmacht nicht auch auf andere Bereiche ausweiten? Das sind nur Vermutungen und keine Unterstellungen.

 

[schlapp]

...

Und mich würde es auch nicht wundern, wenn Intel Magazine für gute Reviews besticht.

Vorsichtig mit solchen Formulierungen! Das kann rechtlich schnell mal gefährlich werden.

Na und? Dann verhängt die EU-Kommission eben erneut ein Bußgeld gegen Intel. Wäre Intel doch selber schuld.

 

[Opteron]

Diese Durchnummerierung meinte ich mit "Analyse". Und nein, ein Spiel wäre noch sehr viel langsamer, wenn das OS die Kerne nicht priorisiert nach physikalisch zuweisen würde.

Aso, na dann schreib Nummerieren .. Analyse ist für sowas doch viel zu hoch gegriffen ;-)

Nein, ab 2002 funktioniert SMT auch korrekt. Ich kann dazu jetzt nichts raussuchen, aber ich bin davon überzeugt, dass das OS erst die physikalischen Kerne auslasten wurd. Schau dir mal Performanceunterschiede zwischen Win2k und WinXP mit nem P4 mit HTT an. Das ist gewaltig, weil Win2k die 2 logischen Kerne wie physikalische behandelt. Programme würden sehr viel mehr Leistung verlieren durch SMT und nicht nur 5%. Damit implizierst du ja eine über 95%ige Performanceeffizienz für SMT pro Kern. Das kann definitiv nicht sein im Durchschnitt. Win7 wird daran auch nichts ändern, da SMT schon vorher korrekt implementiert wurde - diese Technik ist nunmal einfach nicht so toll.

Mag ja alles stimmen .. aber wie erklärst Du Dir das Performanceplus bei SMT + festgepinnten Software Threads ?
Vor allem, da das Leistungsplus ziemlich genau dem entspricht, wenn man SMT komplett abschaltet.
Dein beschriebener, alter P4 Vergleich kann gerne stimmen, aber das kann durchaus die "normale", anfängliche SMT Optimierung gewesen sein - ohne richtiger Nummerierung. Damals gabs ja eh nur 1 echten Kern ;-)

Der Pferdefuss, den ich oben aufgezeigt habe, betraf schon den P4 und wird vor allem den Clarkdale treffen, sofern ein Programm aus 2 rechenintensiven und mehreren weniger rechenintensiven Threads mit vielen Synchronisationen besteht.

Also wenn da ne Software kommt, die 4 Threads auslegen kann läuft die auf nem Dualkern mit 2fach SMT sicherlich schneller als auf nem normalen Dual.

ciao

Alex

P.S: @all: Ignorfunktion ist was feines, kann ich nur empfehlen

 

[Mondrial]

PCGH ist lächerlich? Eine solche Aussage von jemanden, der zwei HD4890 OC im Rechner hat, kann man nicht für voll nehmen. Aber aale du dich nur im Sonnenschein deiner roten Fanboy-Sonne.

Irgendwie scheint PCGH allgemein schlecht über AMD informiert zu sein:

Eng verwandt ist die Athlon X3 und X4 Serie. Die TDP beträgt hier 95W für die non-e Modelle und der Cache wurde bei den X3 weiter auf 1,5 Megabyte verkleinert. [...]

Verkleinert Die X3 haben schon immer "nur" 1.5MB...

[...]Die Phenom II X3 Serie wird mit einem 3 Gigahertz Phenom II X3 740 BE erweitert. Im Zuge dessen wird die bisherige Black Edition mit 2,8 Gigahertz einem Phenom II X3 720 mit festem Multiplikator weichen. Unverändert auch hier die restlichen Daten: 2 Megabyte 2nd-level-Cache, 4 Megabyte 3rd-level-Cache, 95 Watt TDP und Sockel AM3.

Also mein 720er hat 1.5MB L2 und 6MB L3...

Neue Phenom II CPUs: TDP-Limit erreicht?

 

[Opteron]

Also mein 720er hat 1.5MB L2 und 6MB L3...

Hast halt keinen 740 PCGH Edition

Neue Phenom II CPUs: TDP-Limit erreicht?

Viel komischer finde ich bei dem "Ding" eher den Schlussatz:

AMD gelang es später, den Verbrauch in neuen Revisionen auf 125 Watt zu drücken, war aber nicht mehr in der Lage, den Takt des Phenom I weiter zu steigern. Ähnliches könnte nun auch dem Phenom II bevorstehen - und das obwohl die Taktfrequenz seit dem Debüt-Modell Phenom II X4 940 BE um nicht einmal 15% gesteigert wurde.

Was für ne Dramatik ... die Schreibkünste wäre bei ner Kleinkunstbühne sicher toll, aber bei ner IT Onlinepublikation ... ok ComputerBild gibts auch, aber das ist (war?) ein anderer Level.

Geht doch auch anders:

Bei allen drei Nehalem-CPUs handelt es sich um Quadcores, die 8 Mebibyte L3-Cache besitzen und eine TDP von 130 Watt aufweisen.

http://www.pcgameshardware.de/aid,662524/Intel-Core-i7-Preise-und-Modelle/CPU/News/
Nüchtern, sachlich, knapp ... so passt das. Da schrieb auch keiner, dass der i7 bereits am Taktende sei, weil sogar schon das 2,66 GHz Bambinimodell mit hitzigen 130W TDP aufwartet... würde mich auch gar nicht interessieren, TDP ist das eine, Verbrauch das andere.

Aja eins noch, (halb-zitiert):
"Seit dem Debüt-Modell 965 XE wurden die i7 Taktraten um nichteinmal 5% gesteigert, und das obwohl der i7 schon länger als der Phenom2 auf dem Markt ist."

ciao

Alex

P.S: Weil ichs gerade sehe, sind die Binärpräfixe bei PCGH jetzt wieder out ? Oder handhabt das jeder Schreiber nach gut Dünken ?

 

[Undertaker 1]

Aja eins noch, (halb-zitiert):
"Seit dem Debüt-Modell 965 XE wurden die i7 Taktraten um nichteinmal 5% gesteigert, und das obwohl der i7 schon länger als der Phenom2 auf dem Markt ist."

Es besteht schlicht kein Bedarf für ein höher taktendes Modell In der Folge müssten die Preise für die langsameren Modelle gesenkt werden, die Marge sinkt bzw. die Taktanforderungen an die Dies steigen -> tendenziell sinkende Ausbeute. Das wäre ein Schuss ins eigene Bein.

 

[Athlon-64]

und für was war dann der 975 ... ?? ... als Alibi ???

mfg

 

[thom_cat]

Es besteht schlicht kein Bedarf für ein höher taktendes Modell In der Folge müssten die Preise für die langsameren Modelle gesenkt werden, die Marge sinkt bzw. die Taktanforderungen an die Dies steigen -> tendenziell sinkende Ausbeute. Das wäre ein Schuss ins eigene Bein.

der spruch war doch nun wirklich nicht ernstgemeint ^^

 

[Mondrial]

Was für ne Dramatik ... die Schreibkünste wäre bei ner Kleinkunstbühne sicher toll, aber bei ner IT Onlinepublikation ... ok ComputerBild gibts auch, aber das ist (war?) ein anderer Level.

Das Phenom I vom Phenom II abgelöst wurde, und somit der Sinn eines höher taktenden Modells mehr als in Frage zu stellen ist, scheint PCGH wohl auch entgangen zu sein. Aber Hauptsache ein Kritikpunkt...

Ich verstehe nicht, wie man diesen Kurs, trotz teilweise harscher Kritik aus der eigenen Community, so weiterführen kann.

 

[Undertaker 1]

und für was war dann der 975 ... ?? ... als Alibi

Vermutlich der gleiche wie beim 950: Der Unterschied zum sehr viel günstigeren 920 sollte vergrößert werden, um mehr Käufer für das höherpreisige Produkt zu finden.
Eine grobe Parallele könnte man auch bei AMD finden, die über den freien Multiplikator und geringe Aufpreise (hier natürlich in ganz anderen Dimensionen) den Käufer für das jeweils größte Modell zu begeistern. Mit Erfolg, wie der im Vergleich zu den kleineren Modellen weitaus beliebtere X4 955 zeigt.

 

[Athlon-64]

das wird aber nicht funktionieren - denn der EE ist ein nischenprodukt und der 950 sein Geld schlicht nicht wert

mfg

 

[Undertaker 1]

Objektiv gesehen stimmt das, nichtsdestoweniger ist ein 950 zum gleichen Preis attraktiver als ein 940 und ein 975 besser als ein 965 - den volumenstärkeren 920 hat man ja gerade eben nicht angetastet, um die Differenz nach oben zu vergrößern.

 

[Opteron]

Ich verstehe nicht, wie man diesen Kurs, trotz teilweise harscher Kritik aus der eigenen Community, so weiterführen kann.

Böse Zungen mögen behaupten, dass die finanziellen Anreize einer Community eher gering sind ...

ciao

Alex

 

[[HOT]]

Aso, na dann schreib Nummerieren .. Analyse ist für sowas doch viel zu hoch gegriffen ;-)

hehe jo, aber auch einfache Analysen sind Analysen . Dass da jetzt kein ultrakomplizierter Superalgorithmus hintersteht wollt ich damit auch net sagen . Nur das SMT Unterstützung eben SMT-Unterstützung ist und keine halbe SMT-Unterstützung oder sowas.

Mag ja alles stimmen .. aber wie erklärst Du Dir das Performanceplus bei SMT + festgepinnten Software Threads ?
Vor allem, da das Leistungsplus ziemlich genau dem entspricht, wenn man SMT komplett abschaltet.
Dein beschriebener, alter P4 Vergleich kann gerne stimmen, aber das kann durchaus die "normale", anfängliche SMT Optimierung gewesen sein - ohne richtiger Nummerierung. Damals gabs ja eh nur 1 echten Kern ;-)

Das ist in der Tat die Schwäche in meiner Argumentation. Aber man sah ähnliches Verhalten ja auch so beim 840EE, der hatte 2 Kerne und SMT und der Schedular verhielt sich genauso wie jetzt.
Dass man wenn man manuell da rumfurwerkt keine Einbrüche mehr hat ist auch völlig logisch, damit nimmst du dem Schedular ja die Verteilungsaufgabe ab. Mich stört eben so gewaltig an dieser gängigen Meinung, dass SMT einfach genutzt wird wie normale Kerne, dass die Leistungseinbrüche nicht größer und vor allem nicht so irre unregelmässig sind. Im Prinzip wäre es dem Schedular ja völlig egal, welchen Thread er jetzt wo hinpackt. Das würde aber zu extrem ungünstigen Konstallationen führen, ich könnt mir Einbrüche um die 50-80% vorstellen, wenn der Schedular so handeln würde - eben genau das, was mit Win2k damals passierte, wenn HTT an war. Das passiert aber nicht. Die Einbrüche sind zwar unterschiedlich pro App, aber dort konstant. Also muss der Schedular irgendwie doch priorisiert verteilen, wenn auch nicht immer perfekt (daher die berüchtigten 5%).

Also wenn da ne Software kommt, die 4 Threads auslegen kann läuft die auf nem Dualkern mit 2fach SMT sicherlich schneller als auf nem normalen Dual.

Eben da hab ich meine Zweifel. Das war bei dem berühmten P4-EE-DualCore ja eben auch nicht der Fall. Seither hat sich die Situation sogar verschlimmert, da der Nehalem wesentlich effektiver seine Kerne füllen kann als der P4 früher (Loop-Detektor usw), er arbeitet deutlich effektiver, also bringt SMT auch weniger. Zudem ist seither die Software zwar mehr Multithreaded, aber auch die Compiler deutlich effektiver geworden. Dein Fall wäre der Idealfall, aber auch nur dann, wenn die Threads vernünftig verteilt sind. Sind die Threads voneinander abhängig, wirds dann wieder kritisch und SMT wirkt wieder eher kontraproduktiv, mMn könnte der Schuss sogar bei 4 Threads nach hinten losgehen.
aber auch so: SMT kann nur dann effektiv sein, wenn die Rechenpipes nicht schon so gut ausgelastet werden. SMT wird da vielleicht die letzten 5-10% noch rausquetschen können (ist ja schon ein netter Bonus, aber leider erkauft mit Nachteilen). Sicher gibt es auch die ein oder andere App, die mehr profitiert, aber eben nicht der Durchschnitt.

[...]
P.S: @all: Ignorfunktion ist was feines, kann ich nur empfehlen

Das kann ich nur unterstreichen. Man muss nicht jeden Müll beantworten, vor allem, wenn er von bekannten Personen kommt. Der Leser weiß schon was Müll ist und was nicht .

 

[Opteron]

Das ist in der Tat die Schwäche in meiner Argumentation. Aber man sah ähnliches Verhalten ja auch so beim 840EE, der hatte 2 Kerne und SMT und der Schedular verhielt sich genauso wie jetzt.

P4 Vergleiche sind eigentlich eher schlecht, bis auf Hyperthreading ist da wirklich alles anders, v.a. die I/O Anbindung bereit mir da Kopfweh, unten mehr ;-)

Das würde aber zu extrem ungünstigen Konstallationen führen, ich könnt mir Einbrüche um die 50-80% vorstellen, wenn der Schedular so handeln würde - eben genau das, was mit Win2k damals passierte, wenn HTT an war.

Hmmm, tja ... wenn man halt sicherstellen kann, dass das wirklich nur am Scheduler hing. Vielleicht wars ja auch irgendwas andres, was zw. 2000 -> XP passierte, eventuell ne Anpassung an Netburst und dessen geänderten Latenzen, Prozesswechselzeiten etc. ? Abgesehen davon weiss man nicht was die gemacht haben, M$ war damals ziemlich schlampig was das Coden anbelangt, gut möglich, dass die nur den 1 Kern / 2 Threads Fall vorsahen.

Das passiert aber nicht. Die Einbrüche sind zwar unterschiedlich pro App, aber dort konstant. Also muss der Schedular irgendwie doch priorisiert verteilen, wenn auch nicht immer perfekt (daher die berüchtigten 5%).

Naja, das blöde ist ja auch noch, dass man eben nicht nur die 4 Spiele Threads hat, sondern auch noch ne Menge Systemtasks, die auch noch alle paar Millisekunden laufen wollen. Die Prozesse werden eh andauernd unterbrochen. Da ist es jetzt möglich, dass die nach nem Taskwechsel auf eine andren Kern verschoben werden, da der zu der Millisekunde gerade frei war, es aber besser wäre, noch ne ms mehr zu warten, da man dann wieder den gleichen Kern mit passendem L2 hätte.
An dem gleichen Problem krankt ja auch C&Q bei AMD, da wird ein Thread reihum auf die Kerne gescheucht, die reihum dann hoch und runtertakten.
Also zumindest bei nur 2 Threads mit 100% Last.
Mit vier 100% Threads wärs sicherlich besser, da das takten dann entfällt, aber das nur nebenbei ;-)

Eben da hab ich meine Zweifel. Das war bei dem berühmten P4-EE-DualCore ja eben auch nicht der Fall. Seither hat sich die Situation sogar verschlimmert, da der Nehalem wesentlich effektiver seine Kerne füllen kann als der P4 früher (Loop-Detektor usw), er arbeitet deutlich effektiver, also bringt SMT auch weniger.

Jo, wie schon oben deutlich wurde, P4 und i7 zu vergleichen ist schwierig. Was v.a. beim i7 einiges bringt sind die unganged IMCs. Der P4 musste sich da noch mit nem 1066er FSB rumschlagen, den sich auch noch 2 Dies teilen mussten und an dem nur ganged DDR1/DDR2 hing. Das ist alles andere an ideal, da verhungern die Threads oft.
Ich geb Dir recht, dass der i7 jetzt einen single thread besser ausnützen kann, aber dafür ist das Design auch um einiges breiter, da gibts jetzt a) mehr und b) 128bit Function Units auf die Arbeit verteilt werden kann. Siehst Du z.B. auch hier:
http://www.realworldtech.com/page.cfm?ArticleID=RWT030906143144&p=6


Man darf nicht vergessen, dass SMT nicht nur die Rechenwerke besser auslastet, so dass z.B. im Idealfall ein FPU und ein INT Thread parallel ablaufen, sondern auch von Speicherlatenzen eines Threads (stark) profitiert. In der Wartezeit in der ein Load/Store ins RAM von Thread 1 abgewickelt wird, kann der 2te Thread schon weiterechnen.

Extrem sieht man das am P4 am Beispiel eines boinc Projekts. Bei P3D hat mal einer ein *FPU* Projekt mit/ohne SMT gebencht, mit SMT war der P4 30% schneller (also mehr Durchsatz, eine einzelne WU war natürlich länger unterwegs) ... das waren 2 gleiche Work Units, die garantiert die gleichen Function Units belegten, da die Instruktionen ja identisch sind.

aber auch so: SMT kann nur dann effektiv sein, wenn die Rechenpipes nicht schon so gut ausgelastet werden. SMT wird da vielleicht die letzten 5-10% noch rausquetschen können (ist ja schon ein netter Bonus, aber leider erkauft mit Nachteilen). Sicher gibt es auch die ein oder andere App, die mehr profitiert, aber eben nicht der Durchschnitt.

Nein, siehe P4 Beispiel oben Wobei Du natürlich auch gerne so sehen darfst, dass die Piplines bei nem LD/Store nicht ausgelastet sind ;-)

Edit:
Aja, für weitere Diskussionen sollten wir uns wohl besser nen SMT Thread suchen, such Dir einen aus und schick mir den Link einfach per PM ;-)

ciao

Alex

 

[[HOT]]

Nur um das OT-Geraffel noch zu einem Abschluss zu bringen, ich gebe zu, die P4-Vergleiche waren nicht optimal, dienten ja auch nur zur Erklärung . Sicherlich ist das Design selber auch breiter, aber eben eher im Frontend, was den P4 wohl am Meisten zu schaffen gemacht hat. Na ja, wir werden sehen, in wieweit sich das SMT des Clarkdale in der Praxis auswirken wird. Beim Nehalem bringt es jedenfalls nicht so die Menge, wenn jetzt noch viele Apps auf OpenCL/DX11 umsteigen (was ich hoffe und auch denke, die Vorteile sind erheblich) verschwindet ein Großteil der Apps, die von SMT profitieren würden. (Wenn ich mir Sandy so anschaue mit seiner L3-IGP-Anbindung, rechnet Intel jedenfalls auch fest damit, dass OpenCL/DX11 ein großer Wurf wird.)
Ich seh schon wie das ablaufen wird: In den Reviews hat Clarkdale wieder riesen Vorsprünge durch SMT, was in der Praxis kaum gehalten werden kann, weil die Apps wieder gut ausgesucht werden. Es ist einfach ärgerlich, dass man Journalisten so gut mit Sonderfeatures abspeisen kann. SMT ist zudem noch ein schwer zu erfassendes Thema, weil seine Bedeuting kaum abgeschätzt werden kann - hier wirkt es super, dort nachteilhaft. In Reviews sieht man wieder nur das Super, aber kaum das Nachteilhaft. AMD meidet solche Features wie SMT und Turbo, deshalb steht AMD tendenziell oft schlechter dar, weil sie schlicht unspannender sind. Ich glaube, das ist ein Hauptgrund, warum es diesen Thread überhaupt gibt. Man versteht die Redaktreure gerne falsch, weil man sich in sie schlecht hineinversetzt, andererseits fehlt denen oft der Abstand zu Sache, aus vielerlei Gründen, was aber für eine glaubhafte Objektivität wichtig wäre. Vor allem bei der PCGH fällt dieser Widerspruch ja oft auf, wie schon fleißig gepostet wurde .


Eine Sache noch:
Ich denke, dass eine Sache nicht richtig rüberkam: Ich meinte Threads, die untereinander synchronisiert werden müssen. Die können sich gegenseitig blockieren oder durch andere rechenlastige Threads verzögert werden bei SMT, wenn der Schedular da nicht drauf Acht geben würde . Und: War doch ne relativ fruchtbare und kurze OT-Diskussion, ich danke den Mods für die Nachsicht .

 

[PitGST]

Ja nun ist aber wirklich ende mit dem Offtopic.

 

[fdsonne]

AMD meidet solche Features wie SMT und Turbo, deshalb steht AMD tendenziell oft schlechter dar, weil sie schlicht unspannender sind.

Aber warum sollte AMD nicht ebenso beispielsweise den Turbomodus aufgreifen...

Ich sehe an diesem keinen nennenswerten Nachteil... Und auch nicht wie oben gesagt den Mehr-Stromverbrauch, denn wenn nur der Multi um eine/zwei Stufen angehoben wird, dann verhält sich das ganze ja identisch wie bei einem Modell, welches den Takt als Std. Takt bekommt, mit dem gleichen Stromverbrauch dessen (mal abgesehen von der wirklich anliegenden Spannung, welche ja schwankt)

Wobei ich aber auch sagen muss, das man in dem Fall hätte den Takt auch fest anlegen können, wenn keine Last anliegt, idlet die CPU ja sowieso, und wenn Volllast über alle Cores anliegt, geht der Takt ja auch auf mindestens eine Stufe über dem Std Takt...
Klingt zwar als für die Presse schön, aber zumindest den Volllast-Turbomodus hätte man weglassen können und stattdessen den Volllast-Turbo-Modus als Std. Takt anbieten können...

 

[mr.dude]

Aber warum sollte AMD nicht ebenso beispielsweise den Turbomodus aufgreifen...

Turbo Mode ist keine wirklich smarte Lösung. AMD designed in erster Linie Server Chips. Und dort wird sowas idR sowieso nicht verwendet. Das hat vor allem thermische Gründe. Zudem kann sich die Energieeffizienz des Chips verringern.
Bis auf eben die Zeit, wo du in einem konkreten Szenario mehr Performance bekommst, hat der Turbo Mode keinen Vorteil. Es ist im Endeffekt lediglich ein Benchmark Feature.
Schau dir mal an, woran IBM momentan forscht. Einzelne Bereiche einer Architektur mit deutlich höheren Frequenzen als normal laufen zu lassen. Und hier reden wir über höhere zweistellige GHz Werte. Das ist imo weitaus interessanter als Intels plumper Ansatz, den du mit jedem Modell mit offenem Multiplikator auch problemlos in Software umsetzen kannst.

Und auch nicht wie oben gesagt den Mehr-Stromverbrauch, denn wenn nur der Multi um eine/zwei Stufen angehoben wird, dann verhält sich das ganze ja identisch wie bei einem Modell, welches den Takt als Std. Takt bekommt

Ja. Nur skaliert nicht jede Anwendung linear mit dem Takt. Und ein bis zwei Stufen bringen dir auch nicht viel. Interessant wird es eigentlich erst, wenn du die Taktrate 30% oder mehr anhebst. Hier braucht es aber auch mehr Kernspannung. Und dann wird es richtig fies.
Viel sinnvoller wäre es, wenn zB nur ein Thread Last erzeugt, die Ressourcen ungenutzter Kerne zu verwenden, anstatt das Netburst Prinzip zu reloaden. Denn mehr ist der Turbo Mode im Grunde nicht.

 

[KILLTHIS]

Vorsichtig mit solchen Formulierungen! Das kann rechtlich schnell mal gefährlich werden.

Ich sagte nur, mich würde es nicht wundern, was nicht heißen soll, dass ich es explizit unterstelle. Es ist eben nur meine Meinung, die werde ich doch wohl noch veräußern dürfen. Wenn ich falsch liege, dann sehe ich das auch gerne ein und nehme meine Aussage umgehend zurück. Aber bis dahin bleibt das meine Meinung.

 

[che new]

Vorsichtig mit solchen Formulierungen! Das kann rechtlich schnell mal gefährlich werden.

Wurde hier nicht mal ein INQ Link geposte, der belegt dass Intel in der Vergangenheit bereits Magazine in der Berichterstattung beeinfluss hat? Da setzt ich doch glatt einen drauf und vermute nicht nur sondern sage, Intel hat Magazine bestochen. ;-)

 

[Wolla]

Der INQ hat auch 30.000 Punkte bei 3DMark '06 für den Barcelona behauptet :P

 

[che new]

Der INQ hat auch 30.000 Punkte bei 3DMark '06 für den Barcelona behauptet :P

Die Aussagen stammen von einem Intel-Sprecher (Zitate), wenn es nicht der Wahrheit entsprechen würde hätte Intel die Möglichkeit dagegen vorzugehen.
http://www.hardwareluxx.de/community/showpost.php?p=11725124&postcount=372

 

[[TLR]Snoopy]

Ich habe nun auch nochmals etwas Dampf abgelassen bei PCGH über diesen TDP = Verbrauch mist in deren News.
Nun haben sie wenigstens das Wort Verbrauch raus genommen, aber die News liest ja eh keiner mehr und verschwindet ins Archiv.

http://extreme.pcgameshardware.de/k...neue-phenom-ii-cpus-tdp-limit-erreicht-5.html

 

[Stefan Payne]

Aber warum sollte AMD nicht ebenso beispielsweise den Turbomodus aufgreifen...

Weil die Architektur darauf nicht vorbereitet ist, außerdem kostet ein entsprechender Modus Geld, das AMD nicht hat.

@[TLR]Snoopy
Das Problem bei PCGH sind eher die völlig unfähigen Newsschreiber, die nicht wirklich viel Ahnung haben und anscheinend auch kein Interesse daran haben, qualitativ brauchbare News schreiben zu wollen...
Die 'Intel News' werden wohl eher von den Profis geschrieben, die AMD News überlassen sie dann die externen Aushilfskräfte.
Achte mal ein wenig auf den Schreiber, ich würde wetten, das du dich über vieles von diesen "Aushilfskräften" aufregen würdest...

 

[fdsonne]

Turbo Mode ist keine wirklich smarte Lösung. AMD designed in erster Linie Server Chips. Und dort wird sowas idR sowieso nicht verwendet. Das hat vor allem thermische Gründe. Zudem kann sich die Energieeffizienz des Chips verringern.
Bis auf eben die Zeit, wo du in einem konkreten Szenario mehr Performance bekommst, hat der Turbo Mode keinen Vorteil. Es ist im Endeffekt lediglich ein Benchmark Feature.

Ich bin arbeitsbedingt bei sowas ein wenig gebrantmarktes Kind, bei uns lief das lange Zeit so, das bei Neuanschaffung keine expliziten Hersteller angegeben werden durften sondern für die Leistung nur Benchmarkpunkte zählten...
Und wenn ich weis, das ein ca. 3GHz DualXeon Server so und so viele Benchmarkpunkte bekommt, und ich genau so weis, das das 2,66GHz Modell im Turbomodus mit 3,06GHz auch unter Volllast aller Cores arbeitet, dann kann ich ja getrost zum kleinen und deutlich günstigeren 2,66GHz Modell greifen...

So mein ich das, also ganz soo schlecht find ich den Turbomodus gar nich mal...Wobei mir aber dennoch rätzelhaft ist (außer vllt weils Marketingtechnisch gut klingt) warum Intel nicht sofort 3,06GHz angelegt hat in besagtem Szenario...

Schau dir mal an, woran IBM momentan forscht. Einzelne Bereiche einer Architektur mit deutlich höheren Frequenzen als normal laufen zu lassen. Und hier reden wir über höhere zweistellige GHz Werte. Das ist imo weitaus interessanter als Intels plumper Ansatz, den du mit jedem Modell mit offenem Multiplikator auch problemlos in Software umsetzen kannst.

Da geb ich dir natürlich recht, mit nem offenen Multi kann das fast jeder selbst machen, aber wie viele Leute OC'en denn überhaupt? Das macht wenn dann nur ein kleiner einstelliger Prozentbereich der Gesamtmasse...
Und gerade im Firmenumfeld ist OC idR sowieso kein Thema

Ja. Nur skaliert nicht jede Anwendung linear mit dem Takt. Und ein bis zwei Stufen bringen dir auch nicht viel. Interessant wird es eigentlich erst, wenn du die Taktrate 30% oder mehr anhebst. Hier braucht es aber auch mehr Kernspannung. Und dann wird es richtig fies.
Viel sinnvoller wäre es, wenn zB nur ein Thread Last erzeugt, die Ressourcen ungenutzter Kerne zu verwenden, anstatt das Netburst Prinzip zu reloaden. Denn mehr ist der Turbo Mode im Grunde nicht.

Ich sag mal so, die kleinen Modelle laufen teilweise auch mit 30%+ mehr Takt ohne Spannungserhöhung, sprich hier würde ein derartiger Turbo-Modus sogar weit mehr als nur 2-3 Stufen zulassen...
Und warum soll ich ein großes Modell kaufen, wie beispielsweise oben das Xeon Modell, wenn ich 3GHz anpeile aber gleiches mit dem 2,66GHz Modell erreichen kann?

@Stefan Payne
Neja wenn ein untertakten im idle Modus möglich ist, wäre eine derart einfache Turbo implementierung ebenso möglich, vor allem, wenn im Lastzustand sowieso mindestens eine Multi Stufe hoch gesprungen wird, gibt es ja den normalen Std. Takt eigentlich gar nicht mehr, wenn man so will...

 

[Opteron]

Weil die Architektur darauf nicht vorbereitet ist, außerdem kostet ein entsprechender Modus Geld, das AMD nicht hat.

AMD hat schon ein Patent, das ähnliches beschreibt, eventuell ist das beim Bulldozer eingebaut .. mal abwarten.

ciao

Alex

 

[Stefan Payne]

Ja, eben, das sagt ich ja.

@fdsonne
Du hast aber das Problem, das nicht alle Cores gleich gut sind und gerade AMD so langsam ein echtes Problem mit der Architektur hat.
Bei den kleinen ginge ein Turbomode um 1-2 Stufen auf jeden, das wär kein Problem, aber beim Phenom 955 oder dem kommenden 965 hätte mann schon ein Problem.

Im 'Turbo Mode' müsste der 955 ja 3.6GHz packen, der 965 sogar 3,8 GHz und das ganze unter 'AMD Bedingungen', was nicht so ganz einfach sein dürfte...

OK, vielleicht könntens sogar 1 oder 2 Kerne, aber wie markiere ich jetzt die Kerne, die den Turbo Mode packen würden??