Wird AMD permanent gegenüber Intel in Reviews benachteiligt? Bitte ersten post lesen

[[HOT]]

Jo, dachte mir schon, dass das missverstanden wurde. Total bescheuert ist eigentlich nur, auf die doppelte Performance zu schließen .
Ich korrigiere meine 10% auch gerne auf 20 . Ist halt unklar.

 

[redfirediablo]

Hier mal wieder was für das Messer in der Tasche:

AMD Bashing par excellence

ein paar Auszüge

faking Shanghai versus Xeon benchmark results

There is only one small thing that AMD keeps on forgetting - if Intel takes AMD to court in a bid to invalidate AMD’s x 86 licenses, we wonder that will actually stand on AMD’s side of the bench? More and more people are leaving the company and the amount of skeletons they carry around is something that competition can easily scoop out.

Anmerkung: gestern wurde seitens AMD nochmal ausdrücklich betont das Intel nur Angst und Schrecken verbreiten will und der Deal mit den Arabern innerhalb aller Lizenzbedingungen liegt. Deshalb klagt ja Intel auch nicht sondern blubbert nur.

Der gleiche Typ schwafelt was von 50% weniger Stromaufnahme beim 55nm GT200b von Nvidia, der ja angeblich in ein paar Tagen kommen soll, gegenüber der 65nm Variante. Sehr wahrscheinlich, wenn man sich den G92b anschaut.

 

[Opteron]

Der gleiche Typ schwafelt was von 50% weniger Stromaufnahme beim 55nm GT200b von Nvidia, der ja angeblich in ein paar Tagen kommen soll, gegenüber der 65nm Variante. Sehr wahrscheinlich wenn man sich den G92b anschaut.

Hej immer fair bleiben, vielleicht takten sie den 200b ja auch noch runter
Ansonsten "Theo" ... wenn ich den Namen schon sehe bekomm ich ... ;-)

 

[mr.dude]

Da gehts schon los man kanns nicht 1:1 vergleichen, da ct zwar immerhin den neuesten Beta Compiler benützt, aber sonst nichts optimiert. Vor allem fehlen die SmartHeap Libraries.

Welche willst du denn? Entsprechende Bibliotheken sind beim ICC afaik sowieso dabei. Hat auf die Ergebnisse imo auch keinen grossen Einfluss. Speicherreservierung und -freigabe sollte zugunsten der Performance immer noch ausserhalb kritischer Sequenzen erfolgen. So "smart" werden die Programmierer wohl gewesen sein. Und glücklicherweise hat C bzw C++ immer noch keinen Garbage Collector.

Jo, dass Du jetzt langsam in astronomischen Größenordnungen daneben liegst.
Der 6Kerner kommt auch in 45nm .. schau mal mit wieviel Takt die Dunningtons bei Intel laufen ...

Ähmm, du hast die nachfolgenden Sätze überhaupt nicht gelesen?

So oder so hat ein 6Kerner ein andres Problem ... erhöhten Verwaltungsaufwand. Bei 6 Kernen bekommt jeder Kern weniger Zugriff auf den L3 + RAM Bandbreite. Der L3 wird nur per round-robin verwaltet und die beiden unganged Kanäle ... tja ... 1 Kanal für 3 Kerne, anstatt 2 ... das gibt keine ideale Skalierung wie Du sie gerne hättest. Du vergißt da also "ein paar" Parameter ...

Nochmal, was genau verstehst du denn an den Worten grob und oberflächlich nicht? Die ganzen Ausführungen hättest du dir sparen können, weil sie nichts zum Kontext beitragen. Irgendwie ist dir das scheinbar erst am Ende deines Beitrages aufgefallen. Vorher eventuell erstmal die Beiträge komplett durchlesen? Übrigens, ich würde meine Rechnung nicht als worst-case für Intel bezeichnen. Ganz im Gegenteil. Da könnte man Shanghai noch deutlich besser machen. Ein worst-case Szenario für AMD könnte jedenfalls genauso hineininterpretiert werden. Denn wie gesagt, Speicher kann durchaus mehr als 10% ausmachen. Und auf Compiler sind wir auch noch nicht eingegangen. Da gibt es genug Spielraum verschiedener Switches. Würde mich jedenfalls nicht wundern, wenn c't sogar fast Switches für FP verwendet hätte. Turbo Modus war auch aktiv. Ob das bei den Xeons der Fall sein wird, ist ungewiss. Die kommende Fiorana Plattform von AMD soll ja auch nochmal einiges an Leistung freisetzen. Usw...

