Benchmark sparc vs. x86 von Axel Schmidt (94416)

Präsentation zum Thema: "Benchmark sparc vs. x86 von Axel Schmidt (94416)"—  Präsentation transkript:

1 Benchmark sparc vs. x86 von Axel Schmidt (94416)
Raphael Schlameuß (100753) Axel Schmidt / Raphael Schlameuß

2 Agenda Hardware (Sparc, X86) Prozessor-Features (Sparc, X86)
Benchmark Probleme ?! Erwartete Ergebnisse Ergebnisse Zusammenfassung Fragen und Anregungen ? Axel Schmidt / Raphael Schlameuß

3 Benchmark - Hardware UltraSparc Pentium II SIMBA/SABRE-Chipsatz
UltraSparc IIi, 360 MHz, 256 kB L2 2x 128 MB EDO JEDEC DRAM, 75 MHz Bustakt MDMA-IDE-Controller, 16,7 MB/s 40GB HDD, 7200 min-1, 1863kB Cache ATI 3D Rage Pro PCI, 4MB Netzwerkkarte HAPPY MEAL ASUS P3B-F Mainboard Intel 440BX-Chipsatz Pentium II („Deschutes“), 350 MHz, 512 kB L2 2x 128 MB SDRAM, 100 MHz Bustakt UDMA33-IDE-Controller, 33 MB/s 40GB HDD, 7200 min-1, 1719kB Cache ATI 3D Rage Pro AGP, 8MB Netzwerkkarte Realtek 8139 Axel Schmidt / Raphael Schlameuß

4 UltraSparc IIi – Features
Highly Integrated Superscalar-Processor SPARC-V9 64-Bit-RISC Architektur VISTM Instruction Set 1 UltraSparc IIi CPU mit 360 MHz Takt externer Bus-Takt 90 MHz Axel Schmidt / Raphael Schlameuß

5 UltraSparc IIi – Features
Je 16 kB D- und I-Cache (L1) 256 kB L2-Cache (extern, halber CPU-Takt) 4 Integer-, 3 Gleitpunkt- und 1 Graphic-Units Block-Load/Store-Unit Registerfile mit 64 Bit Registern Axel Schmidt / Raphael Schlameuß

6 Architektur UltraSparc IIi
Axel Schmidt / Raphael Schlameuß

7 Pentium II – Features Out-of-Order Superskalar Processor Core
CISC mit Dynamic Execution Microarchitecture 1 Intel Pentium II CPU mit 350 MHz Takt externer Bus-Takt 100 MHz Axel Schmidt / Raphael Schlameuß

8 Pentium II – Features Je 16 kB D- und I-Cache (L1)
512 kB L2-Cache (extern, halber CPU-Takt) 2 Integer- und 2 MMX-Units 1 Gleitpunkt- und 1 Jump-Unit Load/Store-Unit Axel Schmidt / Raphael Schlameuß

9 Architektur Intel Pentium II
Axel Schmidt / Raphael Schlameuß

10 Benchmark – Probleme ?! Unterschiedliche Hardware
(Mainboard, Grafikkarte, Speicher, Prozessor) Betriebssystemwahl (Solaris, Debian, Gentoo, …) Softwareauswahl (BLAS, LAPACK, LINPACK, Cachebench, Whetstone, Dhrystone) Compileroptimierung ??? Benchmarkergebnisse vergleichbar ? Axel Schmidt / Raphael Schlameuß

11 Betriebssystem Sparc Gentoo Linux (Base 1.6.13)
Stage 1 Installation (32-Bit) CFLAGS: -march=ultrasparc -O2 -m32 -mvis Bootstrapping (Installation des Basissystems [32-Bit]) Update auf stable-Packages (32-Bit) Kernel (mit Gentoo-Patches [64-Bit]) Treiber und Konfigurationen Compiler: gcc-3.4.5 Axel Schmidt / Raphael Schlameuß

12 Betriebssystem x86 Gentoo Linux (Base 1.6.13)
Stage 1 Installation (32-Bit) CFLAGS: -march=pentium2 -O2 -m32 -mmmx Bootstrapping (Installation des Basissystems [32-Bit]) Update auf stable-Packages (32-Bit) Kernel (mit Gentoo-Patches [32-Bit]) Treiber und Konfigurationen Compiler: gcc-3.4.5 Axel Schmidt / Raphael Schlameuß

13 Vorüberlegung Benchmark
Whetstone 1972 (Kombination aus Integer-, Gleitpunkt- und Array- Operationen, Ergebnis in MIPS) Dhrystone 1984 (Integer- und Array-Operationen, Ergebnis in Dhrystone- Loops / s) 1000s / 1000d (LINPACK) Benchmarken von CPU / Cache / Speicher durch Messen von Cache-Zugriffen Lösen Linearer Gleichungssysteme (xAXPY, xGEMV, xGEMM) Compileroptimierung durch CFLAGS Axel Schmidt / Raphael Schlameuß

