Domain-Specific Environments
Principal Investigators: Ralph Johnson, Vikram Adve
One way to make parallel programming be "just programming" is to hide the parallelism inside domain-specific languages or libraries. We call a collection of domain-specific tools domain-specific environments (DSEs). Ideally, the goal of many such DSEs is for application programmers (especially those who are already using these environments) to not have to learn parallel programming - using these environments should allow their programs to automatically take advantage of more cores. In practice, however, much can go wrong, and application programmers are often disappointed by the performance of their programs using a DSE that hides parallelism. Unfortunately, the development tools they can use to diagnose and fix these problems usually do not have any knowledge of their domain, which means that the benefit of domain-specific programming is lost; worse still, it can actually be harder to tune a program if performance behavior can be understood only at the level of a base language and low-level run-time instead of the programmer's source code.
There are too many possible domains for us to develop new tools or specialize existing tools for each domain. Instead, we must develop generic techniques and tools that enable domain experts to build effective, rich parallel DSEs. We plan to implement these for the parallelized frameworks being implemented for our applications, as well as help design these frameworks. We expect to discover common themes and recurring problems that will form the basis for these generic techniques.
A true "programming environment" for a domain should include domain-specific development tools such as tools for code optimization (i.e., domain-aware compilers), performance analysis, debugging, refactoring, and interactive development. All of these tools would present information to the programmer in the concepts and terminology of the domain, rather than simply in those of a base language or run-time system. One of the tools that often needs more information about a DSE is the compiler. Compilers miss opportunities to optimize applications that use domain-specific libraries and frameworks (and often even domain-specific languages) because they do not understand the domain. Ideally, the interface of a DSE should not change when it starts to support parallelism. However, there are limits to the performance gains that can be achieved with complete backward compatibility, so often the DSE will introduce new features. We shall study tools and methodologies to help application programmers cope with such interface changes.
