Download presentation

Presentation is loading. Please wait.

Published byTaryn Coombs Modified about 1 year ago

1
Chapter 7 Multicores, Multiprocessors, and Clusters

2
Chapter 7 — Multicores, Multiprocessors, and Clusters — 2 Introduction Goal: connecting multiple computers to get higher performance Multiprocessors Scalability, availability, power efficiency Job-level (process-level) parallelism High throughput for independent jobs Parallel processing program Single program run on multiple processors Multicore microprocessors Chips with multiple processors (cores) §9.1 Introduction

3
Chapter 7 — Multicores, Multiprocessors, and Clusters — 3 Hardware and Software Hardware Serial: e.g., Pentium 4 Parallel: e.g., quad-core Xeon e5345 Software Sequential: e.g., matrix multiplication Concurrent: e.g., operating system Sequential/concurrent software can run on serial/parallel hardware Challenge: making effective use of parallel hardware

4
Chapter 7 — Multicores, Multiprocessors, and Clusters — 4 FIGURE 7.1 Hardware/software categorization and examples of application perspective on concurrency versus hardware perspective on parallelism.

5
Chapter 7 — Multicores, Multiprocessors, and Clusters — 5 What We’ve Already Covered §2.11: Parallelism and Instructions Synchronization §3.6: Parallelism and Computer Arithmetic Associativity §4.10: Parallelism and Advanced Instruction-Level Parallelism §5.8: Parallelism and Memory Hierarchies Cache Coherence §6.9: Parallelism and I/O: Redundant Arrays of Inexpensive Disks

6
Chapter 7 — Multicores, Multiprocessors, and Clusters — 6 Parallel Programming Parallel software is the problem Need to get significant performance improvement Otherwise, just use a faster uniprocessor, since it’s easier! Difficulties Partitioning Coordination Communications overhead §7.2 The Difficulty of Creating Parallel Processing Programs

7
Chapter 7 — Multicores, Multiprocessors, and Clusters — 7 Amdahl’s Law Sequential part can limit speedup Example: 100 processors, 90× speedup? T new = T parallelizable /100 + T sequential Solving: F parallelizable = Need sequential part to be 0.1% of original time

8
Chapter 7 — Multicores, Multiprocessors, and Clusters — 8 Scaling Example Workload: sum of 10 scalars, and 10 × 10 matrix sum Speed up from 10 to 100 processors Single processor: Time = ( ) × t add 10 processors Time = 10 × t add + 100/10 × t add = 20 × t add Speedup = 110/20 = 5.5 (55% of potential) 100 processors Time = 10 × t add + 100/100 × t add = 11 × t add Speedup = 110/11 = 10 (10% of potential) Assumes load can be balanced across processors

9
Chapter 7 — Multicores, Multiprocessors, and Clusters — 9 Scaling Example (cont) What if matrix size is 100 × 100? Single processor: Time = ( ) × t add 10 processors Time = 10 × t add /10 × t add = 1010 × t add Speedup = 10010/1010 = 9.9 (99% of potential) 100 processors Time = 10 × t add /100 × t add = 110 × t add Speedup = 10010/110 = 91 (91% of potential) Assuming load balanced

10
Chapter 7 — Multicores, Multiprocessors, and Clusters — 10 Strong vs Weak Scaling Strong scaling: problem size fixed As in example Weak scaling: problem size proportional to number of processors 10 processors, 10 × 10 matrix Time = 20 × t add 100 processors, 32 × 32 matrix Time = 10 × t add /100 × t add = 20 × t add Constant performance in this example

11
Chapter 7 — Multicores, Multiprocessors, and Clusters — 11 Shared Memory SMP: shared memory multiprocessor Hardware provides single physical address space for all processors Synchronize shared variables using locks Memory access time UMA (uniform) vs. NUMA (nonuniform) §7.3 Shared Memory Multiprocessors

12
Chapter 7 — Multicores, Multiprocessors, and Clusters — 12 FIGURE 7.2 Classic organization of a shared memory multiprocessor.