Warum ein Vergleich der schnellsten CPUs der Hersteller plötzlich Schwachsinn ist (seit Intel wieder vorne liegt, früher war das ja nicht so) ist mir ehrlich gesagt schleierhaft.

Es geht um die konkreten Begleitumstände, nicht um den Vergleich ansich. c't hat Nehalem mit einem Desktop Setup für einen Server Benchmark getestet. Und das nicht mal spec konform. Daher ist das ganze relativ sinnfrei.

Alle reden hier immer nur davon das man dieses mit jenem nicht vergleichen kann bzw soll. Du genauso. warum sollte man nur taktgleiche CPUs vergleichen?

Weil es erstens noch keinen 3,2 GHz Nehalem Xeon gibt und zweitens nächstes Jahr auch noch höher getaktete Shanghai Opterons kommen. Deshalb.

Bin da eigentlich auch auf Devil Ag Linie, der Vergleich ist absolut ok, einen K10.5 mit DDR3 gibts noch nicht, und einen Opteron mit DDR3 gibts noch länger nicht ... wieso sollte man das dann nicht vergleichen dürfen ...

DDR2 und DDR3 macht gar nicht mal so viel aus. Es geht darum, dass Intel bei Servern idR FB-DIMMs einsetzt und nicht unbuffered DDR3. Selbst registered RAM, wie bei AMD üblich und bei Intel mit DDR2/3 als Option, macht nochmal einen nicht zu unterschätzenden Unterschied zu dem c't Test.

@bawde
Eine normale Schriftgrösse tut's auch.

 

[Opteron]

Nochmal, was genau verstehst du denn an den Worten grob und oberflächlich nicht?

Ich versteh die nicht im Zusammenhang mit dem schönen Wort "Berechnung" ...

DDR2 und DDR3 macht gar nicht mal so viel aus. Es geht darum, dass Intel bei Servern idR FB-DIMMs einsetzt und nicht unbuffered DDR3. Selbst registered RAM, wie bei AMD üblich und bei Intel mit DDR2/3 als Option, macht nochmal einen nicht zu unterschätzenden Unterschied zu dem c't Test.

Hmm vielleicht lag darin Dein Fehler / Mißverständnis, Intel setzt beim Nehalem 2P Server keine FBDs ein.
Die kommen erst bei den MP/4P 8 Core Teilen im LGA1566, dann aber gleich 4 Kanal FBD2 ... darüber kann man mit den aktuellen Werten dann wirklich gar nichts vorhersagen ...

Übrigens, ich würde meine Rechnung nicht als worst-case für Intel bezeichnen. Ganz im Gegenteil. Da könnte man Shanghai noch deutlich besser machen.

Na dann bewerb Dich mal bei AMD ;-)

ciao

Alex

 

[mr.dude]

Ich versteh die nicht im Zusammenhang mit dem schönen Wort "Berechnung" ...

Daraus können wir ein lustiges Spielchen machen. Ich verstehe nicht, was du daran nicht verstehst. Jetzt du...

Hmm vielleicht lag darin Dein Fehler / Mißverständnis, Intel setzt beim Nehalem 2P Server keine FBDs ein.

Ok, eine Fehlerquelle weniger. Das ändert aber nichts an der grundlegenden Aussage, dass im Gegensatz zu Desktops bei Servern idR eben registered RAM zum Einsatz kommt. Oder ist dies beim Nehalem Xeon anders? Wäre zumindest vollkommen untypisch.

Na dann bewerb Dich mal bei AMD ;-)

Das war logischerweise auf die Rechnung bezogen, nicht auf die Hardware.

 

