Compilers - Revision history

imported>Milind at 16:35, May 20, 2014

2014-05-20T16:35:53Z

← Older revision		Revision as of 16:35, May 20, 2014
Line 40:		Line 40:
	\|corvetteanswer=		\|corvetteanswer=

	\|sleecanswer=		\|sleecanswer=Compilers are used for two purposes in SLEEC: 1) To translate annotations on libraries into directives understood by SLEEC runtime systems (e.g., translating directives regarding inputs/outputs of kernels into SemCache API calls; 2) To perform high level optimizations of programs written using SLEEC-enabled libraries (e.g., performing linear algebra optimizations on applications written with BLAS).

	\|piperanswer=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		\|piperanswer=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
Line 67:		Line 67:
	\|corvetteanswer=		\|corvetteanswer=

	\|sleecanswer=~~N/A~~		\|sleecanswer=We expect to use analysis results from frameworks like Fuse to build our IR for compiler transformations. We will be working on extending Fuse to perform analysis over "locations" that are matrices, or disjoint sets of memory locations.

	\|piperanswer=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). HPCToolkit - one of PIPER's tools - parses machine code, reconstructs control flow graphs, performs interval analysis to identify loops, and then combines the information about loops with information about inlining from DWARF to attribute performance metrics to optimized code.		\|piperanswer=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). HPCToolkit - one of PIPER's tools - parses machine code, reconstructs control flow graphs, performs interval analysis to identify loops, and then combines the information about loops with information about inlining from DWARF to attribute performance metrics to optimized code.
Line 95:		Line 95:
	\|corvetteanswer=		\|corvetteanswer=

	\|sleecanswer=N/A		\|sleecanswer=In addition to targeting general systems with our compiler transformations, we specifically target heterogeneous hardware (e.g., CPU/GPU nodes) with SemCache, and perform optimizations across method (library) calls.

	\|piperanswer=all of the above		\|piperanswer=all of the above
Line 121:		Line 121:
	\|corvetteanswer=		\|corvetteanswer=

	\|sleecanswer=		\|sleecanswer=C/C++

	\|piperanswer=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.		\|piperanswer=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.
Line 175:		Line 175:
	\|corvetteanswer=		\|corvetteanswer=

	\|sleecanswer=~~N/A~~		\|sleecanswer=We leverage general code motion transformations to expose opportunities for high-level optimization.

	\|piperanswer=Instrumentation		\|piperanswer=Instrumentation
Line 201:		Line 201:
	\|corvetteanswer=		\|corvetteanswer=

	\|sleecanswer=~~N/A~~		\|sleecanswer=Source level (ish). Our IR captures more information (dependences, semantic type information, etc) than is available at source level, but we want to be able to translate back to source.

	\|piperanswer=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		\|piperanswer=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
Line 282:		Line 282:
	\|corvetteanswer=		\|corvetteanswer=

	\|sleecanswer=~~N/A~~		\|sleecanswer=We expect domain specific knowledge to be encoded as annotations on library methods (potentially in a separate specification file).

	\|piperanswer=N/A		\|piperanswer=N/A

imported>Admin at 04:35, May 20, 2014

2014-05-20T04:35:32Z

Show changes

imported>Admin at 04:33, May 20, 2014

2014-05-20T04:33:51Z

Show changes

imported>JohnMC at 23:47, May 13, 2014

2014-05-13T23:47:39Z