13
Chapter 7 — Multicores, Multiprocessors, and Clusters — 13 Example: Sum Reduction Sum 100,000 numbers on 100 processor UMA Each processor has ID: 0 ≤ Pn ≤ 99 Partition 1000 numbers per processor Initial summation on each processor sum[Pn] = 0; for (i = 1000*Pn; i < 1000*(Pn+1); i = i + 1) sum[Pn] = sum[Pn] + A[i]; Now need to add these partial sums Reduction: divide and conquer Half the processors add pairs, then quarter, … Need to synchronize between reduction steps

14
Chapter 7 — Multicores, Multiprocessors, and Clusters — 14 Example: Sum Reduction half = 100; repeat synch(); if (half%2 != 0 && Pn == 0) sum[0] = sum[0] + sum[half-1]; /* Conditional sum needed when half is odd; Processor0 gets missing element */ half = half/2; /* dividing line on who sums */ if (Pn < half) sum[Pn] = sum[Pn] + sum[Pn+half]; until (half == 1);

15
Chapter 7 — Multicores, Multiprocessors, and Clusters — 15 FIGURE 7.3 The last four levels of a reduction that sums results from each processor, from bottom to top. For all processors whose number i is less than half, add the sum produced by processor number (i + half) to its sum.

16
Chapter 7 — Multicores, Multiprocessors, and Clusters — 16 Message Passing Each processor has private physical address space Hardware sends/receives messages between processors §7.4 Clusters and Other Message-Passing Multiprocessors

17
Chapter 7 — Multicores, Multiprocessors, and Clusters — 17 FIGURE 7.4 Classic organization of a multiprocessor with multiple private address spaces, traditionally called a message-passing multiprocessor. Note that unlike the SMP in Figure 7.2, the interconnection network is not between the caches and memory but is instead between processor-memory nodes.

18
Chapter 7 — Multicores, Multiprocessors, and Clusters — 18 Loosely Coupled Clusters Network of independent computers Each has private memory and OS Connected using I/O system E.g., Ethernet/switch, Internet Suitable for applications with independent tasks Web servers, databases, simulations, … High availability, scalable, affordable Problems Administration cost (prefer virtual machines) Low interconnect bandwidth c.f. processor/memory bandwidth on an SMP

19
Chapter 7 — Multicores, Multiprocessors, and Clusters — 19 Sum Reduction (Again) Sum 100,000 on 100 processors First distribute 100 numbers to each The do partial sums sum = 0; for (i = 0; i<1000; i = i + 1) sum = sum + AN[i]; Reduction Half the processors send, other half receive and add The quarter send, quarter receive and add, …

20
Chapter 7 — Multicores, Multiprocessors, and Clusters — 20 Sum Reduction (Again) Given send() and receive() operations limit = 100; half = 100;/* 100 processors */ repeat half = (half+1)/2; /* send vs. receive dividing line */ if (Pn >= half && Pn < limit) send(Pn - half, sum); if (Pn < (limit/2)) sum = sum + receive(); limit = half; /* upper limit of senders */ until (half == 1); /* exit with final sum */ Send/receive also provide synchronization Assumes send/receive take similar time to addition

21
Chapter 7 — Multicores, Multiprocessors, and Clusters — 21 Grid Computing Separate computers interconnected by long-haul networks E.g., Internet connections Work units farmed out, results sent back Can make use of idle time on PCs E.g., World Community Grid

22
Chapter 7 — Multicores, Multiprocessors, and Clusters — 22 Multithreading Performing multiple threads of execution in parallel Replicate registers, PC, etc. Fast switching between threads Fine-grain multithreading Switch threads after each cycle Interleave instruction execution If one thread stalls, others are executed Coarse-grain multithreading Only switch on long stall (e.g., L2-cache miss) Simplifies hardware, but doesn’t hide short stalls (eg, data hazards) §7.5 Hardware Multithreading

23
Chapter 7 — Multicores, Multiprocessors, and Clusters — 23 Simultaneous Multithreading In multiple-issue dynamically scheduled processor Schedule instructions from multiple threads Instructions from independent threads execute when function units are available Within threads, dependencies handled by scheduling and register renaming Example: Intel Pentium-4 HT Two threads: duplicated registers, shared function units and caches

