Erster offizieller Test zum Intel Xeon (45nm) Harpertown mit 1600 FSB

Naja, ausgeschlossen ist es noch nicht.

Ich bin ja mal hochgespannt auf die ersten Phenom X4 Benchmarks wodurch man mit OC sicher auch die Möglichkeit haben wird, mal einen Phenom X4 mit 3 GHz zu Benchen und dann bin ich ja mal wirklich hochgespannt, was der bei der Takrate an Leistung rüberbringt.

Man muss ja schon zugeben, dass der 2 GHz Opteron von AMD wirklich sehr niedrig getaktet ist. Hochgespannt bin ich in dem Vergleich auch auf die Opteron 2,5 GHz Variante, welche ja dieses Jahr noch kommen soll.

Tecchannel wird sicherlich auch dazu dann einen Vergleichsbenchmark machen und dann können wir wirklich gespannt sein.

Also so gespannt wie du, kann man doch gar nicht sein.. oder? Zumindest nicht ohne zu brechen :eek:

:hmm: ;)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Mal ganz ehrlich, wo soll denn ein riesen Leistungssprung herkommen? Durch mehr Cache, einen höheren FSB und neuen Speicher bekommt man eben keine neue Super-CPU, wenn man es realistisch betrachtet. Immerhin kann jetzt der Takt weiter gesteigert werden, wobei der K10 mit steigenden Taktraten vermutlich schnell aufschließen wird, nicht zuletzt dank der guten Skalierung. Aber da lassen wir uns mal überraschen.
Genau so ist es und deswegen sind diese "Mr. Unereichbar" Prophezeiungen, die von vielen Intelfans unablässig in allen AMD-Threads propagiert wurden absolut lächerlich.
 
Genau so ist es und deswegen sind diese "Mr. Unereichbar" Prophezeiungen, die von vielen Intelfans unablässig in allen AMD-Threads propagiert wurden absolut lächerlich.

Bitte argumentiert sachlich und mit Beweisen. Abfällige Bemerkungen sind Spam.

Wenn man sich schon in anderen Themen über Spam aufregt, dann sollte man nicht selber welchen verbreiten. Die Leute die gemeint sind, verstehen mich schon. Erstaunlich dass ihr in den Themen die die eigene Lieblingsfirma gut stehen lassen, auf strikte Einhaltung der Forenregeln besteht, jedoch in den Themen, die von der Gegenseite stammen selber gegen sie verstoßt. So langsam reicht es. Und damit meine ich mehrere Leute.
 
Was ist an der Aussage nicht sachlich, ich glaub mir reichts gleich langsam!

Freie Meinungsäußerung(ohne Bleiedigungen) wird ja wohl noch erlaubt sein, oder gilt das hier nur für bestimmte User?!?
 
@StevensDE
Wenn du mir jetzt noch plausibel erklärst, weshalb Intel und unseriöse/unprofessionelle (Online)Magazine AMD Benchmark-Vergleichsergebnisse mit Intel Compiler (wobei AMD CPUs faktisch "versteckt" ausgebremst werden) veröffentlichen, glaub ich sogar deinen heiligen Worten über den Intel Compiler! ;)


Hab mir jetzt auch mal die c't Ausgabe 20 herausgelassen. Was ich ebenfalls interessant finde bezüglich der Intel-Benchmarks:

"Vor allem im puren 64-Bit-Betrieb, wie er bei Servern inzwischen die Regel ist, kann er [Anm.: der K10] seine Stärken ausspielen, denn hier offenbaren sich bei Intels Core2 stärkere strukturelle Schwächen [...] Und so wundert es nicht, dass Intel und Co. SPECint_2006-Benchmarkergebnisse immer nur mit 32-Bit-Code veröffentlichen - das machen wir aber anders"

Quelle: c't 20/2007, Seite 175


Frei nach dem Motto: Ich mal mir die Welt wie es mir gefällt :shot:
 
Zuletzt bearbeitet:
@Mr.Quad:

Ist doch altbekannt, das jeder versucht Benchmarks möglichst unaufällig zu manipulieren :wink:
 
