Sandy Bridge-EP Benchmarkresultate fuer Seminar gesucht

iffi

Enthusiast
Thread Starter
Mitglied seit
20.03.2011
Beiträge
229
Hallo Leute,

ich moechte fuer ein Seminar an der Uni verschiedene Prozessoren(architekturen) auf ihre Leistungsfaehigkeit hin untersuchen.

Zu diesem Zwecke brache ich jedoch noch ein paar Benchmark-ergebnisse aus dem Highend-Sektor (Sandy-Bridge-EP oder Xeon), da diese mehr Speicherkanaele haben als die Standard-Prozessoren (SB:2 , SB-EP: 4)

Da ich leider keinen SB-EP besitze wollte ich fragen, ob einer von euch so freundlich waere und diesen von intel optimierten Linpack benchmark durch sein System jagen kann und die Resultierende .txt file hier hochladen wuerde :)

Intel® Math Kernel Library

Wuerde mich sehr freuen, wenn ich einige Files einsammeln darf

Schonmal Danke im Vorraus fuer eure Zeit und Hilfe
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Bis wann brauchst du Resultate?
Ich kann frühestens anfang nächster Woche ein paar tests fahren.
Es geht dir nur um Prozessorarchitekturen also nur smp benchmarks keine parallelen Rechnungen mit mpi oder?
 
werde den benchmark heute abend mal durch mein sys jagen (SB-E!! kein SB-EP)

Irgendwelche Vorgaben bezgl. takt (stadard/oc ok/etc.) o.ä?
 
Zuletzt bearbeitet:
Die Sachen bräuchte ich bis spätestens Dienstag vor 12 Uhr

@Fr@ddy: Es geht um die Nutzbarkeit von Rechenleistung in (Standard)Programmen, welche meist durch Speicherbandbreite beschränkt wird. Da die Sandybridge der 2011 4 Speicherkanäle anstatt der Üblichen 2 haben, will ich die daraus resultierendere höhere Nutzleistung anzeigen. Da die anderen Werte per Intelbenchmark berechnet wurden, reicht dieser, falls du jedoch ein Multisocket-system hast, gern auch per MPI, es geht um die Maximalperformance unter Idealbedingungen :)

@Onkel.dopi: Takt ist egal, es muss nur in der File Irgendwo vermerkt sein (ist aber beim Intel eh standardmäßig drinnen), damit man das richtig berechnen kann (geht am Schluss um Operationen pro Takt)
 
Hier ein lauf auf zwei Intel(R) Xeon(R) CPU E5-2670 (2.6Ghz) aber dank turbomode @~3GHz bei allen aktiven kernen. Ohne Hyperthreading. Bestückt mit 8x16GB DDR3-1600. Also jeder speicherkanal mit einem 16GB Modul. Hilft dir das weiter?

./runme_xeon64
This is a SAMPLE run script for SMP LINPACK. Change it to reflect
the correct number of CPUs/threads, problem input files, etc..
Mon Jun 24 15:00:19 CEST 2013
Intel(R) Optimized LINPACK Benchmark data

Current date/time: Mon Jun 24 15:00:19 2013

CPU frequency: 3.299 GHz
Number of CPUs: 2
Number of cores: 16
Number of threads: 16

Parameters are set to:

Number of tests: 15
Number of equations to solve (problem size) : 1000 2000 5000 10000 15000 18000 20000 22000 25000 26000 27000 30000 35000 40000 45000
Leading dimension of array : 1000 2000 5008 10000 15000 18008 20016 22008 25000 26000 27000 30000 35000 40000 45000
Number of trials to run : 4 2 2 2 2 2 2 2 2 2 1 1 1 1 1
Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4 4 4 4 1 1 1 1

Maximum memory requested that can be used=16200901024, at the size=45000

=================== Timing linear equation system solver ===================