24
Chapter 7 — Multicores, Multiprocessors, and Clusters — 24 Multithreading Example

25
Chapter 7 — Multicores, Multiprocessors, and Clusters — 25 FIGURE 7.5 How four threads use the issue slots of a superscalar processor in different approaches. The four threads at the top show how each would execute running alone on a standard superscalar processor without multithreading support. The three examples at the bottom show how they would execute running together in three multithreading options. The horizontal dimension represents the instruction issue capability in each clock cycle. The vertical dimension represents a sequence of clock cycles. An empty (white) box indicates that the corresponding issue slot is unused in that clock cycle. The shades of gray and color correspond to four different threads in the multithreading processors. The additional pipe line start-up effects for coarse multithreading, which are not illustrated in this figure, would lead to further loss in throughput for coarse multithreading. Copyright © 2009 Elsevier, Inc. All rights reserved.

26
Chapter 7 — Multicores, Multiprocessors, and Clusters — 26 Future of Multithreading Will it survive? In what form? Power considerations simplified microarchitectures Simpler forms of multithreading Tolerating cache-miss latency Thread switch may be most effective Multiple simple cores might share resources more effectively

27
Chapter 7 — Multicores, Multiprocessors, and Clusters — 27 Instruction and Data Streams An alternate classification §7.6 SISD, MIMD, SIMD, SPMD, and Vector Data Streams SingleMultiple Instruction Streams SingleSISD: Intel Pentium 4 SIMD: SSE instructions of x86 MultipleMISD: No examples today MIMD: Intel Xeon e5345 SPMD: Single Program Multiple Data A parallel program on a MIMD computer Conditional code for different processors

28
Chapter 7 — Multicores, Multiprocessors, and Clusters — 28 FIGURE 7.6 Hardware categorization and examples based on number of instruction streams and data streams: SISD, SIMD, MISD, and MIMD.

29
Chapter 7 — Multicores, Multiprocessors, and Clusters — 29 SIMD Operate elementwise on vectors of data E.g., MMX and SSE instructions in x86 Multiple data elements in 128-bit wide registers All processors execute the same instruction at the same time Each with different data address, etc. Simplifies synchronization Reduced instruction control hardware Works best for highly data-parallel applications

30
Chapter 7 — Multicores, Multiprocessors, and Clusters — 30 Vector Processors Highly pipelined function units Stream data from/to vector registers to units Data collected from memory into registers Results stored from registers to memory Example: Vector extension to MIPS 32 × 64-element registers (64-bit elements) Vector instructions lv, sv : load/store vector addv.d : add vectors of double addvs.d : add scalar to each element of vector of double Significantly reduces instruction-fetch bandwidth

31
Chapter 7 — Multicores, Multiprocessors, and Clusters — 31 Example: DAXPY (Y = a × X + Y) Conventional MIPS code l.d $f0,a($sp) ;load scalar a addiu r4,$s0,#512 ;upper bound of what to load loop: l.d $f2,0($s0) ;load x(i) mul.d $f2,$f2,$f0 ;a × x(i) l.d $f4,0($s1) ;load y(i) add.d $f4,$f4,$f2 ;a × x(i) + y(i) s.d $f4,0($s1) ;store into y(i) addiu $s0,$s0,#8 ;increment index to x addiu $s1,$s1,#8 ;increment index to y subu $t0,r4,$s0 ;compute bound bne $t0,$zero,loop ;check if done Vector MIPS code l.d $f0,a($sp) ;load scalar a lv $v1,0($s0) ;load vector x mulvs.d $v2,$v1,$f0 ;vector-scalar multiply lv $v3,0($s1) ;load vector y addv.d $v4,$v2,$v3 ;add y to product sv $v4,0($s1) ;store the result

32
Chapter 7 — Multicores, Multiprocessors, and Clusters — 32 Vector vs. Scalar Vector architectures and compilers Simplify data-parallel programming Explicit statement of absence of loop-carried dependences Reduced checking in hardware Regular access patterns benefit from interleaved and burst memory Avoid control hazards by avoiding loops More general than ad-hoc media extensions (such as MMX, SSE) Better match with compiler technology

