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

Status
Für weitere Antworten geschlossen.
Noch ein Beispiel

cpux3p.jpg


http://www.agner.org/optimize/optimizing_cpp.pdf Seite 115

Besonders interessant ist Seite 119

Unfortunately, the CPU detection mechanism in Intel compilers has several flaws:

• The best possible version of the code is chosen only when running on an Intel
processor. The CPU dispatcher checks whether the processor is an Intel before it
checks which instruction set it supports. An inferior version of the code is selected if
the processor is not an Intel, even if the processor is compatible with a better version
of the code. This can lead to a dramatic degradation of performance on AMD
processors.


• Explicit CPU dispatching works only with Intel processors. A non-Intel processor
makes the dispatcher signal an error simply by performing an illegal operation that
crashes the program.

• The CPU dispatcher does not check if XMM registers are supported by the operating
system.

I have had a long correspondence with Intel about this. They tried to explain away the fact
that performance is crippled on non-Intel processors until I had provided piles of evidence to
prove my point. Yet, they refused to change the way their CPU dispatcher works.

I just wonder how many benchmark tests have been made comparing Intel and AMD CPUs
on software that - unbeknownst to the tester - was build with an Intel compiler. Some
published benchmarks have evidently been based on the Intel compiler.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich hab mir jetzt nicht die kompletten 17 Seiten durchgelesen und daher werf ich das einfach mal in die Runde:

Ihr beachtet aber alle auch schön das der Phenom (K10) im Endeffekt eine "aufgebohrte" und modifizierte Varitation des Athlon 64 (K8) ist?
Und dafür, das dass Ur-Design des K10 also der K8 bereits 5 Jahre alt ist, schlägt sich der Phenom verdammt gut gegen die Konkurenz seitens Intel.
Und die jetzigen C2D bzw. C2Q haben mit dem Ur-C2D, also dem Pentium M nicht mehr viel zu tun.
Ich würde erstmal abwarten was zum Nehalem Launch im Benchmark Sektor passiert und dann auf erste Tests warten. Und ausserdem hat AMD den Shanghai in der Hinterhand, ich will jetzt nicht rumorakeln aber die werden sicher um ihre Position wissen und sich mit dem Shanghai keine Pleite erlaub,wie damals beim Launch der X2900XT. Die war auch ein ziemlicher Papiertiger (gut schlecht würd ich jetzt auch nicht sagen) aber jeder hat sich davon mehr versprochen. Und ich denke doch das AMD da was feines vorbereitet hat um die Intel Jungs mal wieder von ihren hohen Rössern zu holen.
 
Es ist keine Optimierung auf bestimmte Architekturen möglich? Das widerspricht aber ganz stark dem was ich so zu lesen finde:

http://www.zdnet.de/builder/program/0,39023551,39160306-1,00.htm
Ich kann mich gerne nochmal wiederholen, vielleicht verstehst du es irgendwann noch.
Wovon du sprichst, sind in erster Linie Mikrooptimierungen. Die werden nicht über cpuid zur Laufzeit gesteuert, sondern bereits beim Kompilieren festgelegt (mal abgesehen von VMs). Dh, da der Nano hardwaretechnisch gleich bleibt, bleibt auch das Laufzeitverhalten hier gleich.
Wie HOT schon sagte, Mikrooptimierungen wirken sich heutzutage nur noch gering von Architektur zu Architektur aus. Wirklich gravierende Unterschiede entstehen erst, wenn andere Befehlssätze, Optimierungsgrade oder Algorithmen verwendet werden. Auch wenn dir das vielleicht nicht bewusst ist, du hast eine völlig falsche Vorstellung von "besser schmecken".

Und das der Weg über den Nano nichts aussagt, habe ich ja schon mehrfach erwähnt. Siehe auch meinen letzten Link, mit dem Nano kannst du Optimierungen nicht von Ausbremsungen unterscheiden.
Doch, kannst du, siehe pcmark05. Es gab auch mal einen schönen Artikel, wo Opteron gegen P4 getestet wurde mittels cpuid Patch, und wo der Opteron anschliessend deutlich bessere Ergebnisse lieferte. Mal schauen, ob ich den Link wiederfinde.

