Integer-Bench

[dllfreak2001]

http://ul.to/rv8z95xc

Ich habe 436.1 MegOps/sec mit einem Phenom 2 C3 720 @ 3,2 GHz mit Win7 X64 mit geöffnetem Opera und Winamp

Ich habe das programm selbst geschrieben in PureBasic:




If MessageRequester("Integer-Bench", "Benchmark starten?", #PB_MessageRequester_YesNo) = #PB_MessageRequester_Yes

n.l = 1000000000
a.l = 1
startTime.l = ElapsedMilliseconds()
For i = 0 To n
a + 2436
Next
endTime.l = ElapsedMilliseconds()
MessageRequester("Integer-Bench", "Ergebnis: " + StrF(n/((endTime-startTime))/1000,1) + " MegOps/sec")

EndIf

[grobi]

400.6 MegOps/sec

Core i7 920@standard.

Da stimmt doch was nicht. Wie soll deine CPU da schneller sein? Es sei denn weniger ist besser. ;D

mfg grobi

[hell_bird]

soll das der Quellcode sein? Ich dachte solche Schleifen löst jeder halbwegs moderne Compiler auf...

warum testest du nur addition, warum kein multicore, warum gerade 2436?

[Man From Atlantis]

Q9650@4.00GHz
http://www.abload.de/img/desktop_2011_10_22_15_wk4l.png

[dllfreak2001]

soll das der Quellcode sein? Ich dachte solche Schleifen löst jeder halbwegs moderne Compiler auf...

warum testest du nur addition, warum kein multicore, warum gerade 2436?

Die Schleife kann nicht sperren, ich könnte den gleichen Kram auch in C realisieren, da würde der Compiler auch nicht schimpfen.


-nur Addition weil es von der Rechenzeit bei diesem Compiler keinen Unterschied machte

-kein Multicore weil es mir nur um Singlethread-Leistung geht

-die 2436 weil es keinen unterschied gemacht hat welche zahl ich verwende

400.6 MegOps/sec

Core i7 920@standard.

Da stimmt doch was nicht. Wie soll deine CPU da schneller sein? Es sei denn weniger ist besser. ;D

mfg grobi

Kann sein, dass eine gerade laufende Anwendung hineinpfuscht.
Das Programm mittelt ja nicht über mehrere Durchläufe.

Vielleicht ist der Compiler auch nicht auf die Besonderheiten des I7 optimiert.

[hell_bird]

Die Schleife kann nicht sperren, ich könnte den gleichen Kram auch in C realisieren, da würde der Compiler auch nicht schimpfen.
Ich meinte dass ein ordentlicher Compiler daraus a+n*2436 macht.


-nur Addition weil es von der Rechenzeit bei diesem Compiler keinen Unterschied machte

-kein Multicore weil es mir nur um Singlethread-Leistung geht

-die 2436 weil es keinen unterschied gemacht hat welche zahl ich verwende

Ja ok, schon gut. Ich wollte eigentlich andeuten, dass der Benchmark relativ langweilig ist. Nur eine einzige Addition, die vom Ergebnis der vorherigen abhängig ist? Ich fürchte, da ist sogar ein Pentium 4 pro Takt schneller als ein Sandy Bridge. Wirf mal einen Blick in dieses Dokument: http://www.agner.org/optimize/instruction_tables.pdf

Interessant wäre, wenn eine echte Rechnung mit verschiedenartigen Abhängigkeiten und komplexeren Rechnungen dabei sind, da dann verschiedene Einheiten ausgelastet werden und auch die µop fusion anfängt ihre wirkung zu zeigen.

//Edit: Was auch noch zu beachten wäre:

Address Hex dump Command Comments
00401068 |. C705 A8434000 MOV DWORD PTR DS:[4043A8],3B9ACA00
00401072 |. C705 AC434000 MOV DWORD PTR DS:[4043AC],1
0040107C |. E8 01130000 CALL <JMP.&KERNEL32.GetTickCount> ; [KERNEL32.GetTickCount
00401081 |. A3 B0434000 MOV DWORD PTR DS:[4043B0],EAX
00401086 |. C705 B4434000 MOV DWORD PTR DS:[4043B4],0
00401090 |> A1 A8434000 /MOV EAX,DWORD PTR DS:[4043A8]
00401095 |. 3B05 B4434000 |CMP EAX,DWORD PTR DS:[4043B4]
0040109B |. 7C 12 |JL SHORT 004010AF
0040109D |. 8105 AC434000 |ADD DWORD PTR DS:[4043AC],984
004010A7 |. FF05 B4434000 |INC DWORD PTR DS:[4043B4]
004010AD |.^ 71 E1 \JNO SHORT 00401090
004010AF |> E8 CE120000 CALL <JMP.&KERNEL32.GetTickCount> ; [KERNEL32.GetTickCount
004010B4 |. A3 B8434000 MOV DWORD PTR DS:[4043B8],EAX

Das Fette ist dein "benchmark". Könnte fast sein, dass die anderen Instructions einen größeren Einfluss auf die Performance haben, als das add.

[HarryHirsch]

i7@4.20

40995

[Saugbär]

-kein Multicore weil es mir nur um Singlethread-Leistung geht

Vielleicht ist der Compiler auch nicht auf die Besonderheiten des I7 optimiert.
Singlethread sieht aber ander aus, da splittet der Tasksheduller auf 4*25% auf
538.8 MegOps/sec

[dllfreak2001]

Ich meinte dass ein ordentlicher Compiler daraus a+n*2436 macht.

Och, der Compiler ist schon ganz ordentlich auch ohne Optimierungen dieser Art.


Ja ok, schon gut. Ich wollte eigentlich andeuten, dass der Benchmark relativ langweilig ist. Nur eine einzige Addition, die vom Ergebnis der vorherigen abhängig ist? Ich fürchte, da ist sogar ein Pentium 4 pro Takt schneller als ein Sandy Bridge. Wirf mal einen Blick in dieses Dokument: http://www.agner.org/optimize/instruction_tables.pdf


Sehr interessant... tja was soll ich sagen der Benchmark ist wirklich sehr langweilig soll aber auch nicht mehr sein.


Interessant wäre, wenn eine echte Rechnung mit verschiedenartigen Abhängigkeiten und komplexeren Rechnungen dabei sind, da dann verschiedene Einheiten ausgelastet werden und auch die µop fusion anfängt ihre wirkung zu zeigen.

//Edit: Was auch noch zu beachten wäre:

Address Hex dump Command Comments
00401068 |. C705 A8434000 MOV DWORD PTR DS:[4043A8],3B9ACA00
00401072 |. C705 AC434000 MOV DWORD PTR DS:[4043AC],1
0040107C |. E8 01130000 CALL <JMP.&KERNEL32.GetTickCount> ; [KERNEL32.GetTickCount
00401081 |. A3 B0434000 MOV DWORD PTR DS:[4043B0],EAX
00401086 |. C705 B4434000 MOV DWORD PTR DS:[4043B4],0
00401090 |> A1 A8434000 /MOV EAX,DWORD PTR DS:[4043A8]
00401095 |. 3B05 B4434000 |CMP EAX,DWORD PTR DS:[4043B4]
0040109B |. 7C 12 |JL SHORT 004010AF
0040109D |. 8105 AC434000 |ADD DWORD PTR DS:[4043AC],984
004010A7 |. FF05 B4434000 |INC DWORD PTR DS:[4043B4]
004010AD |.^ 71 E1 \JNO SHORT 00401090
004010AF |> E8 CE120000 CALL <JMP.&KERNEL32.GetTickCount> ; [KERNEL32.GetTickCount
004010B4 |. A3 B8434000 MOV DWORD PTR DS:[4043B8],EAX

Das Fette ist dein "benchmark". Könnte fast sein, dass die anderen Instructions einen größeren Einfluss auf die Performance haben, als das add.

So ist es, die Schleife beeinflusst das Ergebnis recht stark. Das ist aber nicht so schlimm...

[hell_bird]

ok wie auch immer. Ich habe keine Ahnung was das Ergebnis aussagen soll aber hier ist mal meine Messung:
Intel Pentium E5200 (Core2 @ 2.5GHz): 365.8 MegOps/sec

[Konami]

Core 2 Quad Q9450 @ 3,5 GHz: 508.6 MegOps/sec

[dllfreak2001]

ok wie auch immer. Ich habe keine Ahnung was das Ergebnis aussagen soll aber hier ist mal meine Messung:
Intel Pentium E5200 (Core2 @ 2.5GHz): 365.8 MegOps/sec

Nichts eigentlich, ein spaßiger Schwanzvergleich in einer einfachen Teildisziplin ist das. ;D

[Radeonfreak]

557.4 MegOps/sec

[dllfreak2001]

Man sieht ganz gut, dass Intel auch bei sowas einfachem wie einer addition weiter vorne ist als amd.

[pest]

Och, der Compiler ist schon ganz ordentlich auch ohne Optimierungen dieser Art.


nein ist er nicht


MOV DWORD PTR DS:[4043B4],0
@loop: MOV EAX,DWORD PTR DS:[4043A8]
CMP EAX,DWORD PTR DS:[4043B4]
JL SHORT @ende
ADD DWORD PTR DS:[4043AC],984
INC DWORD PTR DS:[4043B4]
JNO SHORT @loop
@ende:


->

MOV ECX,DWORD PTR DS:[4043A8]
@loop: ADD DWORD PTR DS:[4043AC],984
DEC ECX
JNZ @loop


dein "Benchmark" ist ziemlicher Müll, sorry


Man sieht ganz gut, dass Intel auch bei sowas einfachem wie einer addition weiter vorne ist als amd.


nein genau das kannst du da nicht rausziehen

[C.D.B.]

Hmm. 634,5 MOps/sec aufm 2600K@4,5 GHz. :rolleyes:

[KhanRKerensky]

MOV ECX,DWORD PTR DS:[4043A8]
@loop: ADD DWORD PTR DS:[4043AC],984
DEC ECX
JNZ @loop


Wie wärs mit:

MOV ECX,DWORD PTR DS:[4043A8]
@loop: ADD DWORD PTR DS:[4043AC],984
LOOP @loop

? Warum wird die Addition eigentlich nicht mit einem Register durchgeführt? Müsste doch eigentlich schneller als das lesen und schreiben im Speicher (selbst wenns im Cache ist) sein oder nicht?

[pest]

Wie wärs mit:


die "loop" instruction ist auf heutigen prozessoren viel langsamer als "dec/jnz"

[sei laut]

430 439 mit einem C2Q 6600 @ 3,00 Ghz (333*9).
Edit: Ein Schwanzvergleich, wo fast allein die Taktung eine Rolle spielt. :freak:
Edit2: Hatte noch ein paar Anwendungen offen, hat 9 mehr gebracht.

[dllfreak2001]

dein "Benchmark" ist ziemlicher Müll, sorry



Nö ist er nicht, ich finde ihn ganz toll.
Ich wollte ihn jetzt auch nicht optimieren sondern nur in den Raum werfen.
In moderner Software findest du außerdem genug eben solcher schlecht optimierter Stellen.

Ich hoffe du hast nicht erwartet, dass dieser Benchmark irgendwas verwertbares aussagt.
Ist nur ein reiner Schwanzvergleich wie ich schon geschrieben habe, die Werte kann man also
nur miteinander vergleichen.

[PedarPan]

Man sieht ganz gut, dass Intel auch bei sowas einfachem wie einer addition weiter vorne ist als amd.


Ich hoffe du hast nicht erwartet, dass dieser Benchmark irgendwas verwertbares aussagt.
Ist nur ein reiner Schwanzvergleich wie ich schon geschrieben habe, die Werte kann man also
nur miteinander vergleichen.


Ja, was denn nun? Entweder nur (nicht aussagekräftiger) Schwanzvergleich oder aber rauslesen wollen, dass "Intel auch bei sowas einfachem wie einer additions weiter vorne ist als amd"?

Entscheiden sollte man sich doch schon.


Mich würde hierbei interessieren, wie der "alternative" Code denn performt. Mangels Wissen und Lust sich einzuarbeiten, bin ich jedoch nicht fähig so etwas entsprechend umzusetzen.

[Coda]

die "loop" instruction ist auf heutigen prozessoren viel langsamer als "dec/jnz"
Nö. Ab K8 ist das bei AMD eine dual dispatch instruction und sogar schneller.

Bei Intel ist es wohl etwas langsamer. Aber auch nicht wirklich der rede Wert. Von "viel" kann man da nicht ausgehen. Es ist kein Microcode.

[Geldmann3]

439,2 MegOps/Sec mit AMD Phenom II X6 1055T @ 2,9Ghz
beim 2ten Durchgang nur 421MegOps/Sec
beim 3ten 435 MegOps/Sec
beim 4ten 445 MegOps/Sec
beim 5ten 448 MegOps/Sec

CPU auf 800MHz runtergetaktet.
Ergebnis = 113,7 MegOps/Sec

Während des Benchmarks werden alle Kerne nur minimal ausgelastet, warum schwanken dann die Ergebnisse bei unterschiedlichen Taktraten? Kann mir das einer erklären?
Anscheinend limitiert hier nur ein bestimmter Teil der CPU.

[Coda]

Weil's nur ein Thread ist.

[Geldmann3]

Kann ein Thread einen Kern nicht voll auslasten?
Wenn ich in den Taskmanager gucke werden mit dem benchmark alle Kerne minimal ausgelastet 5-25%, warum nicht nur einer bei einem Thread?

[Coda]

Weil das OS das Zeug hin und herschiebt. Das ist normal.

[(del)]

Phenom 955@3,8

520.3MegOps/sec

[Geldmann3]

Weil das OS das Zeug hin und herschiebt. Das ist normal.
Seit wann schiebt das OS einen einzelnen Thread wahllos hin und her? Wenn das so einfach ginge, warum unterstützen dann nicht alle Applikationen Multithreading? Man könnte doch einfach einen Thread, der einen Kern zu 100% auslastet zwischen den Kernen hin und herschieben, und so jede Anwendung "multithreaden"
Die Kerne arbeiten doch Zeitgleich, ein einzelner Thread auf mehreren Kernen würde sich selbst dazwischenfunken, weil das Ganze nicht parallelisiert ist.

[seaFs]

Multithread = mehrere (logische) Prozessoren (Kerne) arbeiten an einer Aufgabe, um ein Ergebnis zu erhalten.
Thread zwischen Cores hin- und herschieben hat nichts damit zu tun. Es ist einfach nur... Daten von einem Cache in den anderen verschieben. Ergo hat es den gegenteiligen Effekt, es verlangsamt eher die Abarbeitung als sie zu beschleunigen.

[Geldmann3]

Zitat von mir:
Während des Benchmarks werden alle Kerne nur minimal ausgelastet, warum schwanken dann die Ergebnisse bei unterschiedlichen Taktraten? Kann mir das einer erklären?

Thread zwischen Cores hin- und herschieben hat nichts damit zu tun. Es ist einfach nur... Daten von einem Cache in den anderen verschieben. Ergo hat es den gegenteiligen Effekt, es verlangsamt eher die Abarbeitung als sie zu beschleunigen.
Warum passiert es dann angeblich? Wenn es doch nur zu einer Verlangsamung führt und nicht nötig ist.

[seaFs]

Dass die Ergebnisse bei unterschiedlichen Taktraten unterschiedlich sind, sollte wohl klar sein (Rechenleistung hängt direkt vom Takt ab...).

Das Hin- und Herschieben ist eine logische Notwendigkeit. Der Scheduler des Betriebssystems muss jedem laufenden Prozess seine CPU-Zeit gewähren, damit jeder Prozess auch ausgeführt werden kann. Und das völlig unabhängig von der Anzahl der logischen Prozessoren. Der Scheduler vergibt definierte Zeitintervalle an die laufenden Prozesse. Da Windows den Fokus auf Interaktivität hat, sind diese Zeitintervalle eher klein (damit möglichst kein Prozess das ganze System aufhält). Wenn du das Hin- und Herwechseln unterbinden willst, nagele den Prozess auf einen Kern mit dem Taskmanager fest. Unter Umständen bringt das Leistungszuwächse.

[Geldmann3]

Höchst interessant, ich habe den Prozess auf einen Kern gelegt und ihm hohe Priorität verliehen @2,9Ghz, nun erreiche ich:

Ergebnis: 464.5 MegOps/sec
Gegen: 445 auf allen Kernen.
Das ist eine Leistungssteigerung von ~4%

Der eine Kern steigt sofort auf 100% Auslastung.

Es könnte natürlich auch sein, dass meine CPU nun einfach auf einem Kern den Turbo anschmeißt. Das kann ich in CoreTemp allerdings nicht beobachten. Ein absulut verlässliches Ergebnis würde man nur ohne Turbo bekommen. Wenn es nicht am Turbo liegt, wäre die Moral der Geschichte, dass man Singlethreaded Anwendungen besser auf einem Kern laufen lässt. Dies bringt nicht nur eine Leistungssteigerung, sondern entlastet auch die anderen Kerne, die nun weniger zu tun haben.

[Demogod]

C2Q 9550 12MB set_high@Core4 @ 3400 Mhz (8,5*400) = 496,8