33
Chapter 7 — Multicores, Multiprocessors, and Clusters — 33 History of GPUs Early video cards Frame buffer memory with address generation for video output 3D graphics processing Originally high-end computers (e.g., SGI) Moore’s Law lower cost, higher density 3D graphics cards for PCs and game consoles Graphics Processing Units Processors oriented to 3D graphics tasks Vertex/pixel processing, shading, texture mapping, rasterization §7.7 Introduction to Graphics Processing Units

34
Chapter 7 — Multicores, Multiprocessors, and Clusters — 34 Graphics in the System

35
Chapter 7 — Multicores, Multiprocessors, and Clusters — 35 GPU Architectures Processing is highly data-parallel GPUs are highly multithreaded Use thread switching to hide memory latency Less reliance on multi-level caches Graphics memory is wide and high-bandwidth Trend toward general purpose GPUs Heterogeneous CPU/GPU systems CPU for sequential code, GPU for parallel code Programming languages/APIs DirectX, OpenGL C for Graphics (Cg), High Level Shader Language (HLSL) Compute Unified Device Architecture (CUDA)

36
Chapter 7 — Multicores, Multiprocessors, and Clusters — 36 Example: NVIDIA Tesla Streaming multiprocessor 8 × Streaming processors

37
Chapter 7 — Multicores, Multiprocessors, and Clusters — 37 Example: NVIDIA Tesla Streaming Processors Single-precision FP and integer units Each SP is fine-grained multithreaded Warp: group of 32 threads Executed in parallel, SIMD style 8 SPs × 4 clock cycles Hardware contexts for 24 warps Registers, PCs, …

38
Chapter 7 — Multicores, Multiprocessors, and Clusters — 38 FIGURE 7.7 Comparing single core of a Sun UltraSPARC T2 (Niagara 2) to a single Tesla multiprocessor. The T2 core is a single processor and uses hardware-supported multithreading with eight threads. The Tesla multiprocessor contains eight streaming processors and uses hardware-supported multithreading with 24 warps of 32 threads (eight processors times four clock cycles). The T2 can switch every clock cycle, while the Tesla can switch only every two or four clock cycles. One way to compare the two is that the T2 can only multithread the processor over time, while Tesla can multithread over time and over space; that is, across the eight streaming processors as well as segments of four clock cycles. Copyright © 2009 Elsevier, Inc. All rights reserved.

39
Chapter 7 — Multicores, Multiprocessors, and Clusters — 39 Classifying GPUs Don’t fit nicely into SIMD/MIMD model Conditional execution in a thread allows an illusion of MIMD But with performance degredation Need to write general purpose code with care Static: Discovered at Compile Time Dynamic: Discovered at Runtime Instruction-Level Parallelism VLIWSuperscalar Data-Level Parallelism SIMD or VectorTesla Multiprocessor

40
Chapter 7 — Multicores, Multiprocessors, and Clusters — 40 FIGURE 7.8 Hardware categorization of processor architectures and examples based on static versus dynamic and ILP versus DLP.

41
Chapter 7 — Multicores, Multiprocessors, and Clusters — 41 Interconnection Networks Network topologies Arrangements of processors, switches, and links §7.8 Introduction to Multiprocessor Network Topologies BusRing 2D Mesh N-cube (N = 3) Fully connected

42
Chapter 7 — Multicores, Multiprocessors, and Clusters — 42 FIGURE 7.9 Network topologies that have appeared in commercial parallel processors. The colored circles represent switches and the black squares represent processor-memory nodes. Even though a switch has many links, generally only one goes to the processor. The Boolean n-cube topology is an n-dimensional interconnect with 2n nodes, requiring n links per switch (plus one for the processor) and thus n nearest-neighbor nodes. Frequently, these basic topologies have been supplemented with extra arcs to improve performance and reliability.

43
Chapter 7 — Multicores, Multiprocessors, and Clusters — 43 Multistage Networks