"Allein das Verändern der Prozessor-Taktrate über den Multiplikator bei ansonsten identischen Prozessoren kann dazu führen, dass Code verändert werden muss, um optimale Performance zu erzielen."
Das ist totaler Blödsinn. Dass jemand entsprechend der Taktrate optimiert, habe ich noch nie gehört. Entweder hat der Autor sich irgendwas unwissentlich aus den Fingern gesogen oder einige Sachen falsch verstanden.
Es ist richtig, dass man Timing bei Optimierungen berücksichtigt, aber das richtet sich ausschliesslich nach den Taktzyklen. Hängt also nicht von der Taktrate ab. Eine immer wieder gestellte Frage ist zB, ob man lieber Penalties durch Branch Misprediction oder Cache Misses in Kauf nimmt. Was performanter ist, hängt nämlich von der Architektur ab. Einen interessanten Artikel gibt es zB hier.
Wie auch immer, all das gehört ebenfalls zur Mikrooptimierung.

Nutze ich eine AMD-CPU, wäre der Intelpfad langsamer, nutze ich eine Intel-CPU, der von AMD. Nutze ich nun einen Via Nano, für den es keinen eigenen Pfad gibt, kann ich allein aus der Performance des Nano auf dem Intel- und dem AMD-Pfad nicht aufschlüsseln, ob dieser Unterschied durch eine etwaige bewusste Benachteiligung von AMD-CPUs bedingt ist oder schlicht durch den Fakt, dass der AMD-Pfad schlechter zur Architektur des Nano passt als der Intelpfad.
Nochmal, du versuchst es immer wieder auf AMD zu reduzieren. Darum geht es aber gar nicht. Es geht darum, ob "GenuineIntel" Code Nicht-Intel CPUs bewusst vorenthalten wird. Und zumindest bei pcmark05 ist dies eindeutig.

Ein ganz billiges Beispiel ist doch, wenn man versucht auf einer Core2 CPU eine Berechnung bzw. deren Daten soweit wie möglich im L2 Cache halten zu können, wärend es bei einem A64/Phenom mit IMC von Vorteil sein kann, sich hier nicht übermäßig einzuschränken und auch den Ram im größeren Umfang zu nutzen, da der Geschwindikeitsunterschied zwischen L2 und Ram geringer ist.
Bitte? Auch bei AMD ist der Unterschied zwischen L2 und RAM immer noch gewaltig. Nur nicht so gewaltig wie bei Intel. Am Prinzip, so viel effektive Daten wie möglich im Cache zu halten, ändert sich dadurch nichts.

Sry, wenn ich dir das so hart sagen muss, ist ja nicht das erste mal, aber deine Theorien und Thesen basieren auf sehr viel Halbwissen, teilweise falsch zitiert, teilweise vollkommen praxisfern.

Ihr beachtet aber alle auch schön das der Phenom (K10) im Endeffekt eine "aufgebohrte" und modifizierte Varitation des Athlon 64 (K8) ist?
Und dafür, das dass Ur-Design des K10 also der K8 bereits 5 Jahre alt ist, schlägt sich der Phenom verdammt gut gegen die Konkurenz seitens Intel.
Und die jetzigen C2D bzw. C2Q haben mit dem Ur-C2D, also dem Pentium M nicht mehr viel zu tun.
Im Endeffekt ist der Core2 auch nur ein aufgebohrter Pentium-M. Sicherlich sind die aktuellen Core2 CPUs (Penryn) nochmal einen Schritt weiter. Aber das Pendant dazu ist ja auch der K10.5, nicht der K10. K10 und K8 haben jedenfalls so viel gemein (oder auch nicht) wie Core2 und Pentium-M.
 
Neues Thema, CB testet Atom-Plattform gegen einé AM2-Sempron-Plattform: http://www.computerbase.de/artikel/...atom_nettops/10/#abschnitt_sonstige_messungen


Im Leerlauf vebraucht das AM2-System 8 Watt mehr als das Atom-System. Doch wie kommt das, wenn Leute wie ich ständig felsenfest behaupten man könne mit einem X2/Sempron-System ein Atom-System im Leerlauf unterbieten oder zumindest gleichziehen?

Ganz einfach:
Man (Computerbase) wähle nicht einen Chipsatz der aktuellen Generation, auch keinen der Vorgänger-Generation, nein man gräbt einen uralten NV-Chipsatz aus, der längst vom Markt ist (sprich man kann ihn nicht mehr kaufen) und (un)glücklicherweise die Eigenschaft besitzt 8-10 Watt mehr als z.B. ein NV 630a-Chipsatz zu verbrauchen.

