Matching memory access patterns and data placement for NUMA systems

Abstract

Many recent multicore multiprocessors are based on a nonuniform memory architecture (NUMA). A mismatch between the data access patterns of programs and the mapping of data to memory incurs a high overhead, as remote accesses have higher latency and lower throughput than local accesses. This paper reports on a limit study that shows that many scientific loop-parallel programs include multiple, mutually incompatible data access patterns, therefore these programs encounter a high fraction of costly remote memory accesses. Matching the data distribution of a program to the individual data access patterns is possible, however it is difficult to find a data distribution that matches all access patterns.Directives as included in, e.g., OpenMP provide a way to distribute the computation, but the induced data partitioning does not take into account the placement of data into the processors' memory. To alleviate this problem we describe a small set of language-level primitives for memory allocation and loop scheduling. Using the primitives together with simple program-level transformations eliminates mutually incompatible access patterns from OpenMP-style parallel programs. This result represents an improvement of up to 3.3X over the default setup, and the programs obtain a speedup of up to 33.6X over single-core execution (19X on average) on a 4-processor 32-core machine.

Optimizing virtual machine scheduling in NUMA multicore systems

“…Zhang et al [40] transform programs in a cache-sharing-aware manner and Majo et al [28] aim to preserve program data locality on NUMA systems. Such transformations can be further made transparent to users and automated at compiler level [39].…”

“…Sub-optimal and unpredictable program performance due to shared on-chip resources remains top concern as it seriously compromises the efficiency, fairness, and Quality-of-Service (QoS) that the platform is capable to provide [41]. There are existing work focusing on hardware techniques [32] and program transformations [28,39,40] to mitigate the problem. Thread scheduling, a more flexible approach, has been also studied to avoid the destructive use of shared resources [7,8,11,14,30] or to use them constructively [5,35,38].…”

Evaluation and Optimization of Breadth-First Search on NUMA Cluster

“…NUMA has provided much larger capacity of shared memory or even shared cache, but remote memory accesses suffer much longer latency and lower bandwidth than local memory accesses, which, if not properly handled, may lead to serious performance reduction [10,[28][29][30]32].…”

“…Though NUMA can provide a much powerful node with more than one processor -more cores and memory, it can be a significant problem for applications due to the congestion on cross-chip interconnects, long latency and potential bandwidth saturation of remote memory accesses [10,[28][29][30]32]. For example, it is shown in [32] that the performance of a multi-threaded program when running on 4 cores (1 socket) and 8 cores (2 sockets) are almost the same.…”

A NUMA-Aware Runtime Environment for the Actor Model

“…If their specific hardware characteristics are not taken into consideration, concurrency for the shared resources might cause important performance degradation [7], [8]. Efficient utilization of these machines has been a very active field of research [9], [10], [11], [12]. However, to the best of our knowledge, there has been no research on the adaptation of actor model REs for these platforms.…”