44
Chapter 7 — Multicores, Multiprocessors, and Clusters — 44 FIGURE 7.10 Popular multistage network topologies for eight nodes. The switches in these drawings are simpler than in earlier drawings because the links are unidirectional; data comes in at the bottom and exits out the right link. The switch box in c can pass A to C and B to D or B to C and A to D. The crossbar uses n2 switches, where n is the number of processors, while the Omega network uses 2n log2n of the large switch boxes, each of which is logically composed of four of the smaller switches. In this case, the crossbar uses 64 switches versus 12 switch boxes, or 48 switches, in the Omega network. The crossbar, how ever, can support any combination of messages between processors, while the Omega network cannot.

45
Chapter 7 — Multicores, Multiprocessors, and Clusters — 45 Network Characteristics Performance Latency per message (unloaded network) Throughput Link bandwidth Total network bandwidth Bisection bandwidth Congestion delays (depending on traffic) Cost Power Routability in silicon

46
Chapter 7 — Multicores, Multiprocessors, and Clusters — 46 Parallel Benchmarks Linpack: matrix linear algebra SPECrate: parallel run of SPEC CPU programs Job-level parallelism SPLASH: Stanford Parallel Applications for Shared Memory Mix of kernels and applications, strong scaling NAS (NASA Advanced Supercomputing) suite computational fluid dynamics kernels PARSEC (Princeton Application Repository for Shared Memory Computers) suite Multithreaded applications using Pthreads and OpenMP §7.9 Multiprocessor Benchmarks

47
Chapter 7 — Multicores, Multiprocessors, and Clusters — 47 FIGURE 7.11 Examples of parallel benchmarks. Copyright © 2009 Elsevier, Inc. All rights reserved.

48
Chapter 7 — Multicores, Multiprocessors, and Clusters — 48 Code or Applications? Traditional benchmarks Fixed code and data sets Parallel programming is evolving Should algorithms, programming languages, and tools be part of the system? Compare systems, provided they implement a given application E.g., Linpack, Berkeley Design Patterns Would foster innovation in approaches to parallelism

49
Chapter 7 — Multicores, Multiprocessors, and Clusters — 49 Modeling Performance Assume performance metric of interest is achievable GFLOPs/sec Measured using computational kernels from Berkeley Design Patterns Arithmetic intensity of a kernel FLOPs per byte of memory accessed For a given computer, determine Peak GFLOPS (from data sheet) Peak memory bytes/sec (using Stream benchmark) §7.10 Roofline: A Simple Performance Model

50
Chapter 7 — Multicores, Multiprocessors, and Clusters — 50 FIGURE 7.12 Arithmetic intensity, specified as the number of fl oat-point operations to run the program divided by the number of bytes accessed in main memory [Williams, Patterson, 2008]. Some kernels have an arithmetic intensity that scales with problem size, such as Dense Matrix, but there are many kernels with arithmetic intensities independent of problem size. For kernels in this former case, weak scaling can lead to different results, since it puts much less demand on the memory system. Copyright © 2009 Elsevier, Inc. All rights reserved.

51
Chapter 7 — Multicores, Multiprocessors, and Clusters — 51 Roofline Diagram Attainable GPLOPs/sec = Max ( Peak Memory BW × Arithmetic Intensity, Peak FP Performance )

52
Chapter 7 — Multicores, Multiprocessors, and Clusters — 52 FIGURE 7.13 Roofline Model [Williams, Patterson, 2008]. This example has a peak floating-point performance of 16 GFLOPS/sec and a peak memory bandwidth of 16 GB/sec from the Stream benchmark. (Since stream is actually four measurements, this line is the average of the four.) The dotted vertical line in color on the left represents Kernel 1, which has an arithmetic intensity of 0.5 FLOPs/byte. It is limited by memory bandwidth to no more than 8 GFLOPS/sec on this Opteron X2. The dotted vertical line to the right represents Kernel 2, which has an arithmetic intensity of 4 FLOPs/byte. It is limited only computationally to 16 GFLOPS/s. (This data is based on the AMD Opteron X2 (Revision F) using dual cores running at 2 GHz in a dual socket system.).

