Intel: Der neue Lynnfield hat eine höhere Speicherbandbreite als ein PhenomII

[Gast HITCHER]

http://www.computerbase.de/artikel/hardware/prozessoren/2009/test_intel_core_i5-750_core_i7-860_core_i7-870/11/#abschnitt_sisoft_sandra_2009

17,6 zu 13,5 GB/s für Intel,
das ist immerhin 30% mehr.

weshalb ist das so?

Hat Intel einen besseren Dualchannel Memory-Controller eingebaut,
oder arbeitet der immer "ganged", was aber bei Multicore-Betrieb ineffizienter ist,
oder ist die eingebaute Northbridge das Nadelöhr, oder hat es einen anderen Grund?

Eigentlich sollten die beiden CPUs mit gleichem RAM doch ca. gleich schnell sein.

[Gast]

Weshalb das so ist?

Sisoft Sandra, muss ich mehr sagen?
http://img25.imageshack.us/img25/7416/76023494.gif

[StefanV]

Benutzten die nicht auch den Intel Compiler oder ähnliche Scherze??

[(del)]

Als aktuell sehr zufriedener "Intelkunde" kann ich dazu nur sagen: Sandra ist als Bench völlig kompromitiert. Ich frag mich eher wie jemand dazu kommt die Soft überhaupt zu erwähnen.

Das noch als "Benchmark" irgendwo aufzuführen ist absolut peinlich.

[Gast HITCHER]

ht4u hat mit pcmark 05 getestet, und da schaut der memory-score für den Lynnfield auch mehr als +30% besser aus.
Ich glaube nicht, daß dieses Ergebnis nur an Sisoftware Sandra liegt.

[mrt]

Das war auch schon beim DDR2-Controller so das AMD den nicht auf Durchsatz optimiert hat, allerdings habens sie die Latenzen auch nicht so weit senken können das man sagen könnte, dass diese den Bandbreitennachteil problemlos ausgleichen oder gar besser damit fährt.
Ich denke dass da noch immer die Crossbar limitiert, scheint aber bei der aktuellen Architektur zu wenig limitierend zu wirken, sonst hätten sie es schon geändert.

[Triskaine]

ht4u hat mit pcmark 05 getestet, und da schaut der memory-score für den Lynnfield auch mehr als +30% besser aus.
Ich glaube nicht, daß dieses Ergebnis nur an Sisoftware Sandra liegt.

;D ;D ;D

Ich verweise darauf:

http://origin.arstechnica.com/reviews/hardware/atom-nano-review.media/PCM2K5-2.jpg

(entnommen von dieser Seite: http://arstechnica.com/hardware/reviews/2008/07/atom-nano-review.ars/6)

Interessant, ändert man die CPUID Flag so das PCMark05 denkt das es auf einem Intel Prozessor läuft verbessern sich die Ergebnisse um 30%. Ob das etwas mit den Ergebnissen des Phenom zu tun hat? :freak:

[Black-Scorpion]

Sobald ein Benchmark auftaucht wo der dem Intel Compiler benutzt wurde, sollte man hellhörig werden.
Ist ja nun wirklich kein Geheimnis das Intel mit allen Mitteln trickst.

[(del)]

Aha. Der Kompiler setzt in der Soft aber keinen eigenen Kode rein um die CPUID auszuwerten und andere Testroutinen zu fahren. Das macht nur der Betrü... ich meine, Programmierer.

[Triskaine]

Aha. Der Kompiler setzt in der Soft aber keinen eigenen Kode rein um die CPUID auszuwerten und andere Testroutinen zu fahren. Das macht nur der Betrü... ich meine, Programmierer.

Das tragische ist das der Intel Compiler tatsächlich eine derartige Funktion bestitzt, nämlich eine Routine zur Erkennung der CPUID wenn man z.B. SSE2 Optmierungen verwenden will. Seit einigen Compilerversionen bekommen AMD CPUs ebenfalls Optimierungen verpasst.
Während der Pentium 4 Era mussten AMD CPUs noch mit normalem x87 Code arbeiten während die Pentiums optimierten Code bekamen. Es ist aber auch heute noch so, das wenn man diese Routine hackt und dem Compiler vortäuscht er laufe auf einer Intel CPU, das die Intel SSE2 Version noch mal etwas schneller läuft als die AMD SSE2 Version und das auf einem AMD Prozessor! Der Unterschied ist nicht riesig, aber ist da und kann schnell mal bis zu 30% ausmachen.
Wenn man schon Benchmarks verwendet dann am besten solche die man selbst mit dem GCC kompiliert hat, denn nur dann kann man Aufschluss darüber geben welche Optimierungen wo verwendet wurden und so ein höchst Maß an Fairness grwährleisten.

[S940]

Das tragische ist das der Intel Compiler tatsächlich eine derartige Funktion bestitzt, nämlich eine Routine zur Erkennung der CPUID wenn man z.B. SSE2 Optmierungen verwenden will.
Nein, Intel hat zwei Routinen ^^
Die CPUID Sache ist alt, mittlerweile werden die erweiterte Family Flags abgefragt, das mit der CPUID war wohl zu offensichtlich.

Mehr hier:
http://www.planet3dnow.de/vbulletin/showthread.php?p=3555261

ciao

Alex

[Avalox]

Aha. Der Kompiler setzt in der Soft aber keinen eigenen Kode rein um die CPUID auszuwerten und andere Testroutinen zu fahren. Das macht nur der Betrü... ich meine, Programmierer.


Doch, dass macht der Compiler völlig allein. Die Abfragefunktion versteckt sich in zahlreichen Bibliotheksaufrufen.

[(del)]

Das tragische ist das der Intel Compiler tatsächlich eine derartige Funktion bestitzt, nämlich eine Routine zur Erkennung der CPUID wenn man z.B. SSE2 Optmierungen verwenden will.Ja ok, aber zieht das überhaupt, wenn man zwar mit ICC kompiliert, aber keine solche Routinen/Bibliotheken linkt?

Sonst kann ich aus eigener kleinen Erfahrung nur sagen, daß beim "normalen" Kode der ICC 9.1 gegenüber GCC 4.2.4 immer abstank und der ICC 10.1 gegen dem 9.1 sogar noch bisschen abgefallen war. Ich weiß da aber nicht mehr die vollständigen Versionsnummern. Hab das irgendwannmal alles entsorgt.

[S940]

Ja ok, aber zieht das überhaupt, wenn man zwar mit ICC kompiliert, aber keine solche Routinen/Bibliotheken linkt?
Die Abfrage ist *immer* eingebaut, ausser Du kompilierst komplett ohne Optimierung. Les Dir einfach mal den P3D Link, und ggf. das PDF von Agner durch.

ciao

Alex

[Undertaker]

Abseits der Optimierungsfragen: Rechnet man "Intelintern" mal zwischen Lynnfield und Nehalem durch, hat ersterer trotz 20% theoretischem Bandbreitennachteil nur 10% realen Rückstand (CB (http://www.computerbase.de/artikel/hardware/prozessoren/2009/test_intel_core_i5-750_core_i7-860_core_i7-870/11/#abschnitt_sisoft_sandra_2009)). Sofern der Test nicht generell ein Skalierungsproblem mit der hohen Bandbreite des Triplechannelinterface des Nehalem hat, scheint Lynnfield hier einige Optimierungen genossen zu haben.