extreme scale: programming. participants mary hall rob ross christine sweeney ian foster daniel...
TRANSCRIPT
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)