53
Chapter 7 — Multicores, Multiprocessors, and Clusters — 53 Comparing Systems Example: Opteron X2 vs. Opteron X4 2-core vs. 4-core, 2× FP performance/core, 2.2GHz vs. 2.3GHz Same memory system To get higher performance on X4 than X2 Need high arithmetic intensity Or working set must fit in X4’s 2MB L-3 cache

54
Chapter 7 — Multicores, Multiprocessors, and Clusters — 54 FIGURE 7.14 Roofline models of two generations of Opterons. The Opteron X2 roofline, which is the same as Figure 7.11, is in black, and the Opteron X4 roofline is in color. The bigger ridge point of Opteron X4 means that kernels that where computationally bound on the Opteron X2 could be memory-performance bound on the Opteron X4.

55
Chapter 7 — Multicores, Multiprocessors, and Clusters — 55 Optimizing Performance Optimize FP performance Balance adds & multiplies Improve superscalar ILP and use of SIMD instructions Optimize memory usage Software prefetch Avoid load stalls Memory affinity Avoid non-local data accesses

56
Chapter 7 — Multicores, Multiprocessors, and Clusters — 56 FIGURE 7.15 Roofline model with ceilings. The top graph shows the computational “ceilings” of 8 GFLOPs/sec if the floating-point operation mix is imbalanced and 2 GFLOPs/sec if the optimizations to increase ILP and SIMD are also missing. The bottom graph shows the memory bandwidth ceilings of 11 GB/sec without software prefetching and 4.8 GB/sec if memory affinity optimizations are also missing.

57
Chapter 7 — Multicores, Multiprocessors, and Clusters — 57 Optimizing Performance Choice of optimization depends on arithmetic intensity of code Arithmetic intensity is not always fixed May scale with problem size Caching reduces memory accesses Increases arithmetic intensity

58
Chapter 7 — Multicores, Multiprocessors, and Clusters — 58 FIGURE 7.16 Roofline model with ceilings, overlapping areas shaded, and the two kernels from Figure Kernels whose arithmetic intensity land in the blue trapezoid on the right should focus on computation optimizations, and kernels whose arithmetic intensity land in the gray triangle in the lower left should focus on memory bandwidth optimizations. Those that land in the blue-gray parallelogram in the middle need to worry about both. As Kernel 1 falls in the parallelogram in the middle, try optimizing ILP and SIMD, memory affinity, and software prefetching. Kernel 2 falls in the trapezoid on the right, so try optimizing ILP and SIMD and the balance of floating-point operations.

59
Chapter 7 — Multicores, Multiprocessors, and Clusters — 59 Four Example Systems §7.11 Real Stuff: Benchmarking Four Multicores … 2 × quad-core Intel Xeon e5345 (Clovertown) 2 × quad-core AMD Opteron X (Barcelona)

60
Chapter 7 — Multicores, Multiprocessors, and Clusters — 60 Four Example Systems 2 × oct-core IBM Cell QS20 2 × oct-core Sun UltraSPARC T (Niagara 2)

61
Chapter 7 — Multicores, Multiprocessors, and Clusters — 61 FIGURE 7.17 Four recent multiprocessors, each using two sockets for the processors. Starting from the upper left hand corner, the computers are: (a) Intel Xeon e5345 (Clovertown), (b) AMD Opteron X (Barcelona), (c) Sun UltraSPARC T (Niagara 2), and (d) IBM Cell QS20. Note that the Intel Xeon e5345 (Clovertown) has a separate north bridge chip not found in the other microprocessors..

62
Chapter 7 — Multicores, Multiprocessors, and Clusters — 62 And Their Rooflines Kernels SpMV (left) LBHMD (right) Some optimizations change arithmetic intensity x86 systems have higher peak GFLOPs But harder to achieve, given memory bandwidth

63
Chapter 7 — Multicores, Multiprocessors, and Clusters — 63 FIGURE 7.18 Characteristics of the four recent multicores. Although the Xeon e5345 and Opteron X4 have the same speed DRAMs, the Stream benchmark shows a higher practical memory bandwidth due to the inefficiencies of the front side bus on the Xeon e5345.