[Opteron]

Ok, eine Fehlerquelle weniger. Das ändert aber nichts an der grundlegenden Aussage, dass im Gegensatz zu Desktops bei Servern idR eben registered RAM zum Einsatz kommt. Oder ist dies beim Nehalem Xeon anders? Wäre zumindest vollkommen untypisch.

Du mit deinen grundlegenden Aussagen immer ...

Für mich ist Deine sog. "Berechnung" Worst Case, für Dich nicht. Dabei wirds wohl bleiben, bis Nehalem 2P Werte rauskommen.

Ich versuchs noch kurz zu erklären:

Warum worst case ? Die c't hat mal schnell unter 32bit mit nem beta Compiler ohne weiteres Extra Tuning (Compilerflags ausgenommen) gebencht.

Die AMD Ergebnisse sind dagegen direkt von AMD, wenn die nicht 100% ausgeschöpft haben was ging, weiss ich auch nicht weiter.

Oben schrieb ich z.B. schon von den Smartheap Libs. Wenn Du jetzt keine Ahnung davon bzw. deren Auswirkungen hast, dann kann ich das nicht ändern, und nein, die sind bei ICC nicht dabei. Du schreibst ja so schön "afaik" ... da geht Dein Wissen eben nicht weit genug.
Wenn Du das ändern willst, dann les mal ein paar (ältere) c't Artikel, umsonst gibts die aber nicht.

Stattdessen hier ein kleiner Werbespruch der Herstellerfirma:

The problem: Compiler runtime libraries allow only one thread at a time to be active in the heap. So on SMP systems, when multiple threads make concurrent heap requests, all but one will be blocked by the heap manager, nullifying the benefit of the extra CPUs. Worse yet, each time a thread is blocked, the OS invokes a context switch. The result: adding processors results in a vicious cycle of context switching that can prevent your app from scaling.

http://www.microquill.com/

So und nun überleg mal, was das für Auswirkungen hat ... der reg. Speicher auf dem Du Dich versteifst ist dagegen lächerlich. Anstatt CL5 hat man durch das Register CL6 ... sicherlich nicht schneller, aber verglichen mit der Library .. Peanuts.

Dazu kommt dann noch 32bit, das Du mal schnell, kurz in nem knappen Satz abhandelst .. .aber ne .. klar, überhaupt kein worst case ... und das böse reg. RAM ...

schönen Abend noch

Alex

 

[che new]

kA ob ich das nur geträumt habe, aber ich bin der Meinung irgendwo einen Vergleich gesehen zu haben, wo der Nehalem in 32bit schneller als 64bit war. Ich weiß noch wie ich mir dabei gedacht habe, was Intel nachwievor unter 32bit schneller bzw. immer noch unter 64bit schwächelnd?? Mal schauen vielleicht finde ich das nochmal (falls es nicht doch nur Traum war oder ich etwas durcheinander bringe).

 

[Opteron]

@che new:
Hmm, Spec wird bei Int immer 32bittig, bei FP 64bittig gebencht, eben weils jeweils schneller ist.
Bei den ct Werten hätte man jetzt durch die Smartheap Libs ein Plus bei INT und durch 64bit ein Plus bei FP.

Mit den Nehalem funktioniert auch Macro-OP-Fusion in 64bit, was Core2 nicht konnte, meintest Du vielleicht das ?

ciao

Alex

 

[mr.dude]

Warum worst case ? Die c't hat mal schnell unter 32bit mit nem beta Compiler ohne weiteres Extra Tuning (Compilerflags ausgenommen) gebencht.

Ich verstehe nicht, was daran "worst" für Intel sein soll. 64 Bit bietet zwar grundsätzlich mehr Performance Potenzial. Aber das spiegelt sich nicht in jeder Anwendung wieder. Man müsste erstmal klären, inwiefern sich 32 und 64 Bit spec unterscheiden. Und Beta Compiler ist eher ein Vorteil, weil dort idR bessere bzw umfangreichere Optimierungen vorhanden sind als in alten Versionen.

