Software & the Concurrency Revolution - PowerPoint Presentation

Software & the Concurrency Revolution by Sutter & Larus ACM Queue Magazine, Sept. 2005For CMPS 5433 - Halverson 1

In a Nutshell “The concurrency revolution is primarily a software revolution. The difficult problem is not building multicore hardware, but programming it in a way that lets mainstream applications benefit from the continued exponential growth in CPU performance.” 2

A look back at computing historyENIAC* – 1949UNIVAC – 1951 @ US Census Bureau 1952 – 2 installations1953 – 3 installations1954 – 13 installationsIBM – Punch Card Systems (tabulations) 1951 – IBM 701 1954: Fortran & Cobol established 3

Software Crisis Rapid growth in hardware Little development in softwareConsider Apple Computer in 1970’s vs. IBM in the 1980’s 4

Current State of Parallel HW Distributed systemsMulticore chipsGraphics processing units (GPU) Etc.Software? Severely LackingSimilar to 1940’s to 1950’s Programs may run slower now 5

Turning PointPerformance of programs will not increase due to HW improvementsNeed for asynchronous processingBarriers It’s hard; new way of thinkingInadequate tools & languagesDifficult to find concurrency in some applications 6

Concurrency a disruption?Concurrency = high performancehw, sw , systems, languages w/ will surviveConcurrent programming is difficultContext-sensitivity & Synchronization analysisThese are provably undecidablePeople don’t tend to think concurrently about programming 7

Programming ModelsGranularity (fine – coarse*)Extent to which a problem is broken in to smaller partsRelative measure of the size of a taskDegree of Coupling (loosely* – tightly) Relative measure of dependence of tasks CommunicationSynchronization Regularity Regular vs. Irregular parallelism 8

3 Parallel ModelsIndependent ParallelismInherently, EmbarassinglyOperations applied independently to each data item Fine grained, uncoupledE.G. A PU is assigned to each element of a 100 X 100 element array to double the value Coarse grained, uncoupledE.G. web-based apps, multi-simulations 9

3 Parallel Models (cont’d)Regular ParallelismApply same operation to collection of data when computations are dependent Synchronization or dependent resultsFine grainedE.G. Array value becomes sum of 4 nhbrs.Coarse grained E.G. Web apps with access to common DB 10

3 Parallel ModelsUnstructured ParallelismMost general, least disciplinedThreads w/ synchronization Unpredictable access to shared dataRequires explicit synchronizationMessagesVia shared memoryVia message passing 11

LocksMechanism for protecting data/code from conflicting or concurrent access (SW)E.G. Semaphore, MonitorStandard locks don’t work in parallel Not composable – deadlockStandard libraries may quit workingProgrammers MUST follow all rules!Global vs. Local procedures Local synchronization difficult 12

Lock AlternativesLock-free programmingUse knowledge of memory to design d.s . not needing locking Difficult, fragile, still publishableTransactional memoryLanguage – ability to write atomic blocks Still in research 13

Goal for Programming Languages“Higher-level language abstractions, including evolutionary extensions to current imperative languages, so that existing applications can incrementally become concurrent.” Make concurrency easy to understandDuring developmentDuring maintenance 14

3 Methods for Realizing ParallelismExplicit ProgrammingImplicit Programming Automatic Parallelism15

Explicit Programming for Parallelization Programmer states exactly where concurrency can occurADV: Programmer can fully exploit concurrent potential DIS: Need higher-level language features & higher level of programming skill 16

Implicit Programming for Parallelization Concurrency hides in libraries or API’s; programmer maintains sequential viewADV: Inexperienced programmers can use concurrencyDIS: Cannot realize all concurrency & difficult to design 17

Automatic ParallelizationCompiler extracts parallelism in sequential program.ADV: Does the work for usDIS: Has not worked well in practice Hard for simple languagesNearly impossible for complex languages (pointers)Sequential algorithms have little concurrency 18

Imperative vs. Functional LanguagesPascal, C, C++, C#, Java Scheme, ML, HaskellStill many issues to be resolved to see if Functional Languages can provide needed features. 19

Abstraction Low-level: Thread & Lock level Not a good building block, viewpointHigh-level: express tasks with inherent concurrency, system schedules on HWEasier transition to new HWEasier for programmer 20

High-Level Abstraction Asynchronous call: non-blocking; call made but caller keeps working Future: mechanism for returning result from an asynchronous call; a placeholder for the valueActive object : non-standard; each object runs own thread; outside method calls are asynchronous 21

4 Needed Programming ToolsDefect detection DebuggerBottleneck detection Testing aids 22

Defect (Error) DetectionNew types of errorsRace conditions & Livelocks Difficult to reproduce, non-deterministicModularity & High-level abstraction helpCannot test modules independentlyYou can, but…Too many possible pathsActive research 23

Debuggers LoggersTrack MessagesCausality TrailsReverse execution 24

Bottleneck DetectionLock ContentionCache Coherence OverheadsLock Convoys 25

Testing AidsExtend Coverage metricsNot just of statement is executed, but with what other concurrent statementsStress testing Need extendingNeeds determinism26

REPEAT: In a Nutshell “The concurrency revolution is primarily a software revolution. The difficult problem is not building multicore hardware, but programming it in a way that lets mainstream applications benefit from the continued exponential growth in CPU performance.” 27

Conclusion – Goals Parallel Apps will (again) run faster on new HWNew InterfacesSystems designers: focus on concurrency Operating systemsLanguagesAbstractions 28