Multicore Programming Nir Shavit Tel Aviv University.

Slides:



Advertisements
Similar presentations
Introduction Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit TexPoint fonts used in EMF. Read the TexPoint manual.
Advertisements

The Art of Multiprocessor Programming Nir Shavit, Ori Shalev CS Spring 2007 (Based on the book by Herlihy and Shavit)
Synchronization. How to synchronize processes? – Need to protect access to shared data to avoid problems like race conditions – Typical example: Updating.
CSE431 Chapter 7A.1Irwin, PSU, 2008 CSE 431 Computer Architecture Fall 2008 Chapter 7A: Intro to Multiprocessor Systems Mary Jane Irwin (
Global Environment Model. MUTUAL EXCLUSION PROBLEM The operations used by processes to access to common resources (critical sections) must be mutually.
Multiprocessors— Large vs. Small Scale Multiprocessors— Large vs. Small Scale.
Lecture 6: Multicore Systems
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Silberschatz, Galvin and Gagne ©2007 Operating System Concepts with Java – 7 th Edition, Nov 15, 2006 Chapter 6 (a): Synchronization.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 4: Mutual Exclusion.
Mutual Exclusion.
Mutual Exclusion The Art of Multiprocessor Programming Spring 2007.
Concurrency The need for speed. Why concurrency? Moore’s law: 1. The number of components on a chip doubles about every 18 months 2. The speed of computation.
Introduction Companion slides for
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 3: Introduction.
An Introduction To PARALLEL PROGRAMMING Ing. Andrea Marongiu
Shared Counters and Parallelism Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
ESE Einführung in Software Engineering X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
Introduction Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Rajeev Alur for CIS 640 at Penn, Spring.
Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Concurrent Skip Lists.
Introduction to Multiprocessor Synchronization Maurice Herlihy TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAAA.
A. Frank - P. Weisberg Operating Systems Introduction to Cooperating Processes.
Joram Benham April 2,  Introduction  Motivation  Multicore Processors  Overview, CELL  Advantages of CMPs  Throughput, Latency  Challenges.
Introduction Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Art of Multiprocessor Programming1 This work is licensed under a Creative Commons Attribution- ShareAlike 2.5 License.Creative Commons Attribution- ShareAlike.
© 2009 Matthew J. Sottile, Timothy G. Mattson, and Craig E Rasmussen 1 Concurrency in Programming Languages Matthew J. Sottile Timothy G. Mattson Craig.
LOGO Multi-core Architecture GV: Nguyễn Tiến Dũng Sinh viên: Ngô Quang Thìn Nguyễn Trung Thành Trần Hoàng Điệp Lớp: KSTN-ĐTVT-K52.
Multicore Programming
Multi-Core Architectures
Multi-core Programming Introduction Topics. Topics General Ideas Moore’s Law Amdahl's Law Processes and Threads Concurrency vs. Parallelism.
1 © R. Guerraoui Concurrent Algorithms (Overview) Prof R. Guerraoui Distributed Programming Laboratory.
Introduction to Multiprocessor Synchronization Maurice Herlihy TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAAA.
Parallel Processing Sharing the load. Inside a Processor Chip in Package Circuits Primarily Crystalline Silicon 1 mm – 25 mm on a side 100 million to.
COMP 111 Threads and concurrency Sept 28, Tufts University Computer Science2 Who is this guy? I am not Prof. Couch Obvious? Sam Guyer New assistant.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
Introduction Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit TexPoint fonts used in EMF. Read the TexPoint manual.
Chapter 1 Performance & Technology Trends Read Sections 1.5, 1.6, and 1.8.
Multicore Programming Summer Daily Schedule 09:00am - 10:30am – Lecture 10:30am - 10:50pm - Break 10:50am - 12:20pm - Lecture 12:20pm - 01:20pm.
1 Lecture #21 Shared Objects and Concurrent Programming This material is not available in the textbook. The online powerpoint presentations contain the.
Introduction Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
Concurrent Queues Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Programming Language Basics Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Multiprocessor Architecture Basics Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Concurrent Skip Lists.
1 Lecture #24 Shared Objects and Concurrent Programming This material is not available in the textbook. The online powerpoint presentations contain the.
Lecture 27 Multiprocessor Scheduling. Last lecture: VMM Two old problems: CPU virtualization and memory virtualization I/O virtualization Today Issues.
CSCI1600: Embedded and Real Time Software Lecture 17: Concurrent Programming Steven Reiss, Fall 2015.
Spin Locks and Contention Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
SMP Basics KeyStone Training Multicore Applications Literature Number: SPRPxxx 1.
Concurrency and Performance Based on slides by Henri Casanova.
Agenda  Quick Review  Finish Introduction  Java Threads.
The Relative Power of Synchronization Operations Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Mutual Exclusion -- Addendum. Mutual Exclusion in Critical Sections.
Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Concurrent Skip Lists.
Concurrency Idea. 2 Concurrency idea Challenge –Print primes from 1 to Given –Ten-processor multiprocessor –One thread per processor Goal –Get ten-fold.
CS703 – Advanced Operating Systems
Background on the need for Synchronization
Introduction to Multiprocessor Synchronization
Multiprocessor Synchronization
Simulations and Reductions
Combinatorial Topology and Distributed Computing
CS Multiprocessor Synchronization
CSCI1600: Embedded and Real Time Software
Introduction Companion slides for
CSE 153 Design of Operating Systems Winter 19
CSCI1600: Embedded and Real Time Software
并发算法与理论 Concurrency: Algorithms and Theories
Presentation transcript:

Multicore Programming Nir Shavit Tel Aviv University

Art of Multiprocessor Programming2 Moore’s Law Clock speed flattening sharply Transistor count still rising

Art of Multiprocessor Programming3 Vanishing from your Desktops: The Uniprocesor memory cpu

Art of Multiprocessor Programming4 Your Server: The Shared Memory Multiprocessor (SMP) cache Bus shared memory cache

Art of Multiprocessor Programming5 Your New Server or Desktop: The Multicore Processor (CMP) cache Bus shared memory cache All on the same chip Sun T2000 Niagara

6 From the 2008 press… …Intel has announced a press conference in San Francisco on November 17th, where it will officially launch the Core i7 Nehalem processor… …Sun’s next generation Enterprise T5140 and T5240 servers, based on the 3rd Generation UltraSPARC T2 Plus processor, were released two days ago…

Art of Multiprocessor Programming 7 Why is Kunle Smiling? Niagara 1

Art of Multiprocessor Programming8 Why do we care? Time no longer cures software bloat –The “free ride” is over When you double your program’s path length –You can’t just wait 6 months –Your software must somehow exploit twice as much concurrency

Art of Multiprocessor Programming9 Traditional Scaling Process User code Traditional Uniprocessor Speedup 1.8x 7x 3.6x Time: Moore’s law

Art of Multiprocessor Programming10 Multicore Scaling Process User code Multicore Speedup 1.8x7x3.6x Unfortunately, not so simple…

Art of Multiprocessor Programming11 Real-World Scaling Process 1.8x 2x 2.9x User code Multicore Speedup Parallelization and Synchronization require great care…

Art of Multiprocessor Programming 12 Sequential Computation memory object thread

Art of Multiprocessor Programming 13 Concurrent Computation memory object threads

Art of Multiprocessor Programming14 Asynchrony Sudden unpredictable delays –Cache misses (short) –Page faults (long) –Scheduling quantum used up (really long)

Art of Multiprocessor Programming15 Concurrency Jargon Hardware –Processors Software –Threads, processes Sometimes OK to confuse them, sometimes not.

Art of Multiprocessor Programming16 Parallel Primality Testing Challenge –Print primes from 1 to Given –Ten-processor multiprocessor –One thread per processor Goal –Get ten-fold speedup (or close)

Art of Multiprocessor Programming17 Load Balancing Split the work evenly Each thread tests range of 10 9 … … · P0P0 P1P1 P9P9

Art of Multiprocessor Programming 18 Procedure for Thread i void primePrint { int i = ThreadID.get(); // IDs in {0..9} for (j = i* , j<(i+1)*10 9 ; j++) { if (isPrime(j)) print(j); }

Art of Multiprocessor Programming19 Issues Higher ranges have fewer primes Yet larger numbers harder to test Thread workloads –Uneven –Hard to predict

Art of Multiprocessor Programming20 Issues Higher ranges have fewer primes Yet larger numbers harder to test Thread workloads –Uneven –Hard to predict Need dynamic load balancing rejected

Art of Multiprocessor Programming Shared Counter each thread takes a number

Art of Multiprocessor Programming 22 Procedure for Thread i int counter = new Counter(1); void primePrint { long j = 0; while (j < ) { j = counter.getAndIncrement(); if (isPrime(j)) print(j); }

Art of Multiprocessor Programming 23 Counter counter = new Counter(1); void primePrint { long j = 0; while (j < ) { j = counter.getAndIncrement(); if (isPrime(j)) print(j); } Procedure for Thread i Shared counter object

Art of Multiprocessor Programming24 Where Things Reside cache Bus cache 1 shared counter shared memory void primePrint { int i = ThreadID.get(); // IDs in {0..9} for (j = i* , j<(i+1)*10 9 ; j++) { if (isPrime(j)) print(j); } code Local variables

Art of Multiprocessor Programming 25 Procedure for Thread i Counter counter = new Counter(1); void primePrint { long j = 0; while (j < ) { j = counter.getAndIncrement(); if (isPrime(j)) print(j); } Stop when every value taken

Art of Multiprocessor Programming 26 Counter counter = new Counter(1); void primePrint { long j = 0; while (j < ) { j = counter.getAndIncrement(); if (isPrime(j)) print(j); } Procedure for Thread i Increment & return each new value

Art of Multiprocessor Programming 27 Counter Implementation public class Counter { private long value; public long getAndIncrement() { return value++; }

Art of Multiprocessor Programming 28 Counter Implementation public class Counter { private long value; public long getAndIncrement() { return value++; } OK for single thread, not for concurrent threads

Art of Multiprocessor Programming 29 What It Means public class Counter { private long value; public long getAndIncrement() { return value++; }

Art of Multiprocessor Programming 30 What It Means public class Counter { private long value; public long getAndIncrement() { return value++; } temp = value; value = temp + 1; return temp;

Art of Multiprocessor Programming 31 time Not so good… Value… 1 read 1 read 1 write 2 read 2 write 3 write 2 232

Art of Multiprocessor Programming 32 Is this problem inherent? If we could only glue reads and writes together… read write read write !!

Art of Multiprocessor Programming 33 Challenge public class Counter { private long value; public long getAndIncrement() { temp = value; value = temp + 1; return temp; }

Art of Multiprocessor Programming 34 Challenge public class Counter { private long value; public long getAndIncrement() { temp = value; value = temp + 1; return temp; } Make these steps atomic (indivisible)

Art of Multiprocessor Programming 35 Hardware Solution public class Counter { private long value; public long getAndIncrement() { temp = value; value = temp + 1; return temp; } ReadModifyWrite() instruction

Art of Multiprocessor Programming 36 An Aside: Java™ public class Counter { private long value; public long getAndIncrement() { synchronized { temp = value; value = temp + 1; } return temp; }

Art of Multiprocessor Programming 37 An Aside: Java™ public class Counter { private long value; public long getAndIncrement() { synchronized { temp = value; value = temp + 1; } return temp; } Synchronized block

Art of Multiprocessor Programming 38 An Aside: Java™ public class Counter { private long value; public long getAndIncrement() { synchronized { temp = value; value = temp + 1; } return temp; } Mutual Exclusion

Art of Multiprocessor Programming 39 Mutual Exclusion or “Alice & Bob share a pond” AB

Art of Multiprocessor Programming 40 Alice has a pet AB

Art of Multiprocessor Programming 41 Bob has a pet AB

Art of Multiprocessor Programming 42 The Problem AB The pets don’t get along

Art of Multiprocessor Programming43 Formalizing the Problem Two types of formal properties in asynchronous computation: Safety Properties –Nothing bad happens ever Liveness Properties –Something good happens eventually

Art of Multiprocessor Programming44 Formalizing our Problem Mutual Exclusion –Both pets never in pond simultaneously –This is a safety property No Deadlock –if only one wants in, it gets in –if both want in, one gets in. –This is a liveness property

Art of Multiprocessor Programming45 Simple Protocol Idea –Just look at the pond Gotcha –Not atomic –Trees obscure the view

Art of Multiprocessor Programming46 Interpretation Threads can’t “see” what other threads are doing Explicit communication required for coordination

Art of Multiprocessor Programming47 Cell Phone Protocol Idea –Bob calls Alice (or vice-versa) Gotcha –Bob takes shower –Alice recharges battery –Bob out shopping for pet food …

Art of Multiprocessor Programming48 Interpretation Message-passing doesn’t work Recipient might not be –Listening –There at all Communication must be –Persistent (like writing) –Not transient (like speaking)

Art of Multiprocessor Programming 49 Can Protocol cola

Art of Multiprocessor Programming 50 Bob conveys a bit AB cola

Art of Multiprocessor Programming 51 Bob conveys a bit AB cola

Art of Multiprocessor Programming52 Can Protocol Idea –Cans on Alice’s windowsill –Strings lead to Bob’s house –Bob pulls strings, knocks over cans Gotcha –Cans cannot be reused –Bob runs out of cans

Art of Multiprocessor Programming53 Interpretation Cannot solve mutual exclusion with interrupts –Sender sets fixed bit in receiver’s space –Receiver resets bit when ready –Requires unbounded number of interrupt bits

Art of Multiprocessor Programming 54 Flag Protocol AB

Art of Multiprocessor Programming 55 Alice’s Protocol (sort of) AB

Art of Multiprocessor Programming 56 Bob’s Protocol (sort of) AB

Art of Multiprocessor Programming57 Alice’s Protocol Raise flag Wait until Bob’s flag is down Unleash pet Lower flag when pet returns

Art of Multiprocessor Programming58 Bob’s Protocol Raise flag Wait until Alice’s flag is down Unleash pet Lower flag when pet returns danger!

Art of Multiprocessor Programming59 Bob’s Protocol (2 nd try) Raise flag While Alice’s flag is up –Lower flag –Wait for Alice’s flag to go down –Raise flag Unleash pet Lower flag when pet returns

Art of Multiprocessor Programming60 Bob’s Protocol Raise flag While Alice’s flag is up –Lower flag –Wait for Alice’s flag to go down –Raise flag Unleash pet Lower flag when pet returns Bob defers to Alice

Art of Multiprocessor Programming61 The Flag Principle Raise the flag Look at other’s flag Flag Principle: –If each raises and looks, then –Last to look must see both flags up

Art of Multiprocessor Programming62 Proof of Mutual Exclusion Assume both pets in pond –Derive a contradiction –By reasoning backwards Consider the last time Alice and Bob each looked before letting the pets in Without loss of generality assume Alice was the last to look…

Art of Multiprocessor Programming 63 Proof time Alice’s last look Alice last raised her flag Bob’s last look QED Alice must have seen Bob’s Flag. A Contradiction Bob last raised flag

Art of Multiprocessor Programming64 Proof of No Deadlock If only one pet wants in, it gets in.

Art of Multiprocessor Programming65 Proof of No Deadlock If only one pet wants in, it gets in. Deadlock requires both continually trying to get in.

Art of Multiprocessor Programming66 Proof of No Deadlock If only one pet wants in, it gets in. Deadlock requires both continually trying to get in. If Bob sees Alice’s flag, he gives her priority (a gentleman…) QED

Art of Multiprocessor Programming67 Remarks Protocol is unfair –Bob’s pet might never get in Protocol uses waiting –If Bob is eaten by his pet, Alice’s pet might never get in

Art of Multiprocessor Programming68 Moral of Story Mutual Exclusion cannot be solved by –transient communication (cell phones) –interrupts (cans) It can be solved by – one-bit shared variables – that can be read or written

Art of Multiprocessor Programming 69 Add Mutex Here public class Counter { private long value; public long getAndIncrement() { mutex.begin() temp = value; value = temp + 1; mutex.end() return temp; }

Art of Multiprocessor Programming 70 Not Here int counter = new Counter(1); void primePrint { long j = 0; while (j < ) { mutex.begin() j = counter.getAndIncrement(); if (isPrime(j)) print(j); mutex.end() }

Art of Multiprocessor Programming71 Why do we care? We want as much of the code as possible to execute concurrently (in parallel) A larger sequential part implies reduced performance Amdahl’s law: this relation is not linear…

Art of Multiprocessor Programming72 Amdahl’s Law Speedup= …of computation given n CPUs instead of 1

Art of Multiprocessor Programming73 Amdahl’s Law Speedup=

Art of Multiprocessor Programming74 Amdahl’s Law Speedup= Parallel fraction

Art of Multiprocessor Programming75 Amdahl’s Law Speedup= Parallel fraction Sequential fraction

Art of Multiprocessor Programming76 Amdahl’s Law Speedup= Parallel fraction Number of processors Sequential fraction

Art of Multiprocessor Programming 77 Example Ten processors 60% concurrent, 40% sequential How close to 10-fold speedup?

Art of Multiprocessor Programming 78 Example Ten processors 60% concurrent, 40% sequential How close to 10-fold speedup? Speedup = 2.17=

Art of Multiprocessor Programming 79 Example Ten processors 80% concurrent, 20% sequential How close to 10-fold speedup?

Art of Multiprocessor Programming 80 Example Ten processors 80% concurrent, 20% sequential How close to 10-fold speedup? Speedup = 3.57=

Art of Multiprocessor Programming 81 Example Ten processors 90% concurrent, 10% sequential How close to 10-fold speedup?

Art of Multiprocessor Programming 82 Example Ten processors 90% concurrent, 10% sequential How close to 10-fold speedup? Speedup = 5.26=

Art of Multiprocessor Programming 83 Example Ten processors 99% concurrent, 01% sequential How close to 10-fold speedup?

Art of Multiprocessor Programming 84 Example Ten processors 99% concurrent, 01% sequential How close to 10-fold speedup? Speedup = 9.17=

Art of Multiprocessor Programming85 The Moral Making good use of our multiple processors (cores) means Finding ways to effectively parallelize our code –Minimize sequential parts –Reduce idle time in which threads wait without

Back to Real-World Multicore Scaling x 2x 2.9x User code Multicore Speedup Must not be managing to reduce sequential % of code

A next generation Intel machine… You pay for N = 8 cores SequentialPart = 25% Amhal  Speedup = only 2.9 times! In Our Example As num cores grows the effect of 25% sequential becomes more accute 4  2.3, 8  2.9, 16  3.4, 32  3.7….

Diminishing Returns

Art of Multiprocessor Programming89 Multicore Computing This is what this my research is about… Inventing tools and techniques that simplify the task of parallelizing the % that is not easy to make concurrent yet may have a large impact on overall speedup

Art of Multiprocessor Programming 90 This work is licensed under a Creative Commons Attribution- ShareAlike 2.5 License.Creative Commons Attribution- ShareAlike 2.5 License You are free: –to Share — to copy, distribute and transmit the work –to Remix — to adapt the work Under the following conditions: –Attribution. You must attribute the work to “The Art of Multiprocessor Programming” (but not in any way that suggests that the authors endorse you or your use of the work). –Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to – Any of the above conditions can be waived if you get permission from the copyright holder. Nothing in this license impairs or restricts the author's moral rights.