Die AMD Ergebnisse sind dagegen direkt von AMD

Das sagt nichts aus. Schau dir die Dell Ergebnisse an, die sind fast identisch. Als ausgeschöpft würde ich das noch lange nicht bezeichnen, zumal sich Unterbau und Software permanent weiterentwickeln. Intel muss den Unterbau überhaupt erstmal auf die Beine stellen.

Oben schrieb ich z.B. schon von den Smartheap Libs. Wenn Du jetzt keine Ahnung davon bzw. deren Auswirkungen hast, dann kann ich das nicht ändern

Och, mach dir mal keine Sorgen. Ich weiss vermutlich sogar noch 'ne Ecke besser, was Smart Heap Bibliotheken sind und wie sie funktionieren. Heap Verwaltung und die Notwendigkeit von Smart Heap Routinen ist vor allem dann wichtig, wenn du viel mit Containern arbeitest, Listen, Queues, Maps, etc. Specint/fp konzentriert sich hingegen auf Rechenleistung. Da bringt dir das vergleichsweise wenig. Ausser du verwendest eine Runtime, die reif für die Tonne ist.

Stattdessen hier ein kleiner Werbespruch der Herstellerfirma:

http://www.microquill.com/

Ach ja, ist es nicht schön, ein paar nichtssagende Werbeslogans in die Runde zu werfen? Hör zu, mal Klartext. Ich weiss mit Sicherheit einen winzig kleinen Tick besser als du über dieses Thema bescheid. Was dort steht, hat keinerlei Aussagekraft. Glaubst du, MicroQuill, wer immer das auch sein mag, sind die ersten, die sich dieser Problematik gestellt haben? Praktisch jeder moderne Compiler hat auch eine MT Runtime. Und wenn nicht Intel diese effizient implementiert, wer dann? Und jede ist letztendlich mehr oder weniger effizient. Dementsprechend greift man in bestimmten Fällen auf angepasste Lösungen zurück. Da lässt sich aber weder etwas pauschalisieren, noch konkretisieren, noch sonst irgendwas. Schau dir lieber mal ein paar Artikel auf CodeProject zu dem Thema an, wann wo Smart Heaps etwas bringen. Dort ist zumindest Substanz vorhanden. Ich habe zudem das Gefühl, du solltest dir zuerst mal anschauen, was Heap Speicher überhaupt ist und welchen Zweck er erfüllt.

 

[redfirediablo]

@ opteron und dude

eure diskussion hat mittlerweile nun überhaupt nichts mehr mit dem Thema zu tun. Im Interesse des Threads, diskutiert das bitte per PN aus oder macht nen eigenen Thread dafür auf, danke.

 

[Opteron]

Ok, dann nur noch ne Kurzzusammenfassung:

1. Smartheaps benützt man bei INT (steht auch schon oben), auch Intel benützt die bei eigenen Tests, so toll kann deren Compiler in dem Feld also nicht sein: http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20080915-05343.html
c't testet ohne -> professionelle INT Werte werden höher ausfallen.

2. Bei FP testet man wg. höheren Ergebnissen mit 64bit.
c't testet ohne -> professionelle FP Werte werden höher ausfallen.

Aus 1+2 folgt -> professionelle INT + FP Werte werden höher ausfallen.

Bis die 2P Systeme 2009 fertig sind traue, ich Intel auch zu reg. DDR3-1333 für die Server freizugeben -> hebt den reg. Nachteil ggü. unbuffered DDR3-1066 der c't auf.

Um die Disk. zu beenden würde ich auch vom "worst case" abrücken, und stattdessen von "suboptimal" sprechen.

Ich hoffe damit können wir das Thema beenden.

ciao

Alex

 

[che new]

Nur noch einen Zusatz, der Beta Compiler den c't benutze hatte bereits SSE4.2 Unterstützung. Daher vermutlich auch der Wahnsinnsvorsprung zum QX9770 (INT 49% bzw. FP 66%).

 

[mr.dude]

