Exascale computers require new technologies in both hardware and software because of the increased gap between various memory structures and computational units and the decreased reliability of components due the sheer size of the machine and small scale of the individual components. The Traleika Glacier project is a study on how an exascale computer could look from both the hardware and software sides. From the hardware side, the proposal is to work more with scratchpad memories instead of the more traditional caches, and with a deep memory hierarchy. Scratchpad memories bring more transparency in performance behavior and free hardware designers from complicated consistency protocols between the various memory layers. From the software side, open community runtime (OCR) is proposed as a potentially viable programming model for this new class of machines. OCR is a task-based model that allows for a more dynamic placement of tasks than more traditional programming models. The paper extensively describes the OCR model and its properties. OCR provides a referential transparent framework, allowing dynamic placement and error recovery. OCR is viewed as a low-level layer between the hardware and higher-level programming languages. Another important aspect is built-in resilience to cope with hardware failures that are expected to be more frequent than the current generation of machines.

The authors’ hardware vision is in principle a sound one; others have also proposed similar structures. As always, the problem lies in the software. Layered memory models are not properly abstracted in most programming languages, which are basically one dimensional. If a programming language abstracts, it is usually in a different way, such as with tasks and/or objects and not in physical memory. OCR requires any high-level programming language to generate tasks. In the authors’ view, these tasks are scheduled and placed in memory by the OCR runtime system. To cover up for the latencies in the various system layers, task generation must be as abundant as possible. This approach is also followed in some functional parallel language approaches. So far so good. The real difficulty, in my opinion, will be the efficient integration of OCR with the higher-level parallel programming languages. Cross-language semantics has always been somewhat difficult to deal with, and the devil is usually in the details. The other part is scheduling and placement by the OCR runtime system. Can we make sufficiently clear to the application programmer what the runtime system has done with an application and how it can it be adapted if the application turns out to run inefficiently? Traleika Glacier still has a lot of open ends, which the authors readily admit.