1. #1
    Lt. Commander
    Dabei seit
    Aug 2012
    Beiträge
    1.440

    Nai's Benchmarkthread


    Bitte hier Diskussionen unterlassen, die nichts mit den Benchmarks zu tun haben. Denn ansonsten wird der Thread sehr schnell sehr unübersichtlich. Auch bitte erst die Diskussion der Benchmarkergebnisse lesen und versuchen zu verstehen. Viele Fragen würden sich dann nämlich erübrigen. Bei Crashes bitte zuerst den Watch-Dog abschalten:
    http://stackoverflow.com/questions/4...rk-around-this



    Benchmark

    Zunächst das aktuelle Benchmark, welches die L2-Cache-Bandbreite, die L2-Cache-Größe und die DRAM-Bandbreite abschätzt:

    NaisBenchmark32.exe 59 KB
    https://mega.co.nz/#!w1NEhRZK!naPp8k...3Z8501W60uWsMQ
    NaisBenchmark64.exe 68 KB
    https://mega.co.nz/#!kg0zUTIT!3jCTfd...SxnNvC0qERJfd4

    CUDA-DLLs:
    cudart32_65.dll 242 KB
    https://mega.co.nz/#!5g8DzA7T!FZzZf9...Sj0-CpBADtFr5o
    cudart64_65.dll 298 KB
    https://mega.co.nz/#!Eh0GzT4D!Kjhqzl...7VIhVNpUaVpN6U


    Für sonstige DLL-Errors bitte zuerst Google verwenden!


    Quelltext:
    Spoiler!


    Diskussion des Benchmarks bei einer Geforce 980 GTX

    Wie versprochen habe ich eine ausführliche Diskussion des Benchmarks angefertig. Die Problematik ist zwar nach NVIDIAs Statement nicht mehr aktuell, aber eventuell kann man in Zukunft das gut verwenden. Ich weiß auch nicht, ob das jemanden noch interessiert, ob es nicht zu sehr Wall of Text ist, und ob es 100 prozentig korrekt ist, ich hoffe es aber.

    Zuerst soll auf die Hardware-Eigenschaften beziehungsweise Treiber-Eigenschaften eingegangen werden. Hierbei bin ich mir aber zum Teil etwas unsicher, da das nicht dokumentiert ist. Deshalb musste ich das aus den Benchmarks und diversen Stack-Overflow-Posts folgern. Ich weiß auch, dass es durchaus kritisch ist, etwas mit sich selbst zu beweisen. Aber das Gesamtbild scheint zu stimmen. Falls jemand sich mit GPGPU gut auskennen sollte, bitte sofort Kritik äußern!

    Die Geforce 970 GTX hat gemäß NVIDIAs aktualisierten Spezifikationen die folgenden Daten:
    • Schnelles DRAM-Segment: "physikalisch" 0 bis 3.5 GiByte, 1.75 MiByte L2-Cache, volle L2-Cache-Bandbreite, 224-Bit Speicherandindung, 192 GByte/s Peak-DRAM-Bandbreite
    • Langsames DRAM-Segment: "physikalisch" 3.5 bis 4.0 GiByte, 0.25 MiByte L2-Cache, 1/7 L2-Cache-Bandbreite, 32-Bit Speicheranbindung, 28 GByte/s Peak-DRAM-Bandbreite


    CUDA zeigt wahrscheinlich folgendes Allozierungsverhalten:
    • Zuerst alloziert sich CUDA den freien Speicherplatz aus dem 0 bis 3.5 GiByte großen Segment.
    • Dann alloziert es sich den freien Speicherplatz aus dem 3.5 bis 4.0 GiByte großen Segment.
    • Zuletzt alloziert es sich den Speicherplatz aus dem 0 bis 3.5 großen Segment, welcher bereits belegt ist. In diesem Bereich muss die GPU dann irgendwie die Daten Swappen, also die Daten CUDA oder von den anderen Programmen von dem GPU-DRAM auf den CPU-DRAM auslagern.


    CUDA zeigt mit Wahrscheinlichkeit folgendes Swapping-Verhalten beziehungsweise Paging-Verhalten für seinen virtuellen globalen Speicherraum:
    • Das Paging ist einfach assoziativ. Falls eine Page sich im DRAM der GPU befindet, dann kann sie dort auch an nur einer bestimmten physikalischen Addresse sein.
    • Auch kann es in einem CUDA-Prozess nicht zwei Pages geben, welche die selben physikalischen Adressen im GPU-DRAM verwenden. Dadurch können sich die Pages eines CUDA-Prozesses nicht selbst aus dem DRAM der GPU verdrängen. Auch kann man deshalb nur so viel Speicher in CUDA allozieren, wie viel auch auf der GPU physikalisch vorhanden sind.
    • Es ist mir noch unklar, wann genau eine CUDA-Page mit einer Page von einem anderen Prozess geswapt wird. Bei einer CPU geschieht das Swappen in der Regel bei einem Page-Fault, also wenn die Page nicht mehr im DRAM der CPU sondern auf der Platte liegt. Bei den aktuellen NVIDIA GPUs scheint dies nicht der Fall zu sein (siehe unten).
    • Für Speicher-Objekte aus OpenGL und DirectX gilt das einfach assoziative Paging nicht. Das heißt sie dürfen durch das Swapping überall in dem DRAM der GPU eingefügt werden.


    Bei einem Page-Fault in einem Kernel, also einem Programm was auf der GPU läuft, zeigt CUDA folgendes Verhalten:
    • Die Page wird aus dem DRAM der CPU über den PCI-E angefordert.
    • Der Zugriff findet ohne L2-Cache statt.
    • Die Page wird nicht in den DRAM der GPU geladen. Dadurch werden bei einem erneuten Zugriff auf die Page wieder die Daten aus dem DRAM der CPU angefordert.



    Als Nächstes soll das Benchmark diskutiert werden. Dabei wird die Messung mit einer Geforce 970 GTX aus der Antwort Nummer 31 herangenommen und zuerst in ein Diagramm eingetragen:

    Klicke auf die Grafik für eine größere Ansicht 