64
Chapter 7 — Multicores, Multiprocessors, and Clusters — 64 FIGURE 7.19 Roofline model for multicore multiprocessors in Figure The ceilings are the same as in Figure Starting from the upper left hand corner, the computers are: (a) Intel Xeon e5345 (Clovertown), (b) AMD Opteron X (Barcelona), (c) Sun UltraSPARC T (Niagara 2), and (d) IBM Cell QS20. Note the ridge points for the four microprocessors intersect the X-axis at the arithmetic intensities of 6, 4, 1/3, and 3/4, respectively. The dashed vertical lines are for the two kernels of this section and the stars mark the performance achieved for these kernels after all the optimizations. SpMV is the pair of dashed vertical lines on the left. It has two lines because its arithmetic intensity improved from to based on register blocking optimizations. LBHMD is the dashed vertical lines on the right. It has a pair of lines in (a) and (b) because a cache optimization skips filling the cache block on a miss when the processor would write new data into the entire block. That optimization increases the arithmetic intensity from 0.70 to It’s a single line in (c) at 0.70 because UltraSPARC T2 does not offer the cache optimization. It is a single line at 1.07 in (d) because Cell has local store loaded by DMA, so the program doesn’t fetch unnecessary data as do caches.

65
Chapter 7 — Multicores, Multiprocessors, and Clusters — 65 Performance on SpMV Sparse matrix/vector multiply Irregular memory accesses, memory bound Arithmetic intensity before memory optimization, 0.25 after Xeon vs. Opteron Similar peak FLOPS Xeon limited by shared FSBs and chipset UltraSPARC/Cell vs. x86 20 – 30 vs. 75 peak GFLOPs More cores and memory bandwidth

66
Chapter 7 — Multicores, Multiprocessors, and Clusters — 66 FIGURE 7.20 Performance of SpMV on the four multicores.

67
Chapter 7 — Multicores, Multiprocessors, and Clusters — 67 Performance on LBMHD Fluid dynamics: structured grid over time steps Each point: 75 FP read/write, 1300 FP ops Arithmetic intensity 0.70 before optimization, 1.07 after Opteron vs. UltraSPARC More powerful cores, not limited by memory bandwidth Xeon vs. others Still suffers from memory bottlenecks

68
Chapter 7 — Multicores, Multiprocessors, and Clusters — 68 FIGURE 7.21 Performance of LBMHD on the four multicores.

69
Chapter 7 — Multicores, Multiprocessors, and Clusters — 69 Achieving Performance Compare naïve vs. optimized code If naïve code performs well, it’s easier to write high performance code for the system SystemKernelNaïve GFLOPs/sec Optimized GFLOPs/sec Naïve as % of optimized Intel XeonSpMV LBMHD % 82% AMD Opteron X4 SpMV LBMHD % 50% Sun UltraSPARC T2 SpMV LBMHD % 93% IBM Cell QS20SpMV LBMHD Naïve code not feasible %

70
Chapter 7 — Multicores, Multiprocessors, and Clusters — 70 FIGURE 7.22 Base versus fully optimized performance of the four cores on the two kernels. Note the high fraction of fully optimized performance delivered by the Sun UltraSPARC T2 (Niagara 2). There is no base performance column for the IBM Cell because there is no way to port the code to the SPEs without caches. While you could run the code on the Power core, it has an order of magnitude lower performance than the SPES, so we ignore it in this figure.

71
Chapter 7 — Multicores, Multiprocessors, and Clusters — 71 Fallacies Amdahl’s Law doesn’t apply to parallel computers Since we can achieve linear speedup But only on applications with weak scaling Peak performance tracks observed performance Marketers like this approach! But compare Xeon with others in example Need to be aware of bottlenecks §7.12 Fallacies and Pitfalls

72
Chapter 7 — Multicores, Multiprocessors, and Clusters — 72 Pitfalls Not developing the software to take account of a multiprocessor architecture Example: using a single lock for a shared composite resource Serializes accesses, even if they could be done in parallel Use finer-granularity locking