← Older revision		Revision as of 23:47, May 13, 2014
Line 60:		Line 60:
	\|(CORVETTE)		\|(CORVETTE)
	\|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)		\|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). HPCToolkit - one of PIPER's tools - parses machine code, reconstructs control flow graphs, performs interval analysis to identify loops, and then combines the information about loops with information about inlining from DWARF to attribute performance metrics to optimized code.
	\|- 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)?'''

imported>Jsstone1 at 03:08, May 12, 2014

2014-05-12T03:08:42Z

Show changes

imported>ChunhuaLiao at 21:56, May 9, 2014

2014-05-09T21:56:22Z

← Older revision		Revision as of 21:56, May 9, 2014
Line 136:		Line 136:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|Within D-TEC, we want to support all levels of intermediate representations to fully support the analysis, optimization and code generation of DSLs.		\|Within D-TEC, we want to support all levels of intermediate representations to fully support the analysis, optimization and code generation of DSLs. For example, a high level representation is best to preserve high level code structures.
			A normalized middle-level representation is most important for many static analyses. A low-level IR is very suitable for machine-specific optimizations.
	\|		\|
	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.		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.

imported>ChunhuaLiao at 18:04, May 9, 2014

2014-05-09T18:04:23Z

← Older revision		Revision as of 18:04, May 9, 2014
Line 68:		Line 68:
	\|We expect that the future extreme-scale computers will be heterogeneous node architectures connected with network connections.		\|We expect that the future extreme-scale computers will be heterogeneous node architectures connected with network connections.
	An example heterogeneous node architecture is a multicore shared memory machine with a NVIDIA GPU accelerator with a separated memory space.		An example heterogeneous node architecture is a multicore shared memory machine with a NVIDIA GPU accelerator with a separated memory space.
			For shared memory, non-uniform memory access (NUMA) will be an expected solution to be scalable.

	We want to exploit coarse-grain parallelism of a program first, then incrementally take advantage of finer-grain parallelism and map them to the		We want to exploit coarse-grain parallelism of a program first, then incrementally take advantage of finer-grain parallelism and map them to the

imported>ChunhuaLiao at 18:03, May 9, 2014

2014-05-09T18:03:06Z

← Older revision		Revision as of 18:03, May 9, 2014
Line 201:		Line 201:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|(D-~~TEC)~~		\|The compiler will generate tasks (kernels) to be executed at runtime. It will also transform and partition data in programs so a NUMA-aware runtime library can be used.
	\|		\|
	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.		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.

imported>ChunhuaLiao at 17:47, May 9, 2014

2014-05-09T17:47:04Z

← Older revision		Revision as of 17:47, May 9, 2014
Line 165:		Line 165:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\|Linux is our main focus OS. Target platforms may use Intel/AMD x86 multicore machines with NVIDIA GPUs.
	\|		\|
	PIL, R-Stream, SCALE and SWARM support Linux (complete list of tested distributions available).		PIL, R-Stream, SCALE and SWARM support Linux (complete list of tested distributions available).
Line 184:		Line 184:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~Linux is our main focus OS. Target platforms may use Intel/AMD x86 multicore machines with NVIDIA GPUs~~.		\|We want to support DSL, annotations, and separated semantics-specification files.
	\|		\|
	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.		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.

imported>ChunhuaLiao at 17:45, May 9, 2014

2014-05-09T17:45:20Z

← Older revision		Revision as of 17:45, May 9, 2014
Line 87:		Line 87:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|(D-~~TEC)~~		\|We are interested in a wide range of generic transformations, such as loop transformations, instrumentation, GPU code generation, and data structure transformation.
			We also want to have a compiler infrastructure which provides easy code transformation APIs so we can add customized, domain-specific transformations.
	\|		\|
	Both R-Stream and SWARM are based on C as their input language.		Both R-Stream and SWARM are based on C as their input language.
Line 101:		Line 102:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\|We want to support all flavours of DSLs.
	\|		\|
	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.		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.
Line 118:		Line 119:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|(D-~~TEC)~~		\|We are interested in a wide range of generic transformations, such as loop transformations, instrumentation, GPU code generation, and data structure transformation.
			We also want to have a compiler infrastructure which provides easy code transformation APIs so we can add customized, domain-specific transformations.
	\|		\|
	R-Stream supports a wide range of loop and data layout transformations, some of which are specific to stencil operations.		R-Stream supports a wide range of loop and data layout transformations, some of which are specific to stencil operations.
Line 133:		Line 135:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|(D-TEC)		\|Within D-TEC, we want to support all levels of intermediate representations to fully support the analysis, optimization and code generation of DSLs.
	\|		\|
	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.		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.
Line 149:		Line 151:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\|We are interested in MPI and OpenMP. Ideally, the compiler should be aware of MPI function calls and have OpenMP implementation.
	\|		\|
	None, although I'm not sure I fully understand the question (as of 5/5/14).		None, although I'm not sure I fully understand the question (as of 5/5/14).
Line 182:		Line 184:
	\|(TG)		\|(TG)
	\|(DEGAS)		\|(DEGAS)
	\|~~(D-TEC)~~		\|Linux is our main focus OS. Target platforms may use Intel/AMD x86 multicore machines with NVIDIA GPUs.
	\|		\|
	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.		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.