1. Rethinking Hardware and Software for Disciplined Parallelism Sarita V. Adve University of Illinois sadve@illinois.edu

2. Sequential CS 101 Java

3. Parallel CS 101 Java Threads

4. Parallel CS 101 Java Threads Data races

5. Parallel CS 101 Java Threads Data races Non-determinism

6. Parallel CS 101 Java Threads Data races Non-determinism Memory Model General-purpose parallel models are complex, abandon decades of sequential programming advances – Safety, modularity, composability, maintainability, …

7. The Problem Popular parallel languages are fundamentally broken

8. The Problem Theorem: Popular parallel languages are fundamentally broken Proof: See the Java Memory Model (+ unresolved bug)

9. The Problem Theorem: Popular parallel languages are fundamentally broken Proof: See the Java Memory Model (+ unresolved bug) Memory consistency model = what values can a read return? – 20+ years of research finally led to convergence – But extremely complex * Dealing with data races is very hard * Mismatch between hardware and software evolution We are building on a foundation where even legal values for reads are complex to specify

10. The Problem Theorem: Current parallel languages are fundamentally broken Proof: See the Java Memory Model (+ unresolved bug) Memory model = what values can a read will return? 20+ years of research finally led to convergence – Sequential consistency for data-race-free programs is minimal – Java added MUCH complexity for safety/security * Minimal (complex) semantics for data races, but unresolved bug – C++, C added complexity for experts due to h/w – s/w mismatch * Independent h/w – s/w evolution resulted in painful consequences Should we continue building on a foundation that can’t even specify legal values for reads? Banish shared-memory?

11. The Problem Theorem: Current parallel languages are fundamentally broken Proof: See the Java Memory Model (+ unresolved bug) Memory model = what values can a read will return? 20+ years of research finally led to convergence – Sequential consistency for data-race-free programs is minimal – Java added MUCH complexity for safety/security * Minimal (complex) semantics for data races, but unresolved bug – C++, C added complexity for experts due to h/w – s/w mismatch * Independent h/w – s/w evolution resulted in painful consequences Should we continue building on a foundation that can’t even specify legal values for reads? Banish wild shared-memory!

12. The Opportunity Need disciplined shared-memory parallel languages Banish data races by design Provide determinism by default Support only explicit and controlled non-determinism Explicit side effects (sharing behavior, granularity, …) ??? Discipline is enforced Much momentum from software community What does this have to do with hardware?

13. The Opportunity Memory model = core of parallel hardware/software interface Today’s hardware designed for wild shared memory – Cache coherence, communication architecture, scheduling, … – Inefficient in performance, power, resilience, complexity, … Claim: Disciplined interface  h/w simplicity + efficiency E.g., race-free s/w  race-free (MUCH SIMPLER) coherence protocols E.g., explicit sharing behavior and granularity  efficient communication, data layout, cache design, …

14. The Approach Software enforces disciplined behavior  Software: safe, modular, composable, maintainable, … Hardware designed for disciplined software  Hardware: simple, scalable, power-efficient, … Broad hardware/software research agenda – Interface: semantics, mechanisms at all levels, ISA, … – Rethink hardware: coherence, communication, layout, caches, … – Help software to abide by interface Fundamental shift in software, hardware – But can be done incrementally – Memory models convergence from similar process But this time let’s co-evolve h/w, s/w