Erstes Engineering Sample von Sandy Bridge-E aufgetaucht

Seite 1 von 2 - Forum: Prozessoren auf overclockers.at

URL: https://www.overclockers.at/prozessoren/erstes-engineering-sample-von-sandy-bridge-e-aufge_225491/page_1 - zur Vollversion wechseln!

mat schrieb am 05.08.2011 um 10:32

<div class="previewimage content"></div>Der Name Coolaler steht nicht selten direkt neben den ersten Fotos und Benchmarks von diversen Intel-Prozessoren, die noch lange nicht reif für die Massenproduktion sind. Auch bei Sandy Bridge-E enttäuscht er uns nicht und hat die ersten Durchläufe in SuperPI 1M und wPrime mit einem 8C/16T-Engineering Sample bei ungefähr 2 GHz auf Lager.

Viper780 schrieb am 05.08.2011 um 11:32

warum auf 6GHz hochrechnen? warum nicht einfach einen SB mit 2GHz Takten und dann SuperPi und WPrime laufne lassen?

mat schrieb am 05.08.2011 um 12:42

Zitat von Viper780
warum auf 6GHz hochrechnen? warum nicht einfach einen SB mit 2GHz Takten und dann SuperPi und WPrime laufne lassen?

Der verlinkten 1M-Run ist der derzeit schnellste SB-Chip und wir wollten wissen, ob SB-E die Zeit schlagen kann. :cool:

Viper780 schrieb am 05.08.2011 um 12:44

mir ist schon klar was ihr damit machen wolltet - aber ich finds halt nicht Aussagekräftig sondern besser wenn man Systeme auf augenhöhe vergleicht und nicht extrapolieren muss dafür.

kannst du denn keine schnellen vergleichs benches machen?

mat schrieb am 05.08.2011 um 12:45

Dazu fehlt mir momentan die Zeit. Hat wer anderer grade ein laufendes SB-System bei der Hand?

octacore schrieb am 05.08.2011 um 13:01

*schmollt in einer Ecke und will auch einen Octacore*
;-)

El_Barto schrieb am 05.08.2011 um 14:26

Zitat
warum auf 6GHz hochrechnen? warum nicht einfach einen SB mit 2GHz Takten und dann SuperPi und WPrime laufne lassen?

mir war grad fad und ich war sowieso grad am nachjustieren also hab ichs kurz mal ausprobiert.

wie's ausschaut ist mein 2500k schneller

w-prime testen bringt aber herzlich wenig, da fehlen mir einfach 12 threads mitm i5

mfg El_Barto

mat schrieb am 05.08.2011 um 14:28

Der Speicher ist sicher nicht so eng eingestellt. Mach bitte mal 1333 MHz, CL9.

El_Barto schrieb am 05.08.2011 um 14:44

bitteschön, viel hat sich nicht geändert, bei dem run war er a spur langsamer.

das ist das erstbeste ergebnis, hab da jetzt nicht herumprobiert obs noch besser geworden wäre.

mfg El_Barto

mat schrieb am 05.08.2011 um 14:50

Danke.

Auf gut Deutsch: Was wir bisher wissen, ist Sandy Bridge-E auf 2 GHz circa gleich schnell wie ein Sandy Bridge auf 2 GHz. Hoffen wir, dass dafür größere L1- und L2-Caches verantwortlich sind, sonst bin ich etwas enttäuscht.

Turrican schrieb am 05.08.2011 um 17:18

nice, sieht leistungsmäßig recht woot aus.

Garbage schrieb am 05.08.2011 um 20:27

Zitat von mat
Danke.

Auf gut Deutsch: Was wir bisher wissen, ist Sandy Bridge-E auf 2 GHz circa gleich schnell wie ein Sandy Bridge auf 2 GHz. Hoffen wir, dass dafür größere L1- und L2-Caches verantwortlich sind, sonst bin ich etwas enttäuscht.

L1 und L2 sind aber bei SB und SB-E gleich groß.
Ich glaube auch gar nicht dass sich bei Super-Pi 1M großartig was ändern wird. Bei 32M eher, wenn 1 Thread sich den 20MB großen L3 Cache fast komplett krallen kann.

Hornet331 schrieb am 06.08.2011 um 14:54

Zitat von mat
Danke.

Auf gut Deutsch: Was wir bisher wissen, ist Sandy Bridge-E auf 2 GHz circa gleich schnell wie ein Sandy Bridge auf 2 GHz. Hoffen wir, dass dafür größere L1- und L2-Caches verantwortlich sind, sonst bin ich etwas enttäuscht.

War auch nix anders zu erwarten, wo SB-E dem dsktop den rang ablaufen wird -> rendering, encoding, über all dort wo eben alle cores vol lausgefahren werden können.

mat schrieb am 08.08.2011 um 10:27

Zitat von Garbage
L1 und L2 sind aber bei SB und SB-E gleich groß.
Ich glaube auch gar nicht dass sich bei Super-Pi 1M großartig was ändern wird. Bei 32M eher, wenn 1 Thread sich den 20MB großen L3 Cache fast komplett krallen kann.

Die Caches könnten von CPU-Z falsch ausgelesen bzw. angenommen werden. Oder kannst du das anderweitig bestätigen?

Hornet, darauf scheint es hinauszulaufen. Benchmarks mit Speicher-Bottleneck könnten ebenfalls durch die zusätzlichen Channels profitieren. Aber wieviele sinnvolle Anwendungen gibts da schon ...

Garbage schrieb am 08.08.2011 um 20:33

Zitat von mat
Die Caches könnten von CPU-Z falsch ausgelesen bzw. angenommen werden. Oder kannst du das anderweitig bestätigen?

die cache description register sind schon seit ewigkeiten festgelegt und praktisch unverändert.
die cache parameter und die cpuid sind in der regel die dinge die immer stimmen. kannst ja mal eine ewig alte cpu-z version mit einer aktuellen cpu-z versuchen - zumindest die cache info wird stimmen (sofern der hersteller keinen pfusch gebaut hat und die abfrage falsche werte zurückliefert).