Name:	Diagramm.jpg 
Hits:	230 
Größe:	43,2 KB 
ID:	471053

    Das Diagramm zeigt, dass innerhalb des CUDA-Speicherbereichs von 0 bis 3072 MiByte, den CUDA sich zuerst alloziert hat, die Messergebnisse einen konstant großen Wert einnehmen. Im Speicherbereich zwischen 3072 bis 3584 MiByte sind die Messergebnisse ebenfalls konstant, aber deutlich niedriger. In den Bereichen von 3584 bis 3840 MiByte sind die Messergebnisse auch konstant und wiederum etwas kleiner. Die verbleibenden 256 MiByte der GPU konnten mit CUDA nicht alloziert werden.

    Als Erstes soll auf den CUDA-Speicherbereich von 0 bis 3072 MiByte eingegangen werden. So wird in diesem CUDA-Speicherbereich eine konstant hohe Speicherbandbreite von 150 GByte/s gemessen, welche in etwa 78 % der Peak-Bandbreite des schnellen Speichersegments der GPU von 192 GByte/s entspricht. Diese 78 % sind in etwa das Maximum, welches ein durch die Speicherbandbreite limitiertes Programm auf der GPU erreichen kann. Auch wird in diesem Bereich durch das Benchmark in etwa eine Cache-Größe von 1792 KiByte geschätzt. Dies entspricht den tatsächlichen Wert der L2-Cache-Größe für das schnelle Speichersegment. Es gibt aber in diesem Bereich bei der Schätzung der L2-Cache-Größe einen Ausreißer bei 384 MiByte, der wahrscheinlich eben wegen der Schätzung entstanden ist. Ebenso ist die L2-Cache-Bandbreite in diesem Bereich mit 396 GByte/s verglichen mit den anderen Messbereichen am höchsten. Dadurch ist es sehr wahrscheinlich, dass dieser CUDA-Speicherbereich in dem schnellen physikalischen Speichersegment von 0 bis 3.5 Gibyte liegt, welches über 224 Bit angebunden ist.

    Als Nächstes sollen die Messungen des CUDA-Speicherbereichs von 3072 bis 3584 MiByte diskutiert werden. Hier beträgt die gemessene DRAM-Bandbreite nur noch und nahezu konstant 22 GByte/s. Das sind in etwa 79 % der Peak-Speicherbandbreite des langsamen Speichersegments. Des Weiteren beträgt die durch das Benchmark geschätzte L2-Cache-Bandbreite mit 77 GByte/s in etwa 19 % der gemessenen Cache-Bandbreite des schnellen Speichersegments. Unter der Annahme, dass dieser CUDA-Speicherbereich im langsamen DRAM-Segment liegt, so wäre ein Bandbreitenverhältnis 1/7 also 14 % zu erwarten. Auch wurde eine Cache-Größe 256 kiByte ermittelt, welche eben der Speichergröße im langsamen Segment entspricht. Somit liegt dieser CUDA-Speicherbereich sehr wahrscheinlich in dem langsamen physikalsichen Speichersegment von 3.5 bis 4.0 GiByte, welches nur über 32 Bit angebunden ist.

    In dem CUDA-Speicherbereich von 3648 bis 3776 MiByte ist die geschätzte DRAM-Bandbreite mit 12.7 GByte/s in etwa genauso hoch wie die geschätzte L2-Cache-Bandbreite mit ebenfalls 12.7 GByte/s. Auch schlägt die Ermittlung einer L2-Cache-Größe fehl. Deshalb ist es sehr wahrscheinlich, dass kein L2-Caching stattfindet. Die geschätzte DRAM-Bandbreite beträgt in etwa 80 % der PCI-E 3.0 Bandbreite mit 15.7 GByte/s. Da bei einem Page-Fault auf der GPU kein L2-Caching stattfindet und die Daten jedes mal über den PCI-E aus dem DRAM der CPU angefordert werden, verhält sich die GPU so, als ob dieser Speicherbereich sich im DRAM der CPU ausgelagert ist.

    CUDA konnte sich allerdings nur 3840 MiByte allozieren. Das heißt 256 MiByte konnten durch das Benchmark nicht untersucht werden. Wahrscheinlich liegen diese 256 MiByte im schnellen DRAM-Segment und sind ein Teilrest, da sich das Benchmark nur 128 MiByte große Blöcke alloziert.

    Damit scheint insgesamt der physikalische Speicher in etwa wie folgt belegt zu sein:
    • 0 bis 512 MiByte (schnelles Segment): Hierinnen befinden sich Windows und andere Programme. Auch würde sich dort der dort der CUDA-Speicherbereich von 3584 bis 3840 MiByte befinden, wenn er nicht gerade wie in diesem Benchmark in dem DRAM der CPU ausgelagert ist.
    • 512 bis 3584 MiByte(schnelles Segment): Hier befindet sich nur der CUDA-Speicherbereich von 0 bis 3072 MiByte
    • 3584 bis 4096 MiByte(langsames Segment): Der Cuda-Speicherbereich von 3072 bis 3584 MiByte


    Insgesamt stimmt das Benchmark somit sehr gut mit den aktualisierten Spezifikationen der GPU überein.

    1. Edit: Habe beide Benchmarks zusammengeführt.
    2. Edit: Diskussion eingebaut.

  2. Anzeige
    Logge dich ein, um diese Anzeige nicht zu sehen.
  3. #2
    Commander
    Dabei seit
    Dez 2014
    Beiträge
    2.254

    AW: Nai's Benchmarkthread

    super sache von dir und dein benchmark geht grad um die ganze welt (Y) respekt
    Mein Schwarzer Gaming Monolit<<<Klick>>>

    Zitat des Tages :

    "Der Vorteil der Klugheit besteht darin, dass man sich dumm stellen kann. Das Gegenteil ist schon schwieriger."
    Nvidia Firmenleitung

  4. #3
    Commodore
    Dabei seit
    Apr 2012
    Ort
    Baden Württemberg
    Beiträge
    4.502

    AW: Nai's Benchmarkthread

    @Nai

    Kannst Du einen solchen Benchmark auch für die AMD Grafikkarten schreiben ? Dieser hier ist jetzt ja nur für Nvidia Karten, Oder ?

    mfg Zotac2012
    My sysProfile !
    i5 8600K@5,0 GHz / MSI GTX 1070 mit INFILTRATOR - Unreal Engine 4 Demo:
    https://www.youtube.com/watch?v=IbYNtZb46QQ
    The Division Ingame Benchmark
    https://www.youtube.com/watch?v=DNHtms1EGjs

  5. #4
    Lt. Commander
    Ersteller dieses Themas

    Dabei seit
    Aug 2012
    Beiträge
    1.440

    AW: Nai's Benchmarkthread

    Ich habe mehr oder weniger folgendes Problem, wenn ich das ganze mit OpenGL oder OpenCL machen würde:

    Bei CUDA basiert das Speichermanagment auf einen virtuellen Speicherraum, auf den über Zeiger zugegriffen wird. Auch können sich bei CUDA und bei aktuellen GPUs die Daten eines Prozesses beim Swapping nicht selbst aus dem DRAM der GPU verdrängen. Dies ist vermutlich darauf zurückzuführen, dass der virtuelle Speicherraum relativ einfach ist und keinen (ausgefeilten) Page Table besitzt. Es ist nur möglich, dass sich die Daten von unterschiedlichen Prozessen aus dem DRAM der GPU verdrängen. Dadurch kann sich das Benchmark nicht selbst verfälschen. Es kann nur durch andere Prozesse, die im Hintergrund laufen und auch den DRAM der GPU verwenden, verfälscht werden.

    Bei OpenGL und OpenCL ist das Speichermanagement abstraker und basiert auf Texturen oder Buffern. Der Treiber darf nun die Buffer und Texturen nach Lust und Laune im DRAM der GPU hin und her kopieren und in den DRAM der CPU swappen. Bei CUDAs virtuellen Speicherraum ist dieses hin und her kopieren *momentan* nicht möglich, da ansonsten die virtuellen Zeiger kaputt gehen würden. Deshalb kann unter OpenGL oder OpenCL die GPU die Position der Daten des Benchmarks im DRAM ändern oder sogar in den DRAM der CPU swappen, während das Benchmark läuft. Dadurch würde sich das Benchmark selbst verfälschen. Somit bräuchte ich eine halbwegs elegante Möglichkeit um das Swapping zu vermeiden. Dafür fällt mir momentan nichts wirklich brauchbares ein.

  6. #5
    Lt. Junior Grade
    Dabei seit
    Jun 2011
    Beiträge
    348

    AW: Nai's Benchmarkthread

    Früher konnte man deaktivierte bereiche der Grafikkarte mit Rivatuner freischalten, gibt es sowas ähnliches noch?
    Ich bezweifel das Nvidia im Chip ein Lasercut macht.

  7. #6
    Lt. Commander
    Ersteller dieses Themas

    Dabei seit
    Aug 2012
    Beiträge
    1.440

    AW: Nai's Benchmarkthread

    Bitte Diskussionen über Sachen, die nichts mit dem Benchmark zu tun haben, hier unterlassen. Ansonsten wird das unübersichtlich.

  8. #7
    Ensign
    Dabei seit
    Nov 2008
    Beiträge
    176

    AW: Nai's Benchmarkthread

    Noch ein Hinweis bevor das Geheule los geht, man sollte vor dem Benchen die Windows DWM ausstellen weil diese sonst GPU Speicher für sich beansprucht und das Ergebnis deutlich verfälscht. Die letzten Chunks werden meist von Windows besetzt und dadurch sieht aus als hätte man ein Leistungseinbruch.

    @Nai: Super Job, bist über Nacht Weltberühmt Danke schön

  9. #8
    Lt. Commander
    Ersteller dieses Themas

    Dabei seit
    Aug 2012
    Beiträge
    1.440

    AW: Nai's Benchmarkthread

    Das sollte in diesem Fall *hoffentlich* nichts ausmachen, da das Benchmark das *hoffentlich* "erkennen" kann.

  10. #9
    Ensign
    Dabei seit
    Feb 2011
    Beiträge
    178

    AW: Nai's Benchmarkthread

    Programm geht bei mir nicht win 8.1
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Klicke auf die Grafik für eine größere Ansicht 

