declarative programming languages for multicore architecures workshop 15 january 2006

Declarative Programming Languages

for Multicore Architecures

Workshop

15 January 2006

Declarative Programming Languages for Multicore Architectures

Welcome…

…to the first workshop on Declarative Programming Languages for Multicore Architectures!

Multicores are coming

• We need to program them

• Correctly!

• Implicit parallelism is promising

• But can it be made effective


Logistics

Workshop, breakfast, and breaks here in Cypress

Lunch in suite J2 – buffet style

Informal style– Ask questions– Discuss– Mixture of retrospective, work in progress, and speculation

on the future

Name tags at the back if you don’t have one

No wireless


Programme

8:40 Keynote: The Evolution of Computing Architectures

1:00 Panel

9:40 Break 2:00 Break

9:55 pH: Lessons Learned 2:20 Now you C it. Now you Don’t.

10:20 Nesl 2:45 Hume and Multicore Architectures

10:45 Break 3:10 Automatic Parallelization and Granularity Control of Logic and Constraint Programs

11:00 The Next Generation of Logic Languages

3:35 Break

11:25 A Look Back and Forward at Parallel Logic Programming

3:55 Design and Implementation Issues for Atomicity

11:50 Lunch 4:20 Stabilizers

4:45 Nested Data Parallelism in Haskell

5:10 Wrap Up


Panel:Lessons from the Past andWhat it Means for Multicores

Questions to ponder:

• What worked and what did not work in the research of the 80s and 90s?

• What are the remaining hard problems from previous research?

• Which hard problems are relevant to multicores, and which are mitigated?

• What does the experience of 80s and 90s suggest for multicore design/architecture?


Thanks

To all of you for attending

To all the presenters

To Anwar Ghuloum, Leaf Petersen, and Jesse Fang for helping me to organise the workshop

To Intel’s PSL for sponsoring the workshop

To Margarida Strickland for administrative support


Keynote

The Evolution of Computing Architectures

Douglas Carmean

Senior Principal Architect

Intel Corporation


Panel:Lessons from the Past andWhat it Means for Multicores

•What worked and what did not work in the research of the 80s and 90s?

•What are the remaining hard problems from previous research?

•Which hard problems are relevant to multicores, and which are mitigated?

•What does the experience of 80s and 90s suggest for multicore design/architecture?


Summary

Hardware

Implicit parallelism

Language design

Key problems

Cross fertilisation

Hardware ideas

Intel

Next steps


Hardware Summary

Three types of parallelism:

• Vector units – floating point, but integer too

• SMT – multiple register sets in single core

• SMP – multiple cores on chip


Implicit Parallelism Summary

Over promised, under delivered

Easy to generate lots of parallelism

• Problem is to schedule

• Cactus stacks, thunks worked well

Sequential (deterministic) semantics is important

• Easier to debug

Cost models are important

Communication was a problem

• Not with multicores


Language Design Thoughts

Don’t commit to specific hardware

Don’t base the language on the implementation

Exact reduction operations are important (see Nesl)

Domain specific languages

• Bad idea, use libraries instead

Atomic great for when you have effects


More Language Design Thoughts

Control of effects is very beneficial

• Fewer writes

• TM logs

Three layers of language:

• Explicit – transactional memory, atomicity

• Implicit – declarative and sequential

• Data parallelism – especially vector


Controversy

Are annotations needed?

• No

• Minimal (and vs or parallelism)

• Strategies

• Manuel’s ideas

Message Passing – good or bad?

• MPI bad

• Perhaps a good programming abstraction exists for certain applications

Cost models


Key Problems

Memory management

• Concurrent GC is an important problem

Data locality

• How to place data

• Shared vs non-shared memory

• Memory Models

Cost Models

Debugging

Put the models together

Thread packages and good low-level libraries


Cross Fertilisation

Or-parallelism for search

• What is the equivalent in FP?

Nesl good at Vector, SMT, and SMP

• Can LP do this too?

What are the similarities between the communities and can they exchange results?


Hardware Ideas - General

General purpose mechanisms, language specific bad

Memory bandwidth is fundamental issue

• Latency solved?

Dataflow?

Programmable hardware?


Hardware Ideas - Specific

Hardware support for Transactional Memory

Read and/or write barriers for GC, TM, I-structs

Fast context switching, lightweight spawn & sched

No glass-jaws in synchronisation instructions

Non-shared memory

NUMA caches

Allocate in cache


Intel

Feel free to talk to us:

• Anwar, David, Leaf, Neal, and Rob

PSL is working on:

• McRT – threading, scheduling, and synchronisation

• Pillar – target language (a la C--) for parallel languages

Intel Research:

• Jekyll, Autolocker, Lockbend, …


This Workshop Follow On

Feel free to give me feedback at:

• [email protected]

A website will be constructed if presenters are willing to give me their slides

• I’ll send a message when ready


The Future

• A once off?

• Repeat again next year and then see?– Open?– Associated with what? Or by itself?

• Something else?

• Follow on for the hardware ideas?

declarative programming languages for multicore architecures workshop 15 january 2006

Documents

multicore architectures

multicore architectures

multicore designarchitecture

vector slide

effects slide

chip slide

wireless slide

effective slide