Size LDA Align. Time(s) GFlops Residual Residual(norm) Check
1000 1000 4 0.008 82.1552 8.724688e-13 2.975343e-02 pass
1000 1000 4 0.005 127.9231 8.724688e-13 2.975343e-02 pass
1000 1000 4 0.005 127.6869 8.724688e-13 2.975343e-02 pass
1000 1000 4 0.005 127.2587 8.724688e-13 2.975343e-02 pass
2000 2000 4 0.029 186.8378 4.701128e-12 4.089406e-02 pass
2000 2000 4 0.028 187.4404 4.701128e-12 4.089406e-02 pass
5000 5008 4 0.330 252.4715 2.434170e-11 3.394253e-02 pass
5000 5008 4 0.328 254.2321 2.434170e-11 3.394253e-02 pass
10000 10000 4 2.464 270.6939 8.916344e-11 3.143993e-02 pass
10000 10000 4 2.449 272.2612 8.916344e-11 3.143993e-02 pass
15000 15000 4 7.629 294.9913 2.165846e-10 3.411244e-02 pass
15000 15000 4 7.596 296.2654 2.165846e-10 3.411244e-02 pass
18000 18008 4 12.539 310.1315 2.945255e-10 3.225417e-02 pass
18000 18008 4 12.561 309.5863 2.945255e-10 3.225417e-02 pass
20000 20016 4 17.280 308.6910 3.831049e-10 3.391318e-02 pass
20000 20016 4 17.275 308.7793 3.831049e-10 3.391318e-02 pass
22000 22008 4 23.095 307.4154 4.066827e-10 2.978791e-02 pass
22000 22008 4 23.084 307.5569 4.066827e-10 2.978791e-02 pass
25000 25000 4 33.867 307.6113 5.501781e-10 3.128666e-02 pass
25000 25000 4 33.838 307.8747 5.501781e-10 3.128666e-02 pass
26000 26000 4 38.140 307.2584 5.851288e-10 3.076783e-02 pass
26000 26000 4 38.186 306.8872 5.851288e-10 3.076783e-02 pass
27000 27000 4 42.802 306.6089 6.532881e-10 3.185765e-02 pass
30000 30000 1 58.797 306.1677 7.329930e-10 2.889466e-02 pass
35000 35000 1 94.121 303.7138 1.115330e-09 3.237635e-02 pass
40000 40000 1 137.412 310.5256 1.359319e-09 3.023172e-02 pass
45000 45000 1 196.753 308.7840 1.876477e-09 3.301464e-02 pass

Performance Summary (GFlops)

Size LDA Align. Average Maximal
1000 1000 4 116.2560 127.9231
2000 2000 4 187.1391 187.4404
5000 5008 4 253.3518 254.2321
10000 10000 4 271.4776 272.2612
15000 15000 4 295.6283 296.2654
18000 18008 4 309.8589 310.1315
20000 20016 4 308.7351 308.7793
22000 22008 4 307.4861 307.5569
25000 25000 4 307.7430 307.8747
26000 26000 4 307.0728 307.2584
27000 27000 4 306.6089 306.6089
30000 30000 1 306.1677 306.1677
35000 35000 1 303.7138 303.7138
40000 40000 1 310.5256 310.5256
45000 45000 1 308.7840 308.7840

Residual checks PASSED

End of tests

Done: Mon Jun 24 15:23:51 CEST 2013

---------- Post added at 16:41 ---------- Previous post was at 15:31 ----------

Und noch ein etwas älterer Rechner mit 2x Intel(R) Xeon(R) CPU X5650 @ 2.67GHz. Ohne turbo ohne SMT mit DDR3-1333.

./runme_xeon64
This is a SAMPLE run script for SMP LINPACK. Change it to reflect
the correct number of CPUs/threads, problem input files, etc..
Mon Jun 24 15:43:49 CEST 2013
Intel(R) Optimized LINPACK Benchmark data

Current date/time: Mon Jun 24 15:43:49 2013

CPU frequency: 2.666 GHz
Number of CPUs: 2
Number of cores: 12
Number of threads: 12

Parameters are set to:

Number of tests: 15
Number of equations to solve (problem size) : 1000 2000 5000 10000 15000 18000 20000 22000 25000 26000 27000 30000 35000 40000 45000
Leading dimension of array : 1000 2000 5008 10000 15000 18008 20016 22008 25000 26000 27000 30000 35000 40000 45000
Number of trials to run : 4 2 2 2 2 2 2 2 2 2 1 1 1 1 1
Data alignment value (in Kbytes) : 4 4 4 4 4 4 4 4 4 4 4 1 1 1 1

Maximum memory requested that can be used=16200901024, at the size=45000

=================== Timing linear equation system solver ===================

