Roadmap: contributions

This action is shared by all clusters, aiming to contribute rich and original material to build a HiPEAC roadmap. It stems from the release of the first HiPEAC roadmap, and plans to revise it into a comprehensive and forward-looking document.

Marc Duranton is responsible for the HiPEAC2 roadmap and asks us (as a cluster) to work on the following issues.

First, define the challenges for our domain:

1. What are the main problems/challenges you see in the next 5 years?
2. What are the main problems/challenges you see in the next 5 to 10 years?
3. What are the main problems/challenges you see after the next 10 years?
4. For all of the challenges you enumerate, please give an assessment of:
   • Who is working on it? (person, country, university, industry, ...)
   • What is the state-of-the-art?
   • Try to classify and sort the most promising approaches.
   • Comment on the European activity (strengths/weaknesses, impact) in the area.
   • Comment on HiPEAC's activity in the area.
   • What could be the impact if the challenge is not solved?
   • What could be the impact if the challenge is solved?
5. Do you see other challenges in other domains that could impact (positively or negatively) your domain?
6. Provide extensive references and justifications for the above.

Then, look for a cristal ball and answer the following questions
(these differ from the first series: current and probable evolution could ignore a problem/challenge):

• What do you see as probable key evolutions in your domain in the next 5 years?
• In the next 10 years?
• Beyond 15 years?
• Which is the (sub-)domain you see as most topical for the next 5 years... outside yours?
• In the next 10 years?
• Beyond 15 years?

Here is a draft bullet list to structure such an answer. Besides answering the above questions, we believe it will be more helpful to explain the global context and challenges in terms of forces and impacts on the compilation platforms.

Forces.

• Complex, many-core, heterogeneous architectures.
  Two distinct objectives with distinct influences:
  • Peak performance, at all costs, automatically or semi-automatically (library generators, pragmas/switches for black-belt programmers).
  • Scalability over architectural evolutions, i.e., maintain/restore the performance increase of about 2x every 18 months: a unique opportunity to break Proebsting's law!
• Managed, declarative, productivity-driven, scripting languages, domain-specific knowledge (specialization, rewrite rules, static properties).
  Two distinct objectives with very different technical contents:
  • Reduce performance penalty.
  • Exploit the computational/communication/storage components of the target architecture.
• Dynamic compilation: a popular oxymoron, yet more topical than ever.
  Continuum of compilation contexts, depending on the nature of the functional vs. performance portability problem:
  • JIT compilation, dynamic optimization.
  • Install-time portability layer.

Global impact.

• Single-source, mutiple-ISA compilation (does not require a single run of the compiler, though, see SARC WP3's single-source compilation experiment for the Cell) with compiler-managed selection of the target and aggregation of static and dynamic analysis across ISAs.
• Portable concurrency constructs in the (intermediate) language(s), with the ability to coarsen and/or refine the grain of parallelism, involving actual program transformations (e.g., task fusion, static scheduling, scratch-pad management, latency-sensitive code generation, data and/or code replication, algorithm selection) and not only run-time adaptation from a multiversion program.
• Extreme variety and complexity of targets makes self-constructing compilers a must: learning cost models, heuristics and interactions between passes; predicting or learning predictive models across architectures.
• Multiple semantical levels: make the intermediate languages first class citizens, targetting compiler optimizations as a priority (but below a portability layer), but with considerations for possible manual intervention (for peak performance or external domain-specific optimization and software engineering tools).
• Optimizations for managed and script languages.
• Whole-program optimization across semantical/module barriers.
• Model portable, deterministic (by default) or at least composable forms of concurrency (overused in the transactional memory community, but what is the exact/formal definition? interesting point of interaction with the programming models cluster).
• Embed domain-specific knowledge into the compiler (interact with general-purpose transformations).

Please contribute to this Wiki page!