Actions

Compilers: Difference between revisions

From Modelado Foundation

imported>BenoitMeister
No edit summary
imported>Schulzm
No edit summary
Line 32: Line 32:
|(CORVETTE)
|(CORVETTE)
|SLEEC
|SLEEC
|PIPER does not have/need its own compiler, but we need access to compiler generated information that captures high-level semantics of the language implemented (basically a form of DWARF for DSLs). Additionally, advanced instrumentation or instrumentation point/markers could be useful.
|PIPER does not have/need its own compiler, but we need access to compiler generated information that captures high-level semantics of the language implemented (basically a form of DWARF for DSLs). Additionally, advanced instrumentation or instrumentation point/markers could be useful. Information provided by different DSLs should be interoperable, ideally standardized and compatible with existing debug information provided by existing compilers
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|'Program analysis can be both challenging and require specialized expertise.  What requirements do you have for program analysis and what level of expertise you expect to require?  This problem could be posed in terms of what APIs for program analysis results do you expect?
|'Program analysis can be both challenging and require specialized expertise.  What requirements do you have for program analysis and what level of expertise you expect to require?  This problem could be posed in terms of what APIs for program analysis results do you expect?
Line 49: Line 49:
|(CORVETTE)
|(CORVETTE)
|N/A
|N/A
|N/A
|PIPER mainly focuses on runtime performance analysis. This could benefit greatly from access to static information (loop structures, static call trees, data structures, ...), which should be provided by compilers in a standardized manner (through APIs or debug information encoded into binaries)
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|''What types of hardware do you expect to address/target within optimizations and at what level of granularity of the program (e.g. coarse-grain, over multiple functions, or fine-grain within statements)?''
|''What types of hardware do you expect to address/target within optimizations and at what level of granularity of the program (e.g. coarse-grain, over multiple functions, or fine-grain within statements)?''
Line 78: Line 78:
|(CORVETTE)
|(CORVETTE)
|N/A
|N/A
|PIPER components will be written in C/C++ plus scripting languages (mostly python)
|PIPER components will be written in C/C++ plus scripting languages (mostly python). All components/tools will be applicable to a wide range of source languages or even binaries. The exact list of supported languages is tbd. and will depend on demand and progress on the overall exascale software stack.
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|'''Do you expect to use, require, or develop an Embedded DSL (defined by compiler support that would leverage semantics of abstractions defined completely within a general purpose base language) or an Extended DSL (define by compiler support that would leverage semantics of abstractions defined by new syntax)?"
|'''Do you expect to use, require, or develop an Embedded DSL (defined by compiler support that would leverage semantics of abstractions defined completely within a general purpose base language) or an Extended DSL (define by compiler support that would leverage semantics of abstractions defined by new syntax)?"
Line 94: Line 94:
|(CORVETTE)
|(CORVETTE)
|N/A
|N/A
|N/A
|Possibly as interface to query and analyze performance data, but unclear as of now
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|''' What generic and customized code transformations do you require to support your project?"
|''' What generic and customized code transformations do you require to support your project?"
Line 123: Line 123:
|(CORVETTE)
|(CORVETTE)
|N/A
|N/A
|N/A
|Mostly does not apply to PIPER, but some elements of autotuning could use code transformation, e.g., to create multiple variants of the same code
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|'''Which parallel programming models (MPI, OpenMP, UPC, etc.) do you want to have better compiler support? "
|'''Which parallel programming models (MPI, OpenMP, UPC, etc.) do you want to have better compiler support? "

Revision as of 03:01, May 7, 2014

Sonia requested that Dan Quinlan initiate this page. For comments, please contact Dan Quinlan. This page is still in development.

QUESTIONS XPRESS TG X-Stack DEGAS D-TEC DynAX X-TUNE GVR CORVETTE SLEEC PIPER
PI Ron Brightwell Shekhar Borkar Katherine Yelick Daniel Quinlan Guang Gao Mary Hall Andrew Chien Koushik Sen Milind Kulkarni Martin Schulz
Describe how you expect to require compiler support within your X-Stack project. (EXPRESS) (TG) (DEGAS) (D-TEC)

Compilers have two purposes in the DynAX project, which are both about increasing productivity and programmability.

1- The first role is to automatically parallelize domain-specific applications from a sequential specification. This is what R-Stream does, as it takes sequential C and produce parallel, scalable SWARM code.

2- The second role is to expose high-level parallel programming abstractions. This goal is addressed at two levels: The HTA compiler, which relies on an explicitly parallel intermediate representation (PIL), generates SCALE code. The SCALE compiler, in turn, offers object-oriented programming and simplifies programming to SWARM.

(X-TUNE) (GVR) (CORVETTE) SLEEC PIPER does not have/need its own compiler, but we need access to compiler generated information that captures high-level semantics of the language implemented (basically a form of DWARF for DSLs). Additionally, advanced instrumentation or instrumentation point/markers could be useful. Information provided by different DSLs should be interoperable, ideally standardized and compatible with existing debug information provided by existing compilers
'Program analysis can be both challenging and require specialized expertise. What requirements do you have for program analysis and what level of expertise you expect to require? This problem could be posed in terms of what APIs for program analysis results do you expect? (EXPRESS) (TG) (DEGAS) (D-TEC)

