1 / 26

‘Obvious Truths’

New Architectures Need New Languages A triumph of optimism over experience! Ian Watson 3 rd July 2009. ‘Obvious Truths’. Single processors will not get faster, we need to go to multi-core There will be a need for processors with many (> 32?) cores

vrist
Télécharger la présentation

‘Obvious Truths’

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. New Architectures Need New LanguagesA triumph of optimism over experience!Ian Watson 3rd July 2009

  2. ‘Obvious Truths’ • Single processors will not get faster, we need to go to multi-core • There will be a need for processors with many (> 32?) cores • These will need to support general purpose applications • Application performance will need to scale with number of cores

  3. ‘Obvious Truths’(2) • General purpose parallel computing needs shared memory • Current shared memory requires cache coherence • Cache coherence doesn’t scale beyond 32 cores • Updateable state makes general purpose parallel programming difficult

  4. ‘Obvious Untruths’ • HPC already has all the answers to parallel programming • Message passing is the answer (hardware or software or both) • Conventional languages already have adequate threading and locking facilities • We can program without state

  5. So what next? • Simplifying the programming model must be the answer – removing facilities is desirable e.g. • Random control transfer • Pointer arithmetic • Explicit memory reclamation • Arbitrary state manipulation is the enemy of parallelism – we must restrict it!

  6. Half Truths? • Functional languages are the answer to parallelism, all we need is to add state (in a controlled way) • Transactional memory can replace locking to simplify the handling of parallel state • Transactional memory can remove the need for cache coherence

  7. Functions+Transactions • The Cambridge Microsoft Haskell work has shown how transactions can be included in a functional language via monads • Is this a style of programming which can be sold to the world as the way ahead for future multi-core (many-core) systems?

  8. Selling a New Language • It must capable of expressing everything that people want • It isn’t just a case of producing something which is a good technical solution • It mustn’t be too complex • It probably needs to look familiar • It needs to be efficient to implement

  9. The Problems • FP is unfamiliar to many existing programmers • Many people find it hard to understand • Even more find monads difficult • In spite of excellent FP compiler technology, imperative programming will probably always be more efficient

  10. Can We Compromise? • Pure functional programs can be executed easily in parallel because they don’t update global state • But if we only exploit parallelism at the function level, local manipulation of state within a function causes no problems • Can we work with such a model?

  11. What Would We Gain? • ‘Easy’ parallelism at function level • This could either be explicit or implicit • Familiarity of low level code • Can use iteration, assignment, updateable arrays etc. • Potential increase in efficiency • Direct mapping to machine code • Explicit memory re-use

  12. What Would We Lose? • Clearly we lose referential transparency within any imperative code • But this is inevitable if we want to manipulate state – even with monads • Clearly, as described so far, we haven’t got the ability to manipulate global state – we need more

  13. Adding Transactions • We should only use shared state when it is really necessary • It should be clear in the language when this is happening • It should be detectable statically • Ideally, it should be possible to check automatically the need for atomic sections

  14. Memory Architecture • With the right underlying programming model we should be able to determine memory regions • Read only • Thread local • Global write once • Global shared (transactional) • Can lead to simplified scalable memory architecture

  15. Experiments • Using Scala to investigate programming styles • Is open source • Has both imperative & functional feature • Not currently transactional • Using Simics based hardware simulator to experiment with memory architectures

  16. Outstanding Questions • Data Parallelism • How to express • How to handle in-place update of parallel data (array) structures • Streaming applications • Purely functional? • Need message passing constructs? • Need additions to the memory model?

  17. Conclusions • None really so far! • But am convinced, from a technical viewpoint, we need new programming approaches • Am fairly convinced that we need to be pragmatic in order to sell a new approach, even if this requires compromises from ideals

  18. Questions?

  19. Transactional Memory • Programming model to simplify manipulation of shared state • Speculative model • Sections of program declared ‘atomic’ • They must complete without conflict or die and restart • Must not alter global state until complete • Needs system support – software or hardware

  20. Object Based Transactional Memory Hardware • Based on ‘object-aware’ caches • Exploits object structure to simplify transactional memory operations • Advantages over other hardware TM proposals • Handles cache overflow elegantly • Enables multiple memory banks with distributed commit

  21. TM & Cache Coherence • Fine grain cache coherence is the major impediment to extensible multi-cores • Updates to shared memory only occur when a transaction commits • Caches only need to be updated at commit points (which tend to be coarser grain) • If all shared memory is made transactional, the requirement for fine grain coherence is removed

  22. TM Programming • TM constructs can be added to conventional programming languages • But, they require careful use to ensure correctness • If transactional & non-transactional operations are allowed on the same data, the result can become complex to understand.

  23. New Programming Models? • Problems can often be simplified by restricting (unnecessary) programming facilities e.g. • Arbitrary control transfer • Pointer arithmetic • Explicit memory reclamation • A new approach is needed to simplify parallel programming & hardware

  24. We Need Useable & Efficient Models • Shared memory is essential for general purpose programming • Message passing (alone) (e.g. MPI, Occam etc.) is not sufficient • We need shared updateable state – e.g. pure functional programming is not the answer • The languages need to be simple and easily implementable

  25. A Synthesis? • Functional Programming has something to offer – don’t use state unnecessarily • But don’t be too ‘religious’ – local, single threaded state is simple & efficient • Can all global shared state be handled transactionally?

  26. Experiments • Using the language Scala – has both functional and imperative features • Experimenting with applications • Studying how techniques similar to ‘escape analysis’ can identify shared mutable state • Looking at hardware implications, particularly memory architecture

More Related