Size LDA Align. Time(s) GFlops Residual Residual(norm) Check
1000 1000 4 0.014 47.9931 1.158133e-12 3.949530e-02 pass
1000 1000 4 0.011 63.4293 1.158133e-12 3.949530e-02 pass
1000 1000 4 0.010 64.4861 1.158133e-12 3.949530e-02 pass
1000 1000 4 0.011 63.6029 1.158133e-12 3.949530e-02 pass
2000 2000 4 0.067 79.3308 5.160899e-12 4.489350e-02 pass
2000 2000 4 0.064 83.7452 5.160899e-12 4.489350e-02 pass
5000 5008 4 0.838 99.5464 2.304573e-11 3.213542e-02 pass
5000 5008 4 0.839 99.3358 2.304573e-11 3.213542e-02 pass
10000 10000 4 6.251 106.6870 1.157730e-10 4.082273e-02 pass
10000 10000 4 6.224 107.1514 1.157730e-10 4.082273e-02 pass
15000 15000 4 20.082 112.0641 1.973532e-10 3.108346e-02 pass
15000 15000 4 20.076 112.0977 1.973532e-10 3.108346e-02 pass
18000 18008 4 34.423 112.9664 2.772305e-10 3.036015e-02 pass
18000 18008 4 34.432 112.9373 2.772305e-10 3.036015e-02 pass
20000 20016 4 46.840 113.8803 3.862499e-10 3.419158e-02 pass
20000 20016 4 46.851 113.8531 3.862499e-10 3.419158e-02 pass
22000 22008 4 62.130 114.2713 4.016573e-10 2.941981e-02 pass
22000 22008 4 62.108 114.3118 4.016573e-10 2.941981e-02 pass
25000 25000 4 92.446 112.6924 5.707311e-10 3.245543e-02 pass
25000 25000 4 92.434 112.7063 5.707311e-10 3.245543e-02 pass
26000 26000 4 101.642 115.2935 6.238647e-10 3.280468e-02 pass
26000 26000 4 101.628 115.3098 6.238647e-10 3.280468e-02 pass
27000 27000 4 113.528 115.5965 6.653771e-10 3.244717e-02 pass
30000 30000 1 155.511 115.7592 7.465623e-10 2.942956e-02 pass
35000 35000 1 248.828 114.8816 1.138278e-09 3.304250e-02 pass
40000 40000 1 366.609 116.3907 1.336678e-09 2.972817e-02 pass
45000 45000 1 528.065 115.0503 1.886135e-09 3.318456e-02 pass

Performance Summary (GFlops)

Size LDA Align. Average Maximal
1000 1000 4 59.8778 64.4861
2000 2000 4 81.5380 83.7452
5000 5008 4 99.4411 99.5464
10000 10000 4 106.9192 107.1514
15000 15000 4 112.0809 112.0977
18000 18008 4 112.9519 112.9664
20000 20016 4 113.8667 113.8803
22000 22008 4 114.2915 114.3118
25000 25000 4 112.6994 112.7063
26000 26000 4 115.3016 115.3098
27000 27000 4 115.5965 115.5965
30000 30000 1 115.7592 115.7592
35000 35000 1 114.8816 114.8816
40000 40000 1 116.3907 116.3907
45000 45000 1 115.0503 115.0503

Residual checks PASSED

End of tests

Done: Mon Jun 24 16:31:38 CEST 2013
 
Zuletzt bearbeitet:
Danke, das hilft sehr weiter, vorallem der Performancesprung von ~110 auf ~300 GFLOPS bei nur 33% mehr Kernen ^^

Gesendet von meinem Nexus S mit der Hardwareluxx App
 
Ich denke der große Performanceunterschied dürfte vor allem an AVX liegen. Und natürlich der etwas höhere Takt.
Wenn es dir darum geht den Vorteil von Speicherbandbreite aufzuzeigen solltest du es vielleicht mit weniger gut optimierter software versuchen. Oder zumindest mit großen Systemen, wo caching weniger hilft.
Mir fallen da spontan mit openmp parallelisierte Programme ein, die nicht ganz einfach vorherzusehende große Datenstrukturen wie Listen nutzen.

Wäre nett, wenn du deine Schlussfolgerungen der Gegenüberstellung hier mitteilen würdest.
 
Hi, also wenn ich am Wochenende Luft habe, schreibe ich meine Auswertungen gern hier in den Thread. Ansonsten im Laufe der Woche
 
Hi Leute,
sorry dass ich erst so spät die Versprochenen Informationen nachtrage, war die Hölle los.

Also, wie bereits vermutet waren die neuen Systeme sowohl Leistungstechnisch schneller, als als Hardwaretechnisch wesentlich besser an die Reale Welt angepasst.

Das Diagramm mit den ausgewerteten Messergebnissen