1. Smartheaps benützt man bei INT (steht auch schon oben), auch Intel benützt die bei eigenen Tests, so toll kann deren Compiler in dem Feld also nicht sein: http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20080915-05343.html
c't testet ohne -> professionelle INT Werte werden höher ausfallen.

"Bla bla ... ich weiss eigentlich gar nicht, wovon ich spreche". Hättest du genauso schreiben können. Das bringt es besser auf den Punkt. Lass erstmal erkennen, dass du weisst, was Smart Heaps sind und wofür sie verwendet werden. Dann können wir eventuell weiterdiskutieren. Ansonsten macht das wenig Sinn. Du interpretierst da viel zu viel rein.
Übrigens, nur damit da das nicht vergisst, bei den AMD Tests kam ebenfalls keine spezielle Smart Heap Bibliothek zum Einsatz. Deinen Aussagen entsprechend sollte AMD dann auch noch toll an Performance zulegen. Kleiner Tipp, das wird dort genauso wenig der Fall sein.

1. Smartheaps benützt man bei INT (steht auch schon oben), auch Intel benützt die bei eigenen Tests, so toll kann deren Compiler in dem Feld also nicht sein: http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20080915-05343.html
c't testet ohne -> professionelle INT Werte werden höher ausfallen.

2. Bei FP testet man wg. höheren Ergebnissen mit 64bit.
c't testet ohne -> professionelle FP Werte werden höher ausfallen.

Heisst das also, INT läuft dann mit 64 Bit langsamer und FP hat keinen Vorteil durch Smart Heaps? Und wo steht, dass FP mit 64 Bit schneller ist? Sry, aber langsam machst du dich mit deinem scheinbar fehlendem Wissen und ohne Quellenangaben etwas unglaubwürdig.

 

[Opteron]

Übrigens, nur damit da das nicht vergisst, bei den AMD Tests kam ebenfalls keine spezielle Smart Heap Bibliothek zum Einsatz.

Guten Morgen:

Other Software: binutils 2.18
32-bit and 64-bit libhugetlbfs libraries
SmartHeap 8.1 32-bit Library for Linux

http://www.spec.org/cpu2006/results/res2008q4/cpu2006-20081024-05683.html

Heisst das also, INT läuft dann mit 64 Bit langsamer und FP hat keinen Vorteil durch Smart Heaps? Und wo steht, dass FP mit 64 Bit schneller ist? Sry, aber langsam machst du dich mit deinem scheinbar fehlendem Wissen und ohne Quellenangaben etwas unglaubwürdig.

Gähn ... Du weisst was Benchmarks sind ? Anscheinend nicht ... aber macht ja nichts, ich erklärs Dir:

Also ein "Benchmark", das sind die Bilder mit den vielen bunten Balken, die unterschiedlich lang sind. Jeder Hersteller macht solche Bildchen, und damit die Balken schön lange sind, versucht jeder Hersteller möglichst viele Punkte zu erzielen. Denn je mehr Punkte, desto länger der Balken, und je länger der Balken desto mehr Kunden, denn die Kunden kaufen gerne das vermeintlich längste, äh. beste Produkt.

Wenn Du also so ein Bildchen siehst, und es auf Daten eines Herstellers basiert, dann weisst Du, dass die Balken laaaang sind, so lange wie es offiziell erlaubt ist und man das Produkt auch so kaufen kann. Technische Kniffe sind erlaubt, solange man sie angibt. Wenn Du jetzt diese Angaben mehrere Systeme vergleichst, dann stellst Du schnell fest: " Hej bei den INT Benches sind grundsätzlich immer so SmartHeap Sachen dabei und die FP Balken sind immer mit 64bit erzielt worden."

Tja jetzt die 1.000.000 Euro Frage: Warum ...

Einfache Lösung. Wenn Du Dich an die laangen Balken von oben erinnerst, dann kommst Du mit logischen Denken zu dem Schluss, dass bei den INT Bildchen ohne SmartHeap tote Hose herrscht und bei FP ohne 64bit keine richtige Stimmung aufkommt. Das will aber natürlich keiner, denn dann wäre das Produkt uninteressant, keiner würde es kaufen, und die Firma bliebe auf der Ware sitzen.
----

