1 / 14

Rethinking Hardware and Software for Disciplined Parallelism

Rethinking Hardware and Software for Disciplined Parallelism. Sarita V. Adve University of Illinois sadve@illinois.edu. Sequential CS 101. Java. Parallel CS 101. Threads. Java. Parallel CS 101. Threads. Java. Data races. Parallel CS 101. Threads. Java. Data races. Non-determinism.

dermot
Télécharger la présentation

Rethinking Hardware and Software for Disciplined Parallelism

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Threads Java

  4. Parallel CS 101 Threads Java Data races

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

  6. Parallel CS 101 Threads Java Memory Model Non-determinism Data races • 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

More Related