Ja ich hab da ein "s" vergessen, das ist aber auch schwierig sich das dazuzudenken: Intels CPUID
Ah, ich glaube ich verstehe was du meinst. Die Ausführung der cpuid Instruktion, welche das Vorhandensein eines Intel Prozessor vermeldet, richtig? Dann ist es schon richtig so ohne "s".
 
Die CPUID beinhaltet einen Herstellercode. Das kannst z.B. in Everest nachschauen. Bei Intel ist das "GenunineIntel" bei AMD ist das "AuthenticAMD". Genau das fragt der Compiler ab. Das kann auch rausgepatcht werden, dann liefern die Intel Compiler auch mit Intel Compiler gute bis sehr gute Ergebnisse.
 
Das kann auch rausgepatcht werden, dann liefern die Intel Compiler auch mit Intel Compiler gute bis sehr gute Ergebnisse.

Öhm, ich glaube das sollte eher heissen: Dann liefern auch AMD Prozessoren mit Intel Compiler gute bis sehr gute Ergebnisse.
 
Jo das denke auch das das einfach nen Tipfehler war!
Aber warum nicht gleich den von Ms nehmen?
 
Weil der MS compiler schlechtere Ergebnisse auf *beiden* Prozessoren liefert.
 
Die CPUID beinhaltet einen Herstellercode. Das kannst z.B. in Everest nachschauen. Bei Intel ist das "GenunineIntel" bei AMD ist das "AuthenticAMD". Genau das fragt der Compiler ab.
OK, dann hast du es so offenbar so gemeint wie ich schrieb. Auch wenn es seltsam klang. Du hast vermutlich ein paar falsche Verstellungen davon, was ein Compiler ist bzw. macht. Ein Compiler _fragt_ nicht ab, was cpuid liefert. Ein Compiler übersetzt Quellcode, d.h. er _erzeugt_ vielmehr eine cpuid Instruktion in der Executable. Diese wird dann zur Laufzeit ausgeführt und entsprechend ausgewertet.
 
Ein Compiler kann aber bestimmte Optimierungen in der Codestruktur vornehmen um bestimmte Prozessorarchitekturen
und -eigenschaften besser nutzen zu können. Um zu wissen welche Vorteile er nutzen soll muss er natürlich wissen
welche Architektur zu Grunde liegt...
 
Zuletzt bearbeitet:
@Mr.Quad:

Ist doch altbekannt, das jeder versucht Benchmarks möglichst unaufällig zu manipulieren :wink:

komischerweise führt jeder seine Benchmarks immer an....

ist wie bei den Einschaltquoten....da werden auch nur die gezeigt die am höchsten sind
 
Ein Compiler kann aber bestimmte Optimierungen in der Codestruktur vornehmen um bestimmte Prozessorarchitekturen
und -eigenschaften besser nutzen zu können. Um zu wissen welche Vorteile er nutzen soll muss er natürlich wissen
welche Architektur zu Grunde liegt...

Das legt der Compiler aber nicht anhand der Platform fest, auf der *der Compiler* ausgeführt wird. Dazu werden Optionen auf der Kommandozeile verwendet. ABER: Alle Compiler generieren alternative Codepfade für Prozessoren die bestimmte Funktionen nicht unterstützen und hier liegt der Hase begraben: Intel führt diese alternativen Codepfade aus sobald ein nicht Intelprozessor vorliegt - aber das betrifft das generierte Programm und nicht den Compiler selbst.
 
Ein Compiler kann aber bestimmte Optimierungen in der Codestruktur vornehmen um bestimmte Prozessorarchitekturen
und -eigenschaften besser nutzen zu können. Um zu wissen welche Vorteile er nutzen soll muss er natürlich wissen
welche Architektur zu Grunde liegt...
Nein, muss er nicht. Das kann er auch gar nicht. Die Arbeit eines Compiler erfolgt während der Übersetzungszeit, cpuid Informationen werden aber während der Laufzeit ausgewertet. grover hat es schon richtig formuliert, Optimierungen nimmt ein Compiler anhand entsprechender Flags vor. Zur Laufzeit wird dann über Codepfade oder Indirektion entschieden, welche davon zum tragen kommen. Der Compiler selbst tut hier überhaupt nichts mehr zur Sache. Das ändert natürlich nichts an Intels Compiler Problem, es war halt nur unglücklich formuliert von [HOT].
 
Zuletzt bearbeitet:
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