So das wars jetzt definitiv von mir zu dem Thema. Hab oben ein Angebot gemacht, aber das wurde wohl übersehen.

Sorry @red fürs letzte OT

over & out

Alex

 

[[HOT]]

Für sowas bin ich zwar kein Experte, aber Smartheap-Bibliotheken haben AFAIK auch Nachteile. In 64Bit können sie sogar sehr kontraproduktiv sein. Intel schreibt die beim Benchmarken für 32Bit vor, AMD hingegen setzt eher auf Benchmarking ohne Smartheap, wohingegen aber beide Hersteller 32Bit als Benchmarkplattform bevorzugen.
"Sauberes" Benchmarking geht wahrscheinlich nur ganz ohne Smartheap und in 64Bit. Praxisrelevant ist sowieso nurnoch 64Bit.

 

[mr.dude]

@Opteron
Hier mal ein Vergleich mit und ohne Smart Heap Bibliothek. Ist ja unglaublich, was da für Performancepotenzial mit weniger als 5% Unterschied schlummert.

Ausserdem solltest du mal genau hinschauen.

SmartHeap 8.1 32-bit Library for Linux

Da frage ich mich doch, was das unter x86-64 überhaupt für Auswirkungen hat. Oder anders gefragt, du beschwerst dich, dass c't ohne Smart Heap Bibliothek (wenn das denn überhaupt der Fall war) unter x86-32 Performance fehlt, die sie unter x86-64 sowieso nicht hätten?

Zum Rest deiner Entgleisungen halt ich einfach mal meine Klappe. Ist irgendwie nur noch peinlich...

 

[Andy65]

Ist irgendwie genauso wie in der politik da wird auch immer mehr versprochen als gehalten wird. Nur mal nebenbei wo ich das ganze mal wieder ne zeitlang mitgelesen hab.

 

[redfirediablo]

Das mal zum Thema AMD würde irgendwelche Benchmarks faken, der Inquirer rudert zurück, auch wenn er sich eine letzte Harke nicht sparen kann:

http://www.theinquirer.net/gb/inquirer/news/2008/11/14/amd-vs-intel-shanghai-shapes

Beim 161 vs 264 Watt Vergleich unterschlägt er natürlich wieder, dass das Intel System deutlich weniger Speicher eingebaut hatte.

 

[HardlineAMD]

The Inquirer...
Wer diese Seite anklickt und den Müll dort auch noch für bare Münze nimmt, hat ein wirklich großes Problem.

Sachliche und fundierte Artikel kennt diese mit der BILD-Internetwurst vergleichbare Seite nicht.

 

[Opteron]

Bin gerade über den PC Welt Artikel gestolpert:

http://www.pcwelt.de/start/computer/prozessor/tests/185273/intel_core_i7_prozessor/index6.html

Ist eigentlich ein i7 Beitrag, und auch nur ein einziges Spiel, aber was auffällt ist, dass die alten Phenoms bei der Min fps Rate schon sehr gut dastehen. Der 9950er hat ne höhere Min fps als der QX9650 ...

Im Durchschnitt liegt der dann zwar 30 fps vorne, aber Lags gibts bekanntermaßen nur wenn die Min fps einbrechen

Ich hoffe, dass so ein Test auch später mit dem Deneb kommt.

ciao

Alex

 

[Undertaker 1]

Und das die Wolfdale nocheinmal 20-30fps vorne liegen, hast du auch bemerkt Das kann man wohl in die Tonne werfen, min-fps Tests machen eigentlich nur in einer "x % unter 25fps" Form Sinn, alles andere schwankt einfach zu sehr von Durchlauf zu Durchlauf.

 

[Opteron]

Und das die Wolfdale nocheinmal 20-30fps vorne liegen, hast du auch bemerkt Das kann man wohl in die Tonne werfen, min-fps Tests machen eigentlich nur in einer "x % unter 25fps" Form Sinn, alles andere schwankt einfach zu sehr von Durchlauf zu Durchlauf.