73
Chapter 7 — Multicores, Multiprocessors, and Clusters — 73 Concluding Remarks Goal: higher performance by using multiple processors Difficulties Developing parallel software Devising appropriate architectures Many reasons for optimism Changing software and application environment Chip-level multiprocessors with lower latency, higher bandwidth interconnect An ongoing challenge for computer architects! §7.13 Concluding Remarks

74
MPC Intel Multicore Roadmaps

75
1.Intel® Pentium M (Pentium M = P6 Modified for Low Power Mobile) 1.Pentium M 2.Mobile Pentium 4 2.Mobile Intel® Celeron 1.Basados en Pentium M (Celeron M) 2.Basados en Microarquitectura Core 3.Intel® Core 1.Basados en Pentium M 1.Core Duo 2.Core Solo 2.Basados en Microarquitectura Core 1.Core 2 Solo 2.Core 2 Duo 3.Core 2 Quad 4.Core 2 Extreme 3.Basados en Microarquitectura Nehalem 1.Core i3 2.Core i5 3.Core i7 4.Core vPro

76

77

78

79

80

81

82

83

84

85

86
Chapter 7 — Multicores, Multiprocessors, and Clusters — 86 History of GPUs Early video cards Frame buffer memory with address generation for video output 3D graphics processing Originally high-end computers (e.g., SGI) Moore’s Law lower cost, higher density 3D graphics cards for PCs and game consoles Graphics Processing Units Processors oriented to 3D graphics tasks Vertex/pixel processing, shading, texture mapping, rasterization §7.7 Introduction to Graphics Processing Units

87
Chapter 7 — Multicores, Multiprocessors, and Clusters — 87 Graphics in the System

88
Chapter 7 — Multicores, Multiprocessors, and Clusters — 88 GPU Architectures Processing is highly data-parallel GPUs are highly multithreaded Use thread switching to hide memory latency Less reliance on multi-level caches Graphics memory is wide and high-bandwidth Trend toward general purpose GPUs Heterogeneous CPU/GPU systems CPU for sequential code, GPU for parallel code Programming languages/APIs DirectX, OpenGL C for Graphics (Cg), High Level Shader Language (HLSL) Compute Unified Device Architecture (CUDA) OpenCL

89
Chapter 7 — Multicores, Multiprocessors, and Clusters — 89 Example: NVIDIA Tesla Streaming multiprocessor 8 × Streaming processors

90
Chapter 7 — Multicores, Multiprocessors, and Clusters — 90 Example: NVIDIA Tesla Streaming Processors Single-precision FP and integer units Each SP is fine-grained multithreaded Warp: group of 32 threads Executed in parallel, SIMD style 8 SPs × 4 clock cycles Hardware contexts for 24 warps Registers, PCs, …

91
Chapter 7 — Multicores, Multiprocessors, and Clusters — 91 FIGURE 7.7 Comparing single core of a Sun UltraSPARC T2 (Niagara 2) to a single Tesla multiprocessor. The T2 core is a single processor and uses hardware-supported multithreading with eight threads. The Tesla multiprocessor contains eight streaming processors and uses hardware-supported multithreading with 24 warps of 32 threads (eight processors times four clock cycles). The T2 can switch every clock cycle, while the Tesla can switch only every two or four clock cycles. One way to compare the two is that the T2 can only multithread the processor over time, while Tesla can multithread over time and over space; that is, across the eight streaming processors as well as segments of four clock cycles. Copyright © 2009 Elsevier, Inc. All rights reserved.

92
Chapter 7 — Multicores, Multiprocessors, and Clusters — 92 Classifying GPUs Don’t fit nicely into SIMD/MIMD model Conditional execution in a thread allows an illusion of MIMD But with performance degredation Need to write general purpose code with care Static: Discovered at Compile Time Dynamic: Discovered at Runtime Instruction-Level Parallelism VLIWSuperscalar Data-Level Parallelism SIMD or VectorTesla Multiprocessor

93
Chapter 7 — Multicores, Multiprocessors, and Clusters — 93 FIGURE 7.8 Hardware categorization of processor architectures and examples based on static versus dynamic and ILP versus DLP.

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google