Actions

D-­TEC: Difference between revisions

From Modelado Foundation

imported>Cdenny
(Created page with "{{Infobox project | title = D-TEC | image = 180px | imagecaption = | team-members = List of team members | pi = Lead PI (Institute) | co-pi = Co-P...")
 
imported>Cdenny
No edit summary
Line 4: Line 4:
| imagecaption =  
| imagecaption =  
| team-members = List of team members
| team-members = List of team members
| pi = Lead PI (Institute)
| pi = Daniel J. Quinlan (LLNL)
| co-pi = Co-PIs (Institute)
| co-pi = Saman Amarasinghe (MIT), Armando Solar‐Lezama (MIT), Adam Chlipala (MIT), Srinivas Devadas (MIT), Una‐May O’Reilly (MIT), Nir Shavit (MIT), Youssef Marzouk (MIT), John Mellor‐Crummey (Rice U.), Vivek Sarkar (Rice U.), Vijay Saraswat (IBM), David Grove (IBM), P. Sadayappan (OSU), Atanas Rountev (OSU), Ras Bodik (UC Berkeley), Craig Rasmussen (U. of Oregon), Phil Colella (LBNL), Scott Baden (UC San Diego)
| website = team website
| website = team website
}}
}}


''Description about your project goes here.....''
'''DSL Technology for Exascale Computing or D-TEC'''
 
'''Domain Specific Languages (DSLs)''' are a tranformational technology that capture expert knowledge about applica@on domains. For the domain scientist, the DSL provides a view of the high‐level programming model. The DSL compiler captures expert knowledge about  how to map high‐level abstractions to different architectures. The DSL compiler’s analysis and transformations are complemented by the general compiler analysis and transformations shared by general purpose languages.
 
* There are different types of DSLs:
** Embedded DSLs: Have custom compiler support for high level abstractions defined in a host language (abstractions defined via a library, for example)
** General DSLs (syntax extended): Have their own syntax and grammar; can be full languages, but defined to address a narrowly defined domain
 
* DSL design is a responsibility shared between application domain and algorithm scientists
 
* Extraction of abstractions requires significant application and algorithm expertise
 
* We have an application team to:
** provide expertise that will ground our DSL research
** ensure its relevance to DOE and enable impact by the end of three years
 