Computerbase hätte genauso gut einen erhältlichen Chipsatzen wie den 6150SE(6100)/430(410/405) -> MCP/1-Chips-Design, 630a/70XX oder 690G nehmen können, die liegen in der gleichen P/L-Klasse, nur mit dem Unterschied, dass sie noch erhältlich sind... das "Hauptproblem" wäre dann nur, dass allesamt deutlich sparsamer sind. Das hätte ein anderes evtl. unerwünschtes Bild abgegeben.

Aber keine Panik, wenn ich die nächsten Wochen zwischendurch etwas Zeit finde, hol ich das Versäumnis von CB, wenigsten einen Chipsatz für die AM2-Plattform zu wählen der noch erhältlich ist, nach. Ich denke ich werde mich für den, bei Stromsparer und Low-Kost-Käufern beliebten, Nv630a-Chipsatz entscheiden. ;)
 
Zuletzt bearbeitet:
Ich kann mich gerne nochmal wiederholen, vielleicht verstehst du es irgendwann noch.

Wie HOT schon sagte, Mikrooptimierungen wirken sich heutzutage nur noch gering von Architektur zu Architektur aus. Wirklich gravierende Unterschiede entstehen erst, wenn andere Befehlssätze, Optimierungsgrade oder Algorithmen verwendet werden. Auch wenn dir das vielleicht nicht bewusst ist, du hast eine völlig falsche Vorstellung von "besser schmecken".

Da vertraue ich Zdnet aber irgendwie eher als dir :)

Doch, kannst du, siehe pcmark05. Es gab auch mal einen schönen Artikel, wo Opteron gegen P4 getestet wurde mittels cpuid Patch, und wo der Opteron anschliessend deutlich bessere Ergebnisse lieferte. Mal schauen, ob ich den Link wiederfinde.

Bitte, sowas bestreite ich doch gar nicht. Es geht schlicht darum, dass du das eben auch nur mit einer AMD-CPU und nicht mit einem Via testen kannst.

Das ist totaler Blödsinn. Dass jemand entsprechend der Taktrate optimiert, habe ich noch nie gehört. Entweder hat der Autor sich irgendwas unwissentlich aus den Fingern gesogen oder einige Sachen falsch verstanden.
Es ist richtig, dass man Timing bei Optimierungen berücksichtigt, aber das richtet sich ausschliesslich nach den Taktzyklen. Hängt also nicht von der Taktrate ab. Eine immer wieder gestellte Frage ist zB, ob man lieber Penalties durch Branch Misprediction oder Cache Misses in Kauf nimmt. Was performanter ist, hängt nämlich von der Architektur ab. Einen interessanten Artikel gibt es zB hier.
Wie auch immer, all das gehört ebenfalls zur Mikrooptimierung.

Gerade Cache Misses sind ein sehr gutes Beispiel. Bei einem Yorkfield mit 12MB L2 Cache lassen die sich grundsätzlich weitaus häufiger vermeiden, sind aber andererseits durch den langsameren Ramzugriff fataler als bei einem Phenom. Soetwas lässt sich in einer Optimierung unterbringen und wäre ein klar architekturspezifisches Merkmal. Quervergleiche mit CPUs anderer Hersteller sind damit nichtssagend.

Nochmal, du versuchst es immer wieder auf AMD zu reduzieren. Darum geht es aber gar nicht. Es geht darum, ob "GenuineIntel" Code Nicht-Intel CPUs bewusst vorenthalten wird. Und zumindest bei pcmark05 ist dies eindeutig.

Nein. Es geht darum, ob "GenuieIntel Code" auf einer nicht-Intel CPU ebenfalls schneller wäre. Im PCMark05 kommt das wohl schlicht dadurch, dass dieser die Befehlssätze neuerer AMD-CPUs nicht kennt und darum nicht nutzt.

Bitte? Auch bei AMD ist der Unterschied zwischen L2 und RAM immer noch gewaltig. Nur nicht so gewaltig wie bei Intel.

Lies doch bitte, exakt das habe ich auch geschrieben.