Wie in diesem Diagramm zu sehen hat gerade Intel mit seinem Wandel "weg von immer mehr Takt, hin zu einer besseren Speicheranbindung" seine Serverprozessoren wieder in Top-Positionen gerückt.
Nun eine kurze Erklärung der Darstellung:
Am besten zeigt sich der Wandel in Vergleich des Xeon E-5345 (in der Grafik Gelb markiert) mit dem des Xeon X-5650 (in der Grafik Grün dargestellt). Durch den Anstieg der Speicheranbindung (hauptsächlich durch den integrierten Speichercontroller) konnte der sog. Ridge-Point von 6.7 auf 2.0 gesenkt werden.
Der Ridge-point mit der Einheit "Operational Intensity" bezeichnet in dieser Darstellung die minimale Anzahl an Floating-Point-Operationen pro Byte,welche eine Anwendung ausführen müsste, um das System vollständig auszulasten. Die maximale Performance wird also 70% früher erreicht. (Zum Vergleich, die Mathematischen Funktionen, welche ich betrachtet hatte, waren bei ~1)

Die Auswirkung des Speicherproblems lässt sich sehr gut in vergleich des Xeon E-5345 mit seinem damaligen Konkurrenten, dem Opteron 2356(in der Grafik türkis dargestellt). Obwohl beide ca. die gleiche Maximalperformance haben, erreicht der Opteron diese nicht nur wesentlich früher, auch im Bereich geringerer Operational Intensity, in der sich die meisten Porgramme tummeln, erreicht er eine wesentlich Performance.

Beim Xeon E5-2670(in der Grafik dunkelrot) hingegen sieht man, dass auch Intel mittlerweile wieder an einem Speicherbandbreitenproblem zu knabbern hat, der Ridgepoint verschiebt sich wieder zu 3,75. Im Vergleich mit der fast baugleichen Sandy-Bridge Architektur des I7 und der Nachfolgearchitektur des I5 IvyBridge sieht man, welches Potential in diesen Architekturen steckt, und wie wenig Desktop-CPU's dieses Ausnutzen können.

Meine Prognose ist, dass in den kommenden Servergenerationen vorallem die Speicheranbindung deutlich verbessert wird, um ähnlich wie bei einem Auto die Leistung überhaupt nutzbar zu machen.

@Fr@ddy:
Ich möchte mich erstmal ganz herzlich bei dir Bedanken, dass ich dank deiner Hilfe den Wandel innerhalb der verschiedenen Prozessorgenerationen sehr gut analysieren konnte, gerade der Vergleich zwischen Northbridge Speicheranbindung <-> CPU-interner Speichercontroller konnte meine Argumente sehr gut unterstreichen.

Entschuldige bitte vielmals, dass ich so lange nicht dazu kam, meine Auswertungen hier einzuschreiben, das war keine Böse Absicht :(



Solltet ihr noch Fragen zu diesem Thema haben, bitte schreibt hier in den Thread oder noch besser, schreibt mir eine PN, dann krieg ich das auf meine Email geschickt.


Euch allen noch einen Schönen Abend und viel Spass beim lesen :)
 
Schön, dass da doch noch was kommt.

Hast du eine erklärung dafür, dass die i5 und i7 single Socket CPUs so abschneiden? Liegt es am hohen Takt der CPU und der verhältnismäßig langsamen Speicheranbindung und den kleinen Caches? War beim i7 HT aktiviert? Hast du irgendwelche Beispiele, ob sich da was bei aktivem HT verschiebt?

Wäre ja ein leichtes an so einem Desktop System mit verschiedenen Speichergeschwindigkeiten oder mit und ohne Dualchannel zu überprüfen was tatsächlich speicheranbindung ausmacht und was über caches kommt.
 
