NUMA Computing with Hardware and Software Co-Support on Configurable Emulated Shared Memory Architectures

Abstract

The emulated shared memory (ESM) architectures are good candidates for future general purpose parallel computers due to their ability to provide an easy-to-use explicitly parallel synchronous model of computation to programmers as well as avoid most performance bottlenecks present in current multicore architectures. In order to achieve full performance the applications must, however, have enough thread-level parallelism (TLP). To solve this problem, in our earlier work we have introduced a class of configurable emulated shared memory (CESM) machines that provides a special non-uniform memory access (NUMA) mode for situations where TLP is limited or for direct compatibility for legacy code sequential computing and NUMA mechanism. Unfortunately the earlier proposed CESM architecture does not integrate the different modes of the architecture well together e.g. by leaving the memories for different modes isolated and therefore the programming interface is non-integrated. In this paper we propose a number of hardware and software techniques to support NUMA computing in CESM architectures in a seamless way. The hardware techniques include three different NUMA shared memory access mechanisms and the software ones provide a mechanism to integrate and optimize NUMA computation into the standard parallel random access machine (PRAM) operation of the CESM. NUMA Computing with Hardware and Software Co-SupportThe hardware techniques are evaluated on our REPLICA CESM architecture and compared to an ideal CESM machine making use of the proposed software techniques.

Global Optimization of Execution Mode Selection for the Reconfigurable PRAM-NUMA Multicore Architecture REPLICA

“…Compared to commercial CPUs and GPUs, PRAM mode is very fast for algorithms with irregular memory accesses and control flow [5], but in some cases it is slower when it comes to regular memory accesses and control flow. We have also in earlier work [4] introduced REPLICAs NUMA mode and given some evaluation on microbenchmarks; we also showed that latency and locality optimizations can give a performance gain in NUMA mode. We here consider a computation that has both a PRAM and a NUMA implementation as a component with two variants.…”

“…The REPLICA architecture is a family of chip multiprocessors (CMP); it is a configurable emulated shared memory (CESM) machine where different configurations have different number of cores, ALUs and memory units (MUs) [4], however in this paper we focus on the configuration given in Table I. The REPLICA architecture is a Very Long Instruction Word (VLIW) architecture, though compared to standard VLIW architectures REPLICA has support for chained functional units (FUs) [7].…”

“…NUMA mode can be seen as an in-place accelerator mode to support sequential legacy programs and programs with low thread level parallelism [4]. From the architectural point of view the pipeline in NUMA mode looks like a standard VLIW pipeline, not allowing any chaining between the FUs; also the number of FUs is fixed even though there can be more in PRAM mode.…”

“…We have encapsulated the JOIN and SPLIT instructions into a special NUMA language construct which also orchestrates stack handling etc. [4]. Switching to NUMA mode takes around 11000 clock cycles and switching back takes around 5000.…”

“…PRAM mode is highly multithreaded and can be considered the "standard" mode while NUMA mode can be considered an accelerator for particular tasks (reusing the same silicon infrastructures). NUMA mode was mainly designed for running programs with low thread-levelparallelism faster, and to support sequential legacy programs [4]. In earlier work we have done an empirical study of REPLICAs PRAM mode compared to other architectures, both academic research prototypes and commercial available state-of-the-art CPUs and GPUs [5].…”