Sry, wenn ich dir das so hart sagen muss, ist ja nicht das erste mal, aber deine Theorien und Thesen basieren auf sehr viel Halbwissen, teilweise falsch zitiert, teilweise vollkommen praxisfern.

Wenn du meine Postings wie gerade bewusst falsch verstehst, macht sich das natürlich auch sehr leicht. Soll ich damit bei dir jetzt auch anfangen? Ich denke nicht das das uns weiterbringt.

Im Endeffekt ist der Core2 auch nur ein aufgebohrter Pentium-M.

Hier fehlt dir wohl ne Menge Hintergrundwissen, vergleich die beiden mal bzgl. Superskalarität, der µOP Buffer und anderem, das ist weit mehr als eine simple Evolution.
 
Zitat von mr.dude Beitrag anzeigen
Im Endeffekt ist der Core2 auch nur ein aufgebohrter Pentium-M.


Ich dachte der Core2 basiert auf den Dothan...


achja f**k war ja ein mobile...:fresse:
 
Maaan, lies dir doch mal durch

-> http://www.forumdeluxx.de/forum/showpost.php?p=9824875&postcount=481

So ... was wird nun wahrscheinlich sein wenn man mit Via testet?

1. Die CPU bekommt genau so einen schlechten oder noch schlechteren Code wie AMD vorgesetzt, weil es eine nicht Intel CPU ist.

2. Deine These : AMD Code und Intel Code sind beide gleich gut, dem Via schmeckt der Intel Code nur architekturbedingt besser als der von AMD.

Darfst dir jetzt eins aussuchen und auch gerne die angeführten Tests und empirischen Daten widerlegen. Ansonsten kann man nur sagen, dass man mit einem Nano sehr wohl "versteckte" verschiedene Optimierungen des Intel Compilers in Benchmarks aussmachen kann.
 
Zuletzt bearbeitet:
Ich sage, dass das ganze einfach so nicht feststellbar ist, da zwei sich überlagernde Effekte auftreten. Das beide existent sind, zeigt übrigens auch dein Bild im Link, siehe die ersten 3 Zeilen:



Wärend alle Intel-CPUs mit der ersten Intel-Compilerversion gegenüber der Microsoft-Version zulegen können, verliert der AMD sogar minimal. Klarer Beweis für die Existenz architekturabhängiger Optimierungen.

Nocheinmal: Ich habe nicht gesagt, die Benachteiligung exisitiert/existiert nicht. Ich sage, euer vorgeschlagenes Testverfahren mittels eines Via Nano ist wertlos.
 
Zuletzt bearbeitet:
@che new

Zitat von kscr13
Eigentlich eine gute Idee, aber:
- Wieso nehmt ihr für den Sempron so ein bekifftes Board?
http://www.computerbase.de/forum/showthread.php?p=4650290#post4650290

Die Antwort von Sebastian - Redakteur "Ersteller dieses Themas"
Weils halt da war und für wenig Geld eigentlich alles bietet, was man in der Klasse erwartet. Wir reden hier von 30 Euro für Mainboard + IGP. Die nächst beste Alternative wäre ein Board mit GF7 / nF630 gewesen. Wie gesagt, das hier getestete Board war bereits vorhanden und passte eigentilch auch gut ins Testfeld (P/L).
http://www.computerbase.de/forum/showpost.php?p=4650435&postcount=14
 
Nocheinmal: Ich habe nicht gesagt, die Benachteiligung exisitiert/existiert nicht. Ich sage, euer vorgeschlagenes Testverfahren mittels eines Via Nano ist wertlos.

Was nun ? Existiert sie oder nicht ? Treff doch mal ne Aussage anhand der Faktenlage ! Wenn Via einen suobtimalen Code vorgesetzt bekommt ist es bei AMD nicht anders (was auch bewiesen wurde) und lässt auch tendenziell eine Vorhersage für AMD CPUs zu.

Es geht doch nur darum ob der Intel Compiler "nicht Intel CPUs" benachteilig und da ist es Wurscht ob man den Via mit IntelCPUID testet oder den AMD mit IntelCPUID. Die Kernaussage bleibt bestehen. Die Frage bleibt nur wieviel der AMD mit gepatchter Abfrage an Performance zulegen kann und das sind laut Diagramm bis zu ca 50 %.
 
Zuletzt bearbeitet:
@[TLR]Snoopy