14 Erwartete Ergebnisse Cache-Zugriff: in etwa identisch (< 256 KByte)
Integer: x86 ≈ sparc Single-Präzision: x86 ≈ sparc Double-Präzision: sparc > x86, wegen 64-Bit Architektur, x86 nur wenige 64-Bit Register (MMX) Compileroptimierung: x86 > sparc Axel Schmidt / Raphael Schlameuß

15 Software für Benchmark
Whetstone (floating-point-Operationen) Dhrystone (integer-Operationen) LINPACK veraltet, deshalb LAPACK (für sparc nicht verfügbar,  LAPACK-ATLAS) LLCBench (Cachebench, Blasbench) BLAS (Basic Linear Algebra Subprograms) Axel Schmidt / Raphael Schlameuß

16 Whetstone 1972 Array-Funktionen (Anteil: 28,91%)
Bedingte Sprünge (Anteil: 15,53%) Integer-Arithmetik (Anteil: 13,65%) Trigonometrische Funktion (Anteil: 1,44%) Funktionsaufrufe (Anteil: 40,47%) Axel Schmidt / Raphael Schlameuß

17 Dhrystone 1984 Array-Funktionen (Anteil: 12,62%)
Bedingte Sprünge (Anteil: 33,01%) Integer-Arithmetik (Anteil: 37,86%) Funktionsaufrufe (Anteil: 16,51%) Axel Schmidt / Raphael Schlameuß

18 Whetstone / Dhrystone Axel Schmidt / Raphael Schlameuß

19 Whetstone / Dhrystone Whetstone (floating-point-Operationen)
ohne Optimierung: Beschleunigung x86  sparc: 1,94 mit Optimierung: Beschleunigung x86  sparc: 1,37 Dhrystone (integer-Operationen) Beschleunigung x86  sparc: 1,63 Beschleunigung x86  sparc: 0,79 Axel Schmidt / Raphael Schlameuß

20 Benchmark LAPACK-ATLAS
ATLAS stellt Schnittstellen für C und Fortran zur Nutzung von LAPACK und BLAS zur Verfügung ATLAS - Automatically Tuned Linear Algebra Software BLAS – Basic Linear Algebra Subprograms LAPACK - Linear Algebra PACKage Axel Schmidt / Raphael Schlameuß

21 Routinen aus LAPACK I Treiber- und Rechen-Routinen
Treiber-Routinen zum Lösen von Problemen wie Lineare Gleichungssysteme Eigenwerte von realen symmetrischen Matrizen Rechen-Routinen für einzelne Aufgaben werden von Treiber-Routinen genutzt Axel Schmidt / Raphael Schlameuß

22 Routinen aus LAPACK II Beispiel einer Routine: SGEMV und DGEMV
S Single precision (32-Bit Gleitpunkt) D Double precision (64-Bit Gleitpunkt) GE General MV Matrix-Vektor-Operationen berechnet die Lösungen zu einem realen System linearer Gleichungen der Form y=α*A*x+β*y, wobei α, β Skalare, A Matrix und x, y Vektoren sind. Axel Schmidt / Raphael Schlameuß

23 LINPACK - SGEFA Pseudocode SGEFA DO k = 1, N find pivot DO j = k+1, N call SAXPY(N-k, -A[k,j], A[k+1,k], A[k+1,j], 1) N=1000 SAXPY – Multiplikation von Skalar und Vektor, Addition von Vektoren DO i = m, N y[i] = a * x[i] + y[i] Skalar a, Vektor x, y Axel Schmidt / Raphael Schlameuß

24 LINPACK – Auswertung I Die Ergebnisse lassen sich folgendermaßen Interpretieren total: Ausführungszeit in Sekunden mflops: Millionen Gleitpunktoperationen pro Sekunde Gewichtung der Operationen: add, sub und mul 1 flop div und sqr 4 flop exp, sin, flop if-Verzweigung 1 flop Berechnung der mflops durch Division von Anzahl flop durch Laufzeit Axel Schmidt / Raphael Schlameuß

25 1000s / 1000d Axel Schmidt / Raphael Schlameuß

26 1000s / 1000d 1000s (single-precision) 1000d (double-precision)
ohne Optimierung: Beschleunigung x86  sparc: 1,52 mit Optimierung: Beschleunigung x86  sparc: 0,90 1000d (double-precision) Beschleunigung x86  sparc: 1,51 Beschleunigung x86  sparc: 1,28 Axel Schmidt / Raphael Schlameuß