The PIL and SCALE compilers support parallel languages as their input (PIL supports Hierarchically Tiled Arrays for data-parallel programs, and SCALE accepts structured, object-oriented codelet programs).

The R-Stream compiler supports sequential C loops to which a set of writing rules (a "style") are applied by the programmer. The rules, which entail exposing enough static information to the compiler, are defined in the R-Stream user guide. Some pragmas are defined that allow the user to provide additional hints to the compiler. R-Stream relies on extensions of the polyhedral model to represent, analyze and transform programs.

(X-TUNE) (GVR) (CORVETTE) N/A PIPER mainly focuses on runtime performance analysis. This could benefit greatly from access to static information (loop structures, static call trees, data structures, ...), which should be provided by compilers in a standardized manner (through APIs or debug information encoded into binaries)
What types of hardware do you expect to address/target within optimizations and at what level of granularity of the program (e.g. coarse-grain, over multiple functions, or fine-grain within statements)? (EXPRESS) (TG) (DEGAS) (D-TEC)

We currently target clusters of x86 multicore nodes for our experiments, but we are considering other targets as well, such as Intel's straw man architecture. So far we have worked at function-level granularity, but optimizing across multiple functions is possible to some degree.

(X-TUNE) (GVR) (CORVETTE) N/A all of the above
What general purpose languages do you expect to use and or extend to support your research work?" (EXPRESS) (TG) (DEGAS) (D-TEC)

Both R-Stream and SWARM are based on C as their input language.

(X-TUNE) (GVR) (CORVETTE) N/A PIPER components will be written in C/C++ plus scripting languages (mostly python). All components/tools will be applicable to a wide range of source languages or even binaries. The exact list of supported languages is tbd. and will depend on demand and progress on the overall exascale software stack.
Do you expect to use, require, or develop an Embedded DSL (defined by compiler support that would leverage semantics of abstractions defined completely within a general purpose base language) or an Extended DSL (define by compiler support that would leverage semantics of abstractions defined by new syntax)?" (EXPRESS) (TG) (DEGAS) (D-TEC)

The R-Stream approach to domain-specificity is to define a programming style and enable domain-specific annotations. The advantage of this approach is that the user still programs in C, and doesn't need to learn a new syntax.

We have developed SCALE as a general-purpose programming language within the domain of HPC. We have not conceived of any of the current SCALE features as being specific to a narrower domain than that.

(X-TUNE) (GVR) (CORVETTE) N/A Possibly as interface to query and analyze performance data, but unclear as of now
What generic and customized code transformations do you require to support your project?" (EXPRESS) (TG) (DEGAS) (D-TEC)

R-Stream supports a wide range of loop and data layout transformations, some of which are specific to stencil operations. These transformations mainly create data locality and parallelism at various levels of the target architecture.

(X-TUNE) (GVR) (CORVETTE) N/A Instrumentation
Which level of Intermediate Representation do you prefer to work with: source level, normalized middle level, or low level (close to binary code)? " (EXPRESS) (TG) (DEGAS) (D-TEC)

We do not have a preference, but in our experience, users want to program at the highest possible level, while still being able to access low-level code and understand the parallelization process. Our source-to-source tools enable this.

(X-TUNE) (GVR) (CORVETTE) N/A Mostly does not apply to PIPER, but some elements of autotuning could use code transformation, e.g., to create multiple variants of the same code
Which parallel programming models (MPI, OpenMP, UPC, etc.) do you want to have better compiler support? " (EXPRESS) (TG) (DEGAS) (D-TEC)

None, although I'm not sure I fully understand the question (as of 5/5/14).

(X-TUNE) (GVR) (CORVETTE) N/A N/A
What OS configuration and hardware platforms do you want to run the compiler? " (EXPRESS) (TG) (DEGAS) (D-TEC)

PIL, R-Stream, SCALE and SWARM support Linux (complete list of tested distributions available).

Successful Mac OS uses of R-Stream were also reported (using Darwin), although it is not officially supported. R-Stream can also cross-compile to any platform as long as the native low-level compiler supports this feature.

For SCALE and SWARM, cross-compilation is done for Xeon Phi.

(X-TUNE) (GVR) (CORVETTE) N/A N/A
How do you expect compilers to incorporate domain-specific information, through DSL, separated semantics-specification files, or other methods? " (EXPRESS) (TG) (DEGAS) (D-TEC)

As explained above, in R-Stream, a domain-specific formulation of the program is performed by combining style rules and annotations (#pragma). Semantics and syntax remain as well-defined as the underlying C language.

PIL is a framework to facilitate any-to-any compilation of parallel languages. There is no domain specific information, but will work for any language.


(X-TUNE) (GVR) (CORVETTE) N/A N/A
How do you expect compilers to interact with your libraries or runtime systems, if any ? " (EXPRESS) (TG) (DEGAS) (D-TEC)

R-Stream generates codes that includes calls to the target machine's runtimes/libraries for the purpose of parallelization and locality optimization. R-Stream also supports library calls within the input code.

(X-TUNE) (GVR) (CORVETTE) N/A Yes: by providing additional debug/code to abstraction mapping information