Das dumme an CBs Test bzw. fadenscheinigen Rechtfertigung ist nur, dass es den uralten 6150/430 als stromhungriges 2-Chipsdesign längst nicht mehr gibt, und was es nicht gibt kann heute wohl kaum repräsentativ sein. Ich kann als Tester nicht einfach mit einer dreist-dämlichen Begründung in der Art "das 2-3 Jahre alte Board lag halt gerade hier herum" kommen, wenn es um aktuelle Low-Cost Stromspar-Plattformen geht. Es gibt den 6150SE/6100 nur noch als MCP sprich 1 Chip-Design, und dieser ist ähnlich sparsam wie der 630a/GF7 -> ~8 Watt sparsamer. Beide Chipsätze gibt es ab bzw. unter 30 Euro.

Fazit: Ich kann bei dem Redakteur entweder nur Faulheit, Inkompetenz oder bewusstes Handeln erkennen.


Edit: http://www.computerbase.de/artikel/hardware/prozessoren/2008/test_intel_atom_nettops/6/
Nvidia C51 (+ SB430) gibt nicht mehr, dieser wurde schon lange durch den MCP61 (6150SE/6100 inkl. SB430/405) ersetzt, später folgte MCP68 (70xx/630a).
 
Zuletzt bearbeitet:
Was nun ? Existiert sie oder nicht ? Treff doch mal ne Aussage anhand der Faktenlage ! Wenn Via einen suobtimalen Code vorgesetzt bekommt ist es bei AMD nicht anders (was auch bewiesen wurde) und lässt auch tendenziell eine Vorhersage für AMD CPUs zu.

Der Punkt ist, das suboptimal für Intel nicht suboptimal für AMD heißen muss. :) Siehe auch nochmal den von mir geposteten Ausschnitt aus dem Diagramm, wo die erste Intel-Compilerversion auf dem AMD selbst mit Intel-ID langsamer ist als der Microsoft-Compiler. Ich will hier nur einer unzulässigen Verallgemeinerung vorbeugen, schlechter auf Via -> schlechter auf AMD lässt sich so eben nicht sagen.
 
Ich will hier nur einer unzulässigen Verallgemeinerung vorbeugen, schlechter auf Via -> schlechter auf AMD lässt sich so eben nicht sagen.

Der Punkt ist : Code für nicht IntelCPUs vom Intelcompiler = suboptimal egal für welchen NichtIntelCPU, genau darum gehts es hier. Willst du abstreiten das AMD hier nicht benachteiligt wird ? Wie intepretierst du bitteschön die Ergebnisse der gepatchten Abfrage in diesem Guide ?

Mit dem Via kann man halt nur testen in welchen Benchmarks genau so eine Abfrage der CPUID stattfindet, unzulässige Geschwindigkeitsdifferenzen auftreten und damit die Objektivität eines solches Benches berechtigt anzweifeln.
 
Zuletzt bearbeitet:
Mit dem Via kann man halt nur testen in welchen Benchmarks genau so eine Abfrage der CPUID stattfindet

Bis hierhin: Jep

unzulässige Geschwindigkeitsdifferenzen auftreten und damit die Objektivität eines solches Benches berechtigt anzweifeln.

...aber das Geschwindigkeitsunterschiede auf dem Nano nix zeigen, hab ich doch schon mehrfach erklärt. Klar, du kannst dann wild spekulieren, aber besonders zielführend ist das ja nicht...
 
Was sollen sie denn bitte nicht zeigen? Das der Benchmark nicht objektiv ist (egal ob für VIA oder AMD) ? Was willst du denn noch ? Eine Aussage von Intel " Ja wir geben anderen Prozessoren einen anderen Code damit unsere besser dastehen" ? Ich gebs auf, der geneigte Leser soll sich bitte seine eigene Meinung bilden.
 
@che new
Ja genau, die Antwort des Redakteurs ist bezeichnend welche Qualität dieser Test hat, nämlich eher laienhaft als amateurhaft.
 