27 Software Suite LLCbench Low Level Architectural Characterization Benchmark
Blasbench xAXPY – Vektoraddition mit Skalar xGEMV – Matrix-Vektor-Multiplikation mit Skalar xGEMM – Matrix-Matrix-Multiplikation mit Skalar Cachebench (Performance Cache) Cache read / hand tuned read Cache write / hand tuned write Cache read/modify/write und hand tuned read/modify/write Axel Schmidt / Raphael Schlameuß

28 Blasbench SAXPY / DAXPY – Vektoraddition mit Skalar y=A*x+y
SGEMV / DGEMV – Matrix-Vektor-Multiplikation mit Skalar y=α*A*x+β*y SGEMM / DGEMM – Matrix-Matrix-Multiplikation mit Skalar C=α*op(A)*op(B)+β*C Matrix A, B, C op(A) = mk-Matrix Skalar α, β op(B) = kn-Matrix Vektor x, y C = mn-Matrix Axel Schmidt / Raphael Schlameuß

29 Blasbench – SAXPY Axel Schmidt / Raphael Schlameuß

30 Blasbench - SGEMV Axel Schmidt / Raphael Schlameuß

31 Blasbench – SGEMM Axel Schmidt / Raphael Schlameuß

32 Blasbench - DAXPY Axel Schmidt / Raphael Schlameuß

33 Blasbench - DGEMV Axel Schmidt / Raphael Schlameuß

34 Blasbench - DGEMM Axel Schmidt / Raphael Schlameuß

35 Software Cachebench for all vector length Funktion Cache read
Durchsatzmessung für verschiedene Vektorlängen Pseudo Code: for all vector length timer start for iteration count for I = 0 to vector length register += memory[I] timer stop mit vector length = [256 Byte KByte] Axel Schmidt / Raphael Schlameuß

36 Software Cachebench for all vector length Funktion Cache write
Durchsatzmessung für verschiedene Vektorlängen Pseudo Code: for all vector length timer start for iteration count for I = 0 to vector length memory[I] = register++ timer stop mit vector length = [256 Byte KByte] Axel Schmidt / Raphael Schlameuß

37 Software Cachebench for all vector length
Funktion Cache read / modify / write Durchsatzmessung für verschiedene Vektorlängen Pseudo Code: for all vector length timer start for iteration count for I = 0 to vector length memory[I]++ timer stop mit vector length = [256 Byte KByte] Axel Schmidt / Raphael Schlameuß

38 Cachebench – read (single / double)
Axel Schmidt / Raphael Schlameuß

39 Cachebench – write (single / double)
Axel Schmidt / Raphael Schlameuß

40 Cachebench – read/modify/write (single / double)
Axel Schmidt / Raphael Schlameuß

41 Software Cachebench Funktionen HandCache read, HandCache read / modify / write und HandCache write Handmodifizierter Code, um die Optimierung des Compilers zu testen Jede Schleife referenziert 8 Memory-Elemente statt einem (Degree Eight Unrolling) Jede Operation ist unabhängig von den vorherigen 7 Operationen (Dependency Analysis) Register sind Speicherstellen zugewiesen und werden so oft wie möglich benutzt (Register Re-Use) Axel Schmidt / Raphael Schlameuß

42 Cachebench – hand read (single / double)
Axel Schmidt / Raphael Schlameuß

43 Cachebench – hand write (single / double)
Axel Schmidt / Raphael Schlameuß

44 Cachebench – hand read/modify/write (single / double)
Axel Schmidt / Raphael Schlameuß

45 Whetstone / Dhrystone Axel Schmidt / Raphael Schlameuß

46 Compileroptimierung Whetstone / Dhrystone
Axel Schmidt / Raphael Schlameuß

47 Compileroptimierung x86 Whetstone / Dhrystone
Axel Schmidt / Raphael Schlameuß

48 Compileroptimierung sparc Whetstone / Dhrystone
gcc berücksichtigt die 4 Integer-FU nicht ??? Axel Schmidt / Raphael Schlameuß

49 Compileroptimierung Whetstone / Dhrystone (gcc-3.4.5 – gcc-4.0.2)
Whetstone [MIPS], Dhrystone [1000 Dhrystones/s] Axel Schmidt / Raphael Schlameuß

50 Zusammenfassung Axel Schmidt / Raphael Schlameuß

51 Zusammenfassung Unterschiedlich gute Unterstützung des Compilers für die Architektur (trotz Optimierung) Compiler selbst liefert je nach Version unterschiedliche Ergebnisse Anwenderprogramme sind unterschiedlich gewichtet Benchmarks nicht zwingend repräsentativ (beeinflussbar) Unterschiedliche Philosophie der Hersteller von Prozessoren zeigen sich in Benchmarks (Anwendungsgebiete  Software) Axel Schmidt / Raphael Schlameuß

52 Fragen und Anregungen ? Axel Schmidt / Raphael Schlameuß

53 Quellen http://www.netlib.org/lapack/
bzw. and-x86_002d64-Options Axel Schmidt / Raphael Schlameuß