Name:	Unbenannt.png 
Hits:	189 
Größe:	17,8 KB 
ID:	470348  

  11. #10
    Lt. Commander
    Ersteller dieses Themas

    Dabei seit
    Aug 2012
    Beiträge
    1.440

    AW: Nai's Benchmarkthread

    Ok noch CUDA-DLLs zum downloaden verlinkt.

  12. #11
    Ensign
    Dabei seit
    Feb 2011
    Beiträge
    178

    AW: Nai's Benchmarkthread

    Mein Ergebniss heißt wohl auch nur 3,5GB oder
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken Klicke auf die Grafik für eine größere Ansicht 

Name:	Unbenannt2.png 
Hits:	463 
Größe:	63,3 KB 
ID:	470349  

  13. #12
    Lt. Commander
    Ersteller dieses Themas

    Dabei seit
    Aug 2012
    Beiträge
    1.440

    AW: Nai's Benchmarkthread

    Ja sieht man m.E. nun sehr schön. Die letzten ~ 500 Megabyte, wenn sich CUDA die alloziert, haben eine deutlich geringere L2-Cache-Größe. Auch das Herausfiltern vom Swapping klappt wahrscheinlich und hoffentlich ganz gut, weshalb man es als Störung ausschließen kann.

  14. #13
    Lt. Junior Grade
    Dabei seit
    Apr 2008
    Beiträge
    327

    AW: Nai's Benchmarkthread

    Gleiches Ergebnis hier. Allerdings ist schon nach 3456 Schluss.

    Spoiler!

  15. #14
    Lt. Commander
    Ersteller dieses Themas

    Dabei seit
    Aug 2012
    Beiträge
    1.440

    AW: Nai's Benchmarkthread

    Weil du mehr im Hintergrund laufen hast. Die GPU belegt diejenigen Bereiche, bei denen schon andere Daten von Windows und co vorhanden sind als letztes "doppelt", da sie dann swappen muss.

    Deine Speicherbelegung deiner GPU sieht vermutlich in etwa so aus:
    0 bis 512 MiByte @ 224-Bit Speicheranbindung: Windows + Programme die im Hintergrund laufen + Chunks 27 bis 29 des Benchmarks
    512 bis 3584 MiByte @ 224-Bit Speicheranbindung: Chunks 0 bis 22 des Benchmarks
    3584 bis 4096 MiByte @ 32-Bit Speicheranbindung: Chunks 23 bis 26 des Benchmarks

  16. #15
    Admiral
    Dabei seit
    Feb 2005
    Beiträge
    7.345

    AW: Nai's Benchmarkthread

    Gibt´s auch eine 32Bit-Version von dem Programm?

  17. #16
    Lt. Commander
    Ersteller dieses Themas

    Dabei seit
    Aug 2012
    Beiträge
    1.440

    AW: Nai's Benchmarkthread

    Ich kann in CUDA mit einem 32-Bit Programm auch nur ~4 Gibyte an Speicher auf der GPU allozieren. Deshalb ist das Programm momentan nur 64-Bit. Evtl lade ich es später für 32-Bit hoch, wobei man damit auch nur "kleinere" GPUs benchen kann.

  18. #17
    Admiral
    Dabei seit
    Feb 2005
    Beiträge
    7.345

    AW: Nai's Benchmarkthread

    Ich habe ja nur eine kleinere GPU (2GB).

  19. #18
    Fleet Admiral
    Dabei seit
    Jun 2011
    Ort
    Jetzt auch in Ihrer Nähe
    Beiträge
    10.549

    AW: Nai's Benchmarkthread

    -EVGA GTX 970 FTW ACX 2.0
    -64bit

    Spoiler!


    Bei 3GB wirds lansgamer und ab 3,5 nochmal deutlich...
    Geändert von Spillunke (27.01.2015 um 17:24 Uhr)
    i7 4790K @4,5GHz | Corsair H100i + NB-BlackSilentPro PL2 | Asrock Z87 Pro4 | Crucial Ballistix Sport 16GB | EVGA GTX 1080 FTW @2063MHz & 12Gbps VRAM | 128GB Samsung 830/480GB SanDisk Ultra II SSD | 1TB/2TB WD HDD | Samsung SH-B123L | be quiet! PP10 500W-CM | CM Mastercase Pro 5 + 3x EKL Wing Boost 2 Toxic Green+ 140mm | Win 10 Pro x64 | BenQ GW2765HT + GW2270H

  20. #19
    Ensign
    Dabei seit
    Nov 2008
    Beiträge
    176

    AW: Nai's Benchmarkthread

    So, nun kann ich auch mein Ergebnis posten. Hab hier den DWM ausgestellt, deswegen geht der Karte die Puste laut dem Bench auch etwas später weg.


    Spoiler!


    €:Wird schon stimmen das man mit der GTX 970 erst ab 3,5 Probs hat, ab 3GB sollten keine auftreten außer man ist im Windows Fenstermodus, weil diese auch Resourcen verschwendet wie man eindeutig sieht.
    Geändert von Elite_Warrior (27.01.2015 um 18:47 Uhr)

  21. #20
    Lt. Junior Grade
    Dabei seit
    Jan 2004
    Beiträge
    267

    AW: Nai's Benchmarkthread

    Gigabyte G1 GTX970

    Mir scheint ein ganzes GB zu fehlen bzw. langsam zu sein.

    Spoiler!
    Geändert von hennich (27.01.2015 um 21:26 Uhr)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  
Forum-Layout: Feste Breite / Flexible Breite