Ne, das gehört dazu, da scheint der FSB bei den Quads dicht zu machen.

Aber darum gehts ja hier im Thread, überall in den Tests von Phenom gegen Intel Quad wird der C2Q hochgejubelt, aber dass anscheinend eine Min fps Schwäche besteht, liest man nirgends. Der C2D darf gerne noch besser sein

Welche Fragen sich aber natürlich stellen ist, ob das auch bei andren Spielen so ist und wie es bei andren Auflösungen bzw. mit den von Dir angesprochenen Schwankungen ausschaut.

ciao

Alex

 

[che new]

Das kann ja wirklich kein Zufall mehr sein, wieder und wieder kommt das mieseste und blamabelste AM2+ Board ever zum Einsatz, das Gigabyte 790FX DQ6. Beim S775-System wird "überraschenderweise" nicht auf Gigabyte vertraut, es kommt das sparsamste X38 von ASUS mit EPU zum Einsatz (aber immerhin macht dieses Board auch gleich dem i7 System schwer zu schaffen).

Wenn man die überflüssigen 50 Watt des Design-Unfalls und Umweltdisasters 790FX DQ6 abzieht, sehen die Verbrauchswerte des Phenom-Systems gar nicht mal übel aus. Nur gut das dieser Technik-Schrotthaufen mittlerweile aus dem Verkehr gezogen wird, vielleicht stecken sogar Umweltbehörden dahinter. Bleibt nur zu hoffen, das Gigabyte in Zukunft die Finger vom AMD-Entusiasten-Bereich lässt und die Menschheit mit solchen Erderwärmer verschont.

 

[Undertaker 1]

Ne, das gehört dazu, da scheint der FSB bei den Quads dicht zu machen.

Das lässt sich sofort widerlegen, denn einerseits würde dies maximal zu gleichen FPS von Dual- und Quadcore führen und zum anderen ist unsinnig, dass dann ein Q9450 nicht schneller als ein Q6600 ist - trotz mehr Cache und mehr FSB. Der QX9770 wiederum skaliert geradezu exponentiell. Nein, da wurden definitiv Schugrößen gemessen, oder kannst du dir die angesprochenen Punkte anders erklären?

 

[Opteron]

Das lässt sich sofort widerlegen, denn einerseits würde dies maximal zu gleichen FPS von Dual- und Quadcore führen und zum anderen ist unsinnig, dass dann ein Q9450 nicht schneller als ein Q6600 ist - trotz mehr Cache und mehr FSB. Der QX9770 wiederum skaliert geradezu exponentiell. Nein, da wurden definitiv Schugrößen gemessen, oder kannst du dir die angesprochenen Punkte anders erklären?

Jo, zumindest beim Q9450, da bleibt wohl bei den FSB333 ne Menge wg. Asynchronbetrieb in der Northbrige hängen, RAM läuft mit DDR3-1066:

Als Speicher verwenden wir DDR3-SDRAM des Typs OCZ OCZ3P1600EB2GK. Die beiden 1-GB-Module des Dual-Channel-Kits sind für bis zu 200 (effektiv 1600) MHz Takt ausgelegt. Bei uns laufen die Speicherriegel mit einem Datentakt von 1066 MHz und CL5-Timings (5-5-5-16).

Wo es aber abstruß wird:

Einzige Ausnahme: Steckt der Core 2 Extreme QX9770, er läuft ab Werk mit einem Front Side Bus von 400 MHz, in der Asus P5E3 Deluxe, lassen wir die OCZ-Module mit vollem Takt, aber reduzierten Zugriffszeiten arbeiten.

Geb Dir also Recht -> Blödsinn ³, einzigstes Fazit ist wohl, dass man den RAM / FSB synchron halten sollte (wobei ich eigentlich dachte, dass das nicht soviel ausmachen würde ... )

ciao

Alex

 

[Undertaker 1]

