Software & the Concurrency Revolution by Sutter & Larus

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

2. 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.”

3. A look back at computing history • ENIAC* – 1949 • UNIVAC – 1951 @ US Census Bureau • 1952 – 2 installations • 1953 – 3 installations • 1954 – 13 installations • IBM – • Punch Card Systems (tabulations) • 1951 – IBM 701 • 1954: Fortran & Cobol established

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

5. Current State of Parallel HW • Distributed systems • Multicore chips • Graphics processing units (GPU) • Etc. • Software? SeverelyLacking • Similar to 1940’s to 1950’s • Programs may run slower now

6. Turning Point • Performance of programs will not increase due to HW improvements • Need for asynchronous processing • Barriers • It’s hard; new way of thinking • Inadequate tools & languages • Difficult to find concurrency in some applications

7. Concurrency a disruption? • Concurrency = high performance • hw, sw, systems, languages w/ will survive • Concurrent programming is difficult • Context-sensitivity & Synchronization analysis • These are provably undecidable • People don’t tend to think concurrently about programming

8. Programming Models • Granularity(fine – coarse*) • Extent to which a problem is broken in to smaller parts • Relative measure of the size of a task • Degree of Coupling (loosely* – tightly) • Relative measure of dependence of tasks • Communication • Synchronization • Regularity • Regular vs. Irregular parallelism

9. 3 Parallel Models Independent Parallelism • Inherently, Embarassingly • Operations applied independently to each data item • Fine grained, uncoupled • E.G. A PU is assigned to each element of a 100 X 100 element array to double the value • Coarse grained, uncoupled • E.G. web-based apps, multi-simulations

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

11. 3 Parallel Models Unstructured Parallelism • Most general, least disciplined • Threads w/ synchronization • Unpredictable access to shared data • Requires explicit synchronization • Messages • Via shared memory • Via message passing

12. Locks • Mechanism for protecting data/code from conflicting or concurrent access (SW) • E.G. Semaphore, Monitor • Standard locks don’t work in parallel • Not composable – deadlock • Standard libraries may quit working • Programmers MUST follow all rules! • Global vs. Local procedures • Local synchronization difficult

13. Lock Alternatives • Lock-free programming • Use knowledge of memory to design d.s. not needing locking • Difficult, fragile, still publishable • Transactional memory • Language – ability to write atomic blocks • Still in research

14. 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 understand • During development • During maintenance

15. 3 Methods for Realizing Parallelism • Explicit Programming • Implicit Programming • Automatic Parallelism

16. Explicit Programmingfor Parallelization • Programmer states exactly where concurrency can occur • ADV: Programmer can fully exploit concurrent potential • DIS: Need higher-level language features & higher level of programming skill

17. Implicit Programmingfor Parallelization • Concurrency hides in libraries or API’s; programmer maintains sequential view • ADV: Inexperienced programmers can use concurrency • DIS: Cannot realize all concurrency & difficult to design

18. Automatic Parallelization • Compiler extracts parallelism in sequential program. • ADV: Does the work for us • DIS: Has not worked well in practice • Hard for simple languages • Nearly impossible for complex languages (pointers) • Sequential algorithms have little concurrency

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

20. Abstraction • Low-level: Thread & Lock level • Not a good building block, viewpoint • High-level: express tasks with inherent concurrency, system schedules on HW • Easier transition to new HW • Easier for programmer

21. 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 value • Active object: non-standard; each object runs own thread; outside method calls are asynchronous

22. 4 Needed Programming Tools • Defect detection • Debugger • Bottleneck detection • Testing aids

23. Defect (Error) Detection • New types of errors • Race conditions & Livelocks • Difficult to reproduce, non-deterministic • Modularity & High-level abstraction help • Cannot test modules independently • You can, but… • Too many possible paths • Active research

24. Debuggers • Loggers • Track Messages • Causality Trails • Reverse execution

25. Bottleneck Detection • Lock Contention • Cache Coherence Overheads • Lock Convoys

26. Testing Aids • Extend Coverage metrics • Not just of statement is executed, but with what other concurrent statements • Stress testing • Need extending • Needs determinism

27. 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.”

28. Conclusion – Goals • Parallel Apps will (again) run faster on new HW • New Interfaces • Systems designers: focus on concurrency • Operating systems • Languages • Abstractions