== Team Members ==
== Team Members ==
* Lawrence Livermore National Laboratory (LLNL)
* Massachusetts Institute of Technology (MIT)
* Rice University
* IBM
* [http://www.osu.edu/ Ohio State University (OSU)]
* University of California, Berkeley
* University of Oregon
* Lawrence Berkeley National Laboratory
* University of California, San Diego
== Goals and Objectives ==
'''D‐TEC Goal: Making DSLs Effective for Exascale'''
* We address all parts of the Exascale Stack:
** '''Languages (DSLs):''' define and build several DSLs economically
** '''Compilers:''' define and demonstrate the analysis and optimizations required to build DSLs
** '''Parameterized Abstract Machine:''' define how the hardware is evaluated to provide inputs to the compiler and runtime
** '''Runtime System:''' define a runtime system and resource management support for DSLs
** '''Tools:''' design and use tools to communicate to specific levels of abstraction in the DSLs


* We will provide effective performance by addressing exascale challenges:
** '''Scalability:''' deeply integrated with state‐of‐art X10 scaling framework
** '''Programmability:''' build DSLs around high levels of abstraction for specific domains
** '''Performance Portability:''' DSL compilers give greater flexibility to the code generation for diverse architectures
** '''Resilience:''' define compiler and runtime technology to make code resilient
** '''Energy Efficiency:''' machine learning and autotuning will drive energy efficiency
** '''Correctness:''' formal methods technologies required to verify DSL transformations
** '''Heterogeneity:''' demonstrate how to automatically generate lower level multi‐ISA code


== Objectives ==
* Our approach includes interoperability and a migration strategy:
** '''Interoperability with MPI + X:''' demonstrate embedding of DSLs into MPI + X applications
** '''Migration for Existing Code:''' demonstrate source‐to-source technology to migrate existing code




== Roadmap ==
== The D‐TEC approach addresses the full Exascale workflow ==
[[File:DTEC-workflow.png|600px]]
 
* Discovery of domain specific abstractions from proxy‐apps by application and algorithm experts
 
* (C1 & C2) Defining Domain Specific Languages (DSLs)
** The role of the DSL is to encapsulate expert knowledge
*** About the problem domain
*** The DSL compiler encapsulates how to optimize code for that domain on new architectures
** Rosebud used to define DSLs ''(a novel framework for joint optimization of mixed DSLs)''
*** DSL specification is used to generate a "DSL plug‐in” for Rosebud's DSL compiler
*** Supports both embedded and general DSLs and multiple DSLs in one host‐language source file
*** DSL optimization is done via cost‐based search over the space of possible rewritings
*** Costs are domain‐specific, based on shared abstract machine model + ROSE analysis results
*** Cross‐DSL optimization occurs naturally via search of combined rewriting space
** Sketching used to define DSLs ''(cutting‐edge aspect of our proposal)''
*** Series of manual refinements steps (code rewrites) define the transformations
*** Equivalence checking between steps to verify correctness
*** The series of transformations define the DSL compiler using ROSE
*** Machine learning is used to drive optimizations
** Both approaches will leverage the common ROSE infrastructure
** Both approaches will leverage the SEEC enhanced X10 runtime system
 
* (C3) DSL Compiler
** Leverages ROSE compiler throughout
 
* (C4) Parameterized Abstract Machine
** Extraction of machine characteristics


* (C5) Runtime System
** Leverages X10 and extends it with SEEC support


== Impact ==
* (C6) Tools
** We will define source-­to‐source migration tools
** We will define the mappings between DSL layers to support future tools




== Software Stack ==
== Software Stack ==
=== Rosebud ===
'''Rosebud Overview'''
* Unified framework for DSL implementation
** all aspects: parsing, analysis, optimization, code generation
** all types: embedded, custom‐syntax, standalone
* Modular development and use of DSLs
** textual DSL description => plug­‐in to ROSE DSL Compiler
** plug‐ins developed separately from ROSE and each other
* Knowledge‐based optimization of DSL programs
** plug‐in encapsulates expert optimization knowledge
** ROSE supplies conventional compiler optimizations
* Flexible code generation
** DSL lowered to any ROSE host language
** DSL compiled directly to (portable) machine code via LLVM
'''Rosebud Implementation'''
* DSL front end
** SGLR parser + predefined host‐language grammars
** attribute grammar + ROSE extensible AST and analysis
* DSL optimizer
** declarative rewriting system + procedural hooks to ROSE
** cost‐based heuristic search of implementation space
** domain‐specific costs based on abstract machine model
** cross‐DSL optimization arises naturally from joint search space
* DSL code generator
** ROSE host language unparsers
** ROSE AST => LLVM SSA code
'''Rosebud Plug-ins'''
[[File:DTEC-Rosebud-Plug-ins.png|600px]]
* Plug‐ins developed separately from ROSE and each other
* Plug‐ins distributed in source or object form
* Selected plug‐ins supplied to Rosebud DSL Compiler to compile mixed DSLs in a host language source file
'''Rosebud DSL Compiler'''
[[File:DTEC-Rosebud-DSL-Compiler.png]]
[[File:DTEC-Rosebud-Parsing.png|right]]
'''Two­‐phase parsing for DSL language support'''
* Host language + multiple DSLs in the same source file
** expressive custom notations
** familiar general-purpose language
* Phase 1: extract and parse DSLs
** via Stratego SDF parsing system
* Phase 2: parse host language
** via existing ROSE front ends
* Merge DSL tree fragments into host language AST
** DSL plug-ins provide custom tree nodes and semantic analysis
=== LOPe Programming Model ===
'''LOPe programming model is easily expressed in Fortran because of syntax for arrays'''
* Halo attribute added to arrays
** HALO(1:*:1, 1:*:1)
** specifies one border cell on each side of a two‐dimensional array
** * implies "stuff" in the middle
[[File:DTEC-Halo-1.png|100px]]
[[File:DTEC-Halo-2.png|right]]
* Halos are logical cells not necessarily physically part of the array
* Halos can be communicated with coarrays
** DIMENSION(:,:)[:,:]
** halo region in pink
** logically extends to neighbor processors
** exchange_halo(Array)
'''LOPe programming model is easily expressed in Fortran because of syntax for concurrency'''
* Concurrent attribute added to procedures
** restricted semantics for array element access to avoid race conditions
** copy halo in, write single element out (visible after all threads exit)
[[File:DTEC-Code-2.png]]
* Called from within a '''DO CONCURRENT''' loop
[[File:DTEC-Code-2.png]]
== Roadmap ==

Revision as of 22:19, February 7, 2013

D-TEC
File:Your-team-logo.png
Team Members List of team members
PI Daniel J. Quinlan (LLNL)
Co-PIs Saman Amarasinghe (MIT), Armando Solar‐Lezama (MIT), Adam Chlipala (MIT), Srinivas Devadas (MIT), Una‐May O’Reilly (MIT), Nir Shavit (MIT), Youssef Marzouk (MIT), John Mellor‐Crummey (Rice U.), Vivek Sarkar (Rice U.), Vijay Saraswat (IBM), David Grove (IBM), P. Sadayappan (OSU), Atanas Rountev (OSU), Ras Bodik (UC Berkeley), Craig Rasmussen (U. of Oregon), Phil Colella (LBNL), Scott Baden (UC San Diego)
Website team website
Download {{{download}}}

DSL Technology for Exascale Computing or D-TEC

Domain Specific Languages (DSLs) are a tranformational technology that capture expert knowledge about applica@on domains. For the domain scientist, the DSL provides a view of the high‐level programming model. The DSL compiler captures expert knowledge about how to map high‐level abstractions to different architectures. The DSL compiler’s analysis and transformations are complemented by the general compiler analysis and transformations shared by general purpose languages.

  • There are different types of DSLs:
    • Embedded DSLs: Have custom compiler support for high level abstractions defined in a host language (abstractions defined via a library, for example)
    • General DSLs (syntax extended): Have their own syntax and grammar; can be full languages, but defined to address a narrowly defined domain
  • DSL design is a responsibility shared between application domain and algorithm scientists
  • Extraction of abstractions requires significant application and algorithm expertise
  • We have an application team to:
    • provide expertise that will ground our DSL research
    • ensure its relevance to DOE and enable impact by the end of three years


Team Members

  • Lawrence Livermore National Laboratory (LLNL)
  • Massachusetts Institute of Technology (MIT)
  • Rice University
  • IBM
  • Ohio State University (OSU)
  • University of California, Berkeley
  • University of Oregon
  • Lawrence Berkeley National Laboratory
  • University of California, San Diego


Goals and Objectives

D‐TEC Goal: Making DSLs Effective for Exascale

  • We address all parts of the Exascale Stack:
    • Languages (DSLs): define and build several DSLs economically
    • Compilers: define and demonstrate the analysis and optimizations required to build DSLs
    • Parameterized Abstract Machine: define how the hardware is evaluated to provide inputs to the compiler and runtime
    • Runtime System: define a runtime system and resource management support for DSLs
    • Tools: design and use tools to communicate to specific levels of abstraction in the DSLs
  • We will provide effective performance by addressing exascale challenges:
    • Scalability: deeply integrated with state‐of‐art X10 scaling framework
    • Programmability: build DSLs around high levels of abstraction for specific domains
    • Performance Portability: DSL compilers give greater flexibility to the code generation for diverse architectures
    • Resilience: define compiler and runtime technology to make code resilient
    • Energy Efficiency: machine learning and autotuning will drive energy efficiency
    • Correctness: formal methods technologies required to verify DSL transformations
    • Heterogeneity: demonstrate how to automatically generate lower level multi‐ISA code
  • Our approach includes interoperability and a migration strategy:
    • Interoperability with MPI + X: demonstrate embedding of DSLs into MPI + X applications
    • Migration for Existing Code: demonstrate source‐to-source technology to migrate existing code


The D‐TEC approach addresses the full Exascale workflow

DTEC-workflow.png

  • Discovery of domain specific abstractions from proxy‐apps by application and algorithm experts
  • (C1 & C2) Defining Domain Specific Languages (DSLs)
    • The role of the DSL is to encapsulate expert knowledge
      • About the problem domain
      • The DSL compiler encapsulates how to optimize code for that domain on new architectures
    • Rosebud used to define DSLs (a novel framework for joint optimization of mixed DSLs)
      • DSL specification is used to generate a "DSL plug‐in” for Rosebud's DSL compiler
      • Supports both embedded and general DSLs and multiple DSLs in one host‐language source file
      • DSL optimization is done via cost‐based search over the space of possible rewritings
      • Costs are domain‐specific, based on shared abstract machine model + ROSE analysis results
      • Cross‐DSL optimization occurs naturally via search of combined rewriting space
    • Sketching used to define DSLs (cutting‐edge aspect of our proposal)
      • Series of manual refinements steps (code rewrites) define the transformations
      • Equivalence checking between steps to verify correctness
      • The series of transformations define the DSL compiler using ROSE
      • Machine learning is used to drive optimizations
    • Both approaches will leverage the common ROSE infrastructure
    • Both approaches will leverage the SEEC enhanced X10 runtime system
  • (C3) DSL Compiler
    • Leverages ROSE compiler throughout
  • (C4) Parameterized Abstract Machine
    • Extraction of machine characteristics
  • (C5) Runtime System
    • Leverages X10 and extends it with SEEC support
  • (C6) Tools
    • We will define source-­to‐source migration tools
    • We will define the mappings between DSL layers to support future tools


Software Stack

Rosebud

Rosebud Overview

  • Unified framework for DSL implementation
    • all aspects: parsing, analysis, optimization, code generation
    • all types: embedded, custom‐syntax, standalone
  • Modular development and use of DSLs
    • textual DSL description => plug­‐in to ROSE DSL Compiler
    • plug‐ins developed separately from ROSE and each other
  • Knowledge‐based optimization of DSL programs
    • plug‐in encapsulates expert optimization knowledge
    • ROSE supplies conventional compiler optimizations
  • Flexible code generation
    • DSL lowered to any ROSE host language
    • DSL compiled directly to (portable) machine code via LLVM

Rosebud Implementation

  • DSL front end
    • SGLR parser + predefined host‐language grammars
    • attribute grammar + ROSE extensible AST and analysis
  • DSL optimizer
    • declarative rewriting system + procedural hooks to ROSE
    • cost‐based heuristic search of implementation space
    • domain‐specific costs based on abstract machine model
    • cross‐DSL optimization arises naturally from joint search space
  • DSL code generator
    • ROSE host language unparsers
    • ROSE AST => LLVM SSA code

Rosebud Plug-ins

DTEC-Rosebud-Plug-ins.png

  • Plug‐ins developed separately from ROSE and each other
  • Plug‐ins distributed in source or object form
  • Selected plug‐ins supplied to Rosebud DSL Compiler to compile mixed DSLs in a host language source file

Rosebud DSL Compiler

DTEC-Rosebud-DSL-Compiler.png

DTEC-Rosebud-Parsing.png

Two­‐phase parsing for DSL language support

  • Host language + multiple DSLs in the same source file
    • expressive custom notations
    • familiar general-purpose language
  • Phase 1: extract and parse DSLs
    • via Stratego SDF parsing system
  • Phase 2: parse host language
    • via existing ROSE front ends
  • Merge DSL tree fragments into host language AST
    • DSL plug-ins provide custom tree nodes and semantic analysis


LOPe Programming Model

LOPe programming model is easily expressed in Fortran because of syntax for arrays

  • Halo attribute added to arrays
    • HALO(1:*:1, 1:*:1)
    • specifies one border cell on each side of a two‐dimensional array
    • * implies "stuff" in the middle

DTEC-Halo-1.png

DTEC-Halo-2.png
  • Halos are logical cells not necessarily physically part of the array
  • Halos can be communicated with coarrays
    • DIMENSION(:,:)[:,:]
    • halo region in pink
    • logically extends to neighbor processors
    • exchange_halo(Array)


LOPe programming model is easily expressed in Fortran because of syntax for concurrency

  • Concurrent attribute added to procedures
    • restricted semantics for array element access to avoid race conditions
    • copy halo in, write single element out (visible after all threads exit)

DTEC-Code-2.png

  • Called from within a DO CONCURRENT loop

DTEC-Code-2.png

Roadmap