A PRAM-NUMA Model of Computation for Addressing Low-TLP Workloads

Abstract

It is possible to implement the parallel random access machine (PRAM) on a chip multiprocessor (CMP) efficiently with an emulated shared memory (ESM) architecture to gain easy parallel programmability crucial to wider penetration of CMPs to general purpose computing. This implementation relies on exploitation of the slack of parallel applications to hide the latency of the memory system instead of caches, sufficient bisection bandwidth to guarantee high throughput, and hashing to avoid hot spots in intercommunication. Unfortunately this solution can not handle workloads with low thread-level parallelism (TLP) efficiently because then there is not enough parallel slackness available for hiding the latency. In this paper we show that integrating non-uniform memory access (NUMA) support to the PRAM implementation architecture can solve this problem and provide a natural way for migration of the legacy code written for a sequential or multi-core NUMA machine. The obtained PRAM-NUMA hybrid model is defined and architectural implementation of it is outlined on our ECLIPSE ESM CMP framework. A high-level programming language example is given.

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

“…We have also introduced the PRAM-NUMA model of computation capturing the details of this solution in more theoretical way [9]. It consists of T processors grouped as P groups of T p processors, a word-wise accessible global shared memory, P local memory blocks, a metric defining distance between the processor groups and target memory blocks, and distance-aware interconnection network (see Figure 2).…”

“…The original PRAM-NUMA model of computation [9] defines separate networks and memory systems for the different modes of the machine, which is impractical from the point of view of writing unified programs making use of both modes. In order to simplify hardware implementation and programming, we have proposed unifying the modes by embedding the NUMA system into the PRAM system so that there is no need for a dedicated NUMA network while dedicated NUMA memories are retained as local memory modules [10].…”

“…Earlier versions of our REPLICA compiler only supported to generate code for PRAM mode [19,15]. For the previous architectures, [8,11], the so called e-compiler was developed and used [6,4]. To a large extent it can be used for the current REPLICA architecture as well, and we use it for some of the evaluation benchmarks in Section 5, since we try to support both compilers under a transition period.…”

“…This poses a problem related to functionalities with low TLP and a compatibility problem with existing sequential and non-uniform memory access (NUMA) programs. In our earlier work we have proposed a configurable emulated shared memory (CESM) machine to solve this problem by allowing a number of threads to be bunched together to mimic native NUMA operation so that the overhead introduced by plain ESM architectures can be eliminated [8,11]. The original PRAM-NUMA model of computation [9,11] defines separate networks and memory systems for the different modes of the machine, which is impractical from the point of view of writing unified programs making use of both modes.…”

“…In our earlier work we have proposed a configurable emulated shared memory (CESM) machine to solve this problem by allowing a number of threads to be bunched together to mimic native NUMA operation so that the overhead introduced by plain ESM architectures can be eliminated [8,11]. The original PRAM-NUMA model of computation [9,11] defines separate networks and memory systems for the different modes of the machine, which is impractical from the point of view of writing unified programs making use of both modes. In order to simplify programming, we have proposed unifying the modes by embedding the NUMA system into the PRAM system so that there is no need for dedicated NUMA network nor dedicated NUMA memories [10].…”