Asynchronität kostet nach eigenen Tests gar nix, der Ram asynchron zum FSB getaktet macht das System bei höherem Speicher- als FSB-Takt sogar schneller als 1:1! Desweiteren wären davon die Dualcores in gleicher Weise betroffen.
Es bleibt dabei, die min-fps dort sind in jeder Hinsicht unerklärbar - und das bereits innerhalb einer CPU-Reihe.

 

[Korn86]

Wenn man die überflüssigen 50 Watt des Design-Unfalls und Umweltdisasters 790FX DQ6 abzieht, sehen die Verbrauchswerte des Phenom-Systems gar nicht mal übel aus. Nur gut das dieser Technik-Schrotthaufen mittlerweile aus dem Verkehr gezogen wird, vielleicht stecken sogar Umweltbehörden dahinter. Bleibt nur zu hoffen, das Gigabyte in Zukunft die Finger vom AMD-Entusiasten-Bereich lässt und die Menschheit mit solchen Erderwärmer verschont.

Muhahahaha wie geil, ich schmeiße mich weg

Besser hätte man es nicht ausdrücken können

Wobei ich trotzdem nicht glaube das ein Phenom gegenüber einem Core 2 Quad in Sachen Stromverbrauch besser dastehen würde wenn man nun eine MSI DKA 790GX Platinum oder ähnliches zum Testen benutzen würde, aber zumindest wären die gemessenen Werte nicht mehr so unglaublich hoch wie im Moment

 

[smoothwater]

Das kann ja wirklich kein Zufall mehr sein, wieder und wieder kommt das mieseste und blamabelste AM2+ Board ever zum Einsatz, das Gigabyte 790FX DQ6. Beim S775-System wird "überraschenderweise" nicht auf Gigabyte vertraut, es kommt das sparsamste X38 von ASUS mit EPU zum Einsatz (aber immerhin macht dieses Board auch gleich dem i7 System schwer zu schaffen).

Wenn man die überflüssigen 50 Watt des Design-Unfalls und Umweltdisasters 790FX DQ6 abzieht, sehen die Verbrauchswerte des Phenom-Systems gar nicht mal übel aus. Nur gut das dieser Technik-Schrotthaufen mittlerweile aus dem Verkehr gezogen wird, vielleicht stecken sogar Umweltbehörden dahinter. Bleibt nur zu hoffen, das Gigabyte in Zukunft die Finger vom AMD-Entusiasten-Bereich lässt und die Menschheit mit solchen Erderwärmer verschont.

Das kann ich so nicht stehen lassen. Das einzige Manko dieses Boards ist der hohe Stromverbrauch. Doch die reichhaltigen Features, die schon sehr frühe Biosreife bzgl. Bugs (siehe Sammelthreads im Vergleich zum Asus-Pendant: zB 8GB und CF) und der (damals) niedrige Boardpreis sind auschlaggebender. Das man bei Benchmarks bzgl. Stromverbrauch lieber auf AMD selbst hätte hören sollen (die empfehlen ja nicht umsonst MSI-Boards), steht ausser Debatte.
Das Gigabyte die Finger von lassen sollte, wär Blödsinn, da die derzeitigen Stromspartechniken in den aktuellen Intel-Boards durchaus überzeugen können und lediglich einer Portierung/ Verbesserung bedürfen.

 

[[HOT]]

Bei GB AM2+-Platinen von BIOS-Reife zu sprechen ist schon echt ein Hohn, sry. Ich hatte das DS5, alle 7er SB600-Bretter setzen im Prinzip auf das gleiche BIOS. Der einzige Unterschied ist, dass das DQ6 eine Version Vorsprung hat, aber ich glaube nicht, dass das alles beseitigt... ich hatte zu dem Thema schonmal was geschrieben und will mich nicht nochmal darüber aufregen. Nur soviel: Zwischen dem GB, das ich vorher hatte und dem Asrock, das ich jetzt habe, liegen Welten in Sachen BIOS und Stromverbrauch. Vor allem hat AOD sogar vollen Nutzwert auf dem Asrock, das bietet nahezu den vollen Funktionsumfang fehlerfrei. Es liegt nicht an AOD, wenn bestimmte Sachen nicht laufen...