Was man mit Benches alles Türken kann ist hier zu lesen.
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1217539570
Ausgangspunkt für den Test war ein Vergleich zwischen dem Intel Atom und dem VIA Nano Prozessor, beides CPUs für den UMPC-Markt, den der Intel Atom gewann. Allerdings haben die Tester von Arstechnica ihren Testkandidaten etwas genauer auf den Zahn gefühlt und zwar auf eine äußerst clevere Art und Weise. Die Tester schnappten sich das VIA Nano System und gaukelten dem PCMark2005 über Manipulationen an der Vendor CPUID des VIA-Prozessors vor, es handle sich nicht um einen VIA, sondern um einen Intel Prozessor. Und was geschah? Obwohl es sich um den selben Prozessor handelte (lediglich mit der CPUID eines Intel versehen), stieg der Wert des Memory-Benchmarks von 1845 auf satte 2721 und lag damit plötzlich vor dem Intel Atom, der lediglich einen Wert von 2428 erreichte.
Wieso jedoch der PCMark2005, der nicht von Intel, sondern von Futuremark entwickelt wurde, einer Firma, die nach eigener Aussage auf maximale Neutralität bedacht ist, in dieser Weise auf die Vendor-IDs reagiert, das kann wohl nur Futuremark selbst beantworten...

Wer nen Phenom hat und den mal mit nem Intel Quad vergleicht weis was da abgeht bei den diversen Benches . Sobald alle 4 kerne gefordert werden siehts nicht gut aus für die
2x Dual pseudo Quads.
Schön wärs wenn AMD bei ihren CPUs in Zukunft auch die CPUID änderbar macht. Damit liese sich deutlich mehr tunen als mit 4000 Mhz.:d
 
Zuletzt bearbeitet:
Was sollen sie denn bitte nicht zeigen? Das der Benchmark nicht objektiv ist (egal ob für VIA oder AMD) ? Was willst du denn noch ? Eine Aussage von Intel " Ja wir geben anderen Prozessoren einen anderen Code damit unsere besser dastehen" ?

Es ist eben nicht egal ob Via oder AMD, wenn ich eine Benachteiligung einer AMD-CPU untersuchen will kann ich dafür schlicht keinen Nano nehmen. Das ist alles was ich gesagt habe und nichts anderes. :rolleyes:
 
hmm boah das heiß was man hier so liest, habs gerade mal überflogen,
das an allen Ecken was gedreht und gewendet wird sollte jedem klar sein, das Benchmarks so viel Aussagekraft haben wie nen Sandkorn am Sandstrand auch.
Das Benchmarks aber auf Menschen wirken wie Alkohol ist auch bekannt, ich wage
mal zu beurteilen das dies am Denkverhalten liegt.

"Oh der liegt ja bei SuperPi 50% unter dem Prozessor, dann ist der ja doppelt so schnell"

Dies wird dann übertragen, auch wenn es mehrere Benchmarks gibt eine 100%tige Genauigkeit kanns nicht geben.
Bestes Beispiel Grafikkartentests gerade jetzt die HD4870 vs. GTX280, je nach Seite sind die Ergebnisse verschieden und somit das Bild verfälscht.

Ein Prozessor und überhaupt ein PC System hängt von so vielen Faktoren ab, ist wie die ersten Fiats die nach Deutschland kamen und jedem unterm Hintern durchrosteten,
weil in Italien kein Rostschutz gebraucht wurde, dies den AUtos hier aber zum Verhängnis wurde.

Gehen wir mal speziell zum Phenom, AMD hat es vermasselt, der TLB Bug zu Anfang war leider der Ausschlag für viele den Phenom direkt abzuschreiben und klar viele schrien auf als es hier 140W TDP beim größten Phenom, aber wer schreit denn nun wenn Intel den Core i7 bringt und dieser 130W TDP hat und das bei 45nm?
Niemand?
Komisch!

Zurück zum Benchmark, die Erkenntnis von Arstechnica ist erschreckend, wurde aber sicherlich von einigen vorher befürchtet.
Wenns einen Konzern in der Branche gibt der Geld hat und alles zu Stande bringt (Geld regiert die Welt) dann ist es wohl Intel.

Da man aber Konkurrenz benötigt kann man nur froh sein das es AMD gibt.

Mich persönlich schreckt der Phenom nicht, aber auch ein Quad von Intel reizt nicht,
wenn die Programme damit mal rumkommen und auf Multicore gehen, dann wird mal überlegt zu wechseln.

Nichts desto trotz müsste jeder eigentlich 2 Systeme hinstellen und vergleichen.
Benchmarks sagen eben einen Dreck über das was wirklich real ist und passiert wenn ein Windowssystem mit Programmen vollgestopft ist.
 
Gerade Cache Misses sind ein sehr gutes Beispiel. Bei einem Yorkfield mit 12MB L2 Cache lassen die sich grundsätzlich weitaus häufiger vermeiden, sind aber andererseits durch den langsameren Ramzugriff fataler als bei einem Phenom. Soetwas lässt sich in einer Optimierung unterbringen und wäre ein klar architekturspezifisches Merkmal. Quervergleiche mit CPUs anderer Hersteller sind damit nichtssagend.
DAS SIND MIKROOPTIMIERUNGEN. Wie oft denn noch? Die werden nicht für jede CPU unterschiedlich erstellt, sondern EINMALIG. Und damit muss jede CPU dann zurechtkommen. GCC bietet für sowas zB die Flags -march und -mtune an. Das hat mit cpuid nichts zu tun.

Nein. Es geht darum, ob "GenuieIntel Code" auf einer nicht-Intel CPU ebenfalls schneller wäre.
Was irgendwie das gleiche ist. :rolleyes:

Hier fehlt dir wohl ne Menge Hintergrundwissen, vergleich die beiden mal bzgl. Superskalarität, der µOP Buffer und anderem, das ist weit mehr als eine simple Evolution.
Toll. Der Core2 hat einen Dekoder mehr. Und nun? Das ist natürlich revolutionär und macht aus der zugrunde liegenden P6 bzw Pentium-M Architektur gleich etwas vollkommen anderes. :rolleyes:
 
DAS SIND MIKROOPTIMIERUNGEN. Wie oft denn noch? Die werden nicht für jede CPU unterschiedlich erstellt, sondern EINMALIG. Und damit muss jede CPU dann zurechtkommen. GCC bietet für sowas zB die Flags -march und -mtune an. Das hat mit cpuid nichts zu tun.

Bitte, der Punkt ist das Optimierungen auf eine bestimme CPU auch durch das normale Programmdesign einfließen können. Dies beweist dir die Praxis:

http://www.computerbase.de/artikel/...08/test_amd_athlon_x2_4850e/14/#abschnitt_mp3

In der ersten Lame-Version liegt ein QX9770 44% vor einem 9950, in der letzten 58%. Ergo ist die letzte Version für den Core 2 im Vergleich zum Phenom besser optimiert als die erste.

Toll. Der Core2 hat einen Dekoder mehr. Und nun? Das ist natürlich revolutionär und macht aus der zugrunde liegenden P6 bzw Pentium-M Architektur gleich etwas vollkommen anderes. :rolleyes:

Lies doch einfach mal den Artikel http://www.tecchannel.de/server/hardware/437111/
 
tecchannel schrieb:
Die neue Architektur für dieses hehre Ziel nennt Intel schlicht „Core“. Sie stellt ein Mix aus den besten Komponenten der Core-Duo- und NetBurst-Architektur dar – mit Schwerpunkt auf dem Core-Duo-Design. Außerdem spendiert Intel der Core-Architektur fünf neue „Innovationen“: Wide Dynamic Execution, Advanced Digital Media Boost, Advanced Smart Cache, Smart Memory Access sowie Intelligent Power Capability.
Wow 5 Innovationen, das war echt was ganz Neues ;)
 
Bitte, der Punkt ist das Optimierungen auf eine bestimme CPU auch durch das normale Programmdesign einfließen können. Dies beweist dir die Praxis:

http://www.computerbase.de/artikel/...08/test_amd_athlon_x2_4850e/14/#abschnitt_mp3

In der ersten Lame-Version liegt ein QX9770 44% vor einem 9950, in der letzten 58%. Ergo ist die letzte Version für den Core 2 im Vergleich zum Phenom besser optimiert als die erste.
Mikrooptimierungen haben mit Programmdesign überhaupt nichts zu tun. Die Zeiten sind glücklicherweise vorbei. Und was genau soll der Vergleich damit zu tun haben? Dir ist schon klar, dass hier ebenfalls der ICC verwendet wurde?

Wozu? Bist du nicht in der Lage, mal selbst etwas darzulegen? Oder kannst du nur das wiedergeben, was andere geschrieben haben? Und dann noch Tecchannel. Wie immer ungemein beeindruckend deine Quellen. :rolleyes:
Falls du es nicht mitbekommen hast, mir ist schon bewusst, was von Core auf Core2 verändert wurde. Alles in allem ist das aber pure Evolution. Nicht mehr und nicht weniger im Vergleich zu K8 und K10.
 
Zuletzt bearbeitet:
Wozu? Bist du nicht in der Lage, mal selbst etwas darzulegen? Oder kannst du nur das wiedergeben, was andere geschrieben haben? Und dann noch Tecchannel. Wie immer ungemein beeindruckend deine Quellen. :rolleyes:
Kam ja schon oft vor, das er irgendwelche Links ohne eigene Erläuterung in den Thread wirft. Wenn dann jemand reagiert, sucht er sich ganz andere Textpassagen raus und meinte ja auch was ganz Anderes...

Lustig finde ich, das ihn diese Quelle eigentlich widerlegt. Aber egal...er wird schon das ein oder andere Rosinchen finden ;)
 
Zuletzt bearbeitet:
Schau mir gerade mal den HEX Code von lame an und es lässt sich tatsächlich "genuineIntel" im Programm und der zugehörigen dll finden. Vielleicht sollte man das mal mit AuthenticAMD ersetzen (hat ja zum Glück die selbe länge)... ich teste das mal, glaube jedoch nicht das es so einfach ist.
 
Mikrooptimierungen haben mit Programmdesign überhaupt nichts zu tun. Die Zeiten sind glücklicherweise vorbei. Und was genau soll der Vergleich damit zu tun haben? Dir ist schon klar, dass hier ebenfalls der ICC verwendet wurde?

Dir ist schon klar, dass sich mit unterschiedlichen Versionen die Performance verschiedener CPUs relativ zueinander verändert hat? Damit ist der Beweis erbracht, dass die getroffenen Optimierungen der einen CPU besser schmecken als der anderen, somit das Verhalten von CPU a mit Optimierung a nicht auf CPU b übertragen werden kann. Ein Test mit dem Nano um Rückschlüsse auf eine AMD-CPU zu ziehen ist somit wertlos. Dies nun zum 10. Male :)

Wozu? Bist du nicht in der Lage, mal selbst etwas darzulegen? Oder kannst du nur das wiedergeben, was andere geschrieben haben? Und dann noch Tecchannel. Wie immer ungemein beeindruckend deine Quellen. :rolleyes:
Falls du es nicht mitbekommen hast, mir ist schon bewusst, was von Core auf Core2 verändert wurde. Alles in allem ist das aber pure Evolution. Nicht mehr und nicht weniger im Vergleich zu K8 und K10.

Muss ich dir etwa noch vorlesen was da steht? "Sie [Core2] stellt ein Mix aus den besten Komponenten der Core-Duo- und NetBurst-Architektur dar"

Vergleiche doch einfach auch mal die IPC-Entwicklung von K8 zu K10 sowie die von Banias zu Penryn, die Differenzen sind klarstens sichtbar.
 
Könnte es sein, dass bei der einen Lame-Version einfach SSE4.1-Support dazu kam? Ein recht eindeutiges Zeichen dafür wäre, dass der Abstand zwischen Q6600 und X4 9950 mit einmal 6% und einmal 5% Differenz gleich geblieben ist. Der Leistungsschub hätte dann eher mit erweiterten Befehlssätzen als mit Architektur-/Micro-Optimierungen zu tun. Oder hab ich da was falsch verstanden, denn als "Fachmann" will ich mich hier auf dem Gebiet nicht ausgeben.

mMn gabe es zwischen Yonah (Core Duo) und Merom (Core 2 Duo) nicht den gern dargestellten exorbitanen Leistungsschub. Der Penryn hat zwar noch mal ne kleine Schippe draufgelegt, aber das ganze rührt vom Cache, der sich gegenüber dem Yonah nicht nur verdoppelt sondern gleich verdreifacht hat, und dem FSB-Aufbohren (533/667MHz -> 800/1066MHz -> 1333MHz) her. Naja und es kamen noch neue Befehlssätze hinzu (SSE4.1)

Ganz ähnlich sieht es bei der Evolution K8 - K10 - K10.5 aus, der Cache wurde in ähnlichen Verhältnissen aufgestock und Befehlssätze kamen dazu (SSE4a). "FSB" bzw. Referenztakt aufbohren hatte die Architektur nicht nötig bzw. würde nichts bringen.
 
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