Extreme Scale: Programming

Participants• Mary Hall• Rob Ross• Christine Sweeney• Ian Foster• Daniel Laney• Lavanya Ramakrishnan• Jim Ahrens• John Wright• Craig Tull• Tom Uram• Frank Wuerthwein

• Pinar Alper• Gagan Agrawal• Jim Kowalkowski• Greg Abram• Berk Geveci• Scott Klasky• Manish Parashar• Valerio Pascucci• Michela Taufer• Chris Carothers

Thanks to Manish for taking detailed notes!

Changes in Architectures

• High concurrency• More dynamic– execution of programs (more asynchronous)– behavior of system (e.g., DVFS, failures)

• Diversity of architectures• In-system storage– And no common model for this so far• Lifetime, locality, API, …

“Horizon” and Coordination• Where does the workflow end and programming model

begin?– Hierarchical representation and scheduling

• Might be multiple algorithms that solve the same problem: are those implemented as part of a single code, or as multiple codes

• Need for coordination between workflow and programming model (and runtime)– Coordination between workflow and the scheduler– Coordination with things external to the system

(e.g., other workflow systems, additive manufacturing example)• Need to bring communities together to enable

interoperability.

Mapping• Scientists define model of science (workflow), that is

converted into an execution plan in some way– Capture what scientist wants to do rather than how they want to

do it– Leads to improved portability to different architectures– How is architectural information and scientist’s intent used to pick

a “good” execution plan?• Domain specific language (DSL) paradigm for programming?• User could specify “knobs” (options) that provide additional

degree(s) of freedom (e.g., precision)• Cost models needed to enable decision-making

– Including during execution– E.g., relative cost of data access

Patterns• “Poor man’s workflow” – capturing scripts, etc. that define

a job and allowing for easy re-execution• Coupled codes• Ensembles (many jobs running at the same time)

– People already do this (e.g., using swift), sampling high-dimensional spaces

– Conditionals in the workflow based on results of individual runs– UQ/V&V often a piece of this

• Multi-physics and in situ analysis– Which pieces are done as part of the “workflow”?

• Need to articulate the common workflow patterns to help guide discussion.

Provenance• Capture of runtime decisions, even if it isn’t possible

to reproduce exact execution• Tagging of data based on runtime analysis• More than just what workflow is doing• Even if teams aren’t using other workflow

components, provenance capture is useful

Pragmatics• Accessibility of the workflow description method • Basic programming constructs (conditionals, loops) are needed

as part of the language for describing workflows• Dynamism in the workflow itself, workflow is changed at

runtime (rather than trying to capture all the possible execution paths)– User driven or automated

• How do you get large communities to buy into tools developed under the workflow umbrella (e.g., provenance capture)?

• How do you help teams integrate some tools while not necessarily buying into the whole set of tools/packages?

• In situ analytics will be parallel, must take good advantage of architectural characteristics and coexist with simulation code(s)