Hast du eine erklärung dafür, dass die i5 und i7 single Socket CPUs so abschneiden? Liegt es am hohen Takt der CPU und der verhältnismäßig langsamen Speicheranbindung und den kleinen Caches?
Diese Kurven beziehen sich auf die theoretisch maximialen Werte, daher hat auch der Takt einen sehr hohen Einfluss: Die Formel lautet #Kerne x FrequenzProKern x (Flops pro Taktzyklus)
Es liegt vorallem am hohen Takt der CPU, da sowohl der i5 als auch der i7 jeweils nur 4 Kerne besitzt. Die im vergleich zum Serversystem wesentlich langsamer ansteigende Kurve ist allein auf die Speicheranbindung zurückzuführen, da in meiner Betrachtung Cache-Techniken vernachlässigt werden, da sie (fast) keinen Einfluss auf den Ridge-Point der Arichtekturen haben. Die Auslastung eines Systems mit Cache-techniken wird als Arithmetic Intensity bezeichnet, Cache wird hierbei vorallem bei der Optimierung von Software betrachtet, um die Operational Intensity eines Programmes zu erhöhen, damit diese sich an den Ridge-Point eines Systems annähert, um höhere Leistung zu erziehlen (es gibt ein Paper, welches verschiedene Cache-techniken miteinbezieht, bei interesse such ich es gerne herraus)
War beim i7 HT aktiviert? Hast du irgendwelche Beispiele, ob sich da was bei aktivem HT verschiebt?
Nach meinen Messungen gab es nur marginale Verbesserungen zwischen "ohne HT" und "mit HT" (unter 1%), was jedoch vorallem dem hochoptimierten Intel-Benchmark zuzuschreiben sein wird, welcher die Pipelines sehr gut auszulasten scheint. HT Ist ja nur eine Technik der Hersteller, um NOPs innerhalb von Pipelines sinnvoll mit Instruktionen aufzufüllen, um die sonst "verlorene" Rechenzeit sinnvoll zu füllen.

Da sich die Formel zur Berechnung der theoretischen Leistung nur auf echte Kerne bezieht, hat HT hierbei faktisch keinen Einfluss. Im Realen Softwareleben jedoch würde ich außer bei Hoch-Intensiven Algorithmen HT immer aktiviert lassen, da der Overhead fast nicht messbar ist und die Auslastung der Pipelines nie 100% ist :)

Wäre ja ein leichtes an so einem Desktop System mit verschiedenen Speichergeschwindigkeiten oder mit und ohne Dualchannel zu überprüfen was tatsächlich speicheranbindung ausmacht und was über caches kommt.
Natürlich kann man relativ leicht den Ridgepoint seines eigenen Systems errechen, Aussagekräftiger für den Einzelnen ist es aber sicherlich, seinen realen Speicherdurchsatz und seine reale max. Flops rauszubekommen. Dazu kann man einfach an seinen Rechner per Syntetischem Benchmark die maximiale Rechenleistung herausfinden(z.b. der Linpack von Intel) und anschließend den maximialen Speicherdurchsatz (in dem Paper wird hier der Stream-benchmark genannt, weiß nicht genau, ob es da mittlerweile schon bessere gibt).

Für meinen i7 z.b. war die Abweichung von theoretischer und maximaler Rechenleistung 108,8 vs 102,5 ~5,79%, womit ich gut leben kann. Der Übertaktete I5 hingegen hat mit 121,6 vs 100,2 schon deutlich schlechter abgeschnitten, was ich persönlich auch nicht 100%ig erklären kann, da ~18% schon deutlich Platz nach oben lassen.

Die Abweichungen zwischen Theorie und Praxis der Xeons lässt aber vermuten, dass es mit der Operational Intensity des Benchmarks zu tun haben könnte:
Der ältere Gulftown mit einem RP von 2 hat eine Abweichung von ~9%, der deutlich Leistungsstärkere SB-E mit einem RP von fast 4 liegt mit ~19% eher in der Zone der benchmarklimiterung
 
Nach meinen Messungen gab es nur marginale Verbesserungen zwischen "ohne HT" und "mit HT" (unter 1%), was jedoch vorallem dem hochoptimierten Intel-Benchmark zuzuschreiben sein wird, welcher die Pipelines sehr gut auszulasten scheint. HT Ist ja nur eine Technik der Hersteller, um NOPs innerhalb von Pipelines sinnvoll mit Instruktionen aufzufüllen, um die sonst "verlorene" Rechenzeit sinnvoll zu füllen.
Der Intel HPL verwendet die MKL und dieses benutzt auf Intel Hardware intensiv Thread Pinning, so daß HT nichts mehr bringt. Es ist auch mit selbst geschriebenem Code relativ einfach die Cores zu 100% auszulasten, wenn man Number Crunching macht und den Code immer für die Zielplattform übersetzt. Ohne Thread Pinning hat man das Problem, daß unnötige Contextwechsel stattfinden und dadurch zu viele Cache Misses produziert werden. Der HPL hängt im wesentlichem von der DGEMM Routine ab, und diese wird heute immer auf die Vermeidung von Cache Misses optimiert.
 
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