Is data distribution necessary in OpenMP?
Proceedings of the 2000 ACM/IEEE conference on Supercomputing
Extending OpenMP for NUMA machines
Proceedings of the 2000 ACM/IEEE conference on Supercomputing
The trade-off between implicit and explicit data distribution in shared-memory programming paradigms
ICS '01 Proceedings of the 15th international conference on Supercomputing
Measuring memory hierarchy performance of cache-coherent multiprocessors using micro benchmarks
SC '97 Proceedings of the 1997 ACM/IEEE conference on Supercomputing
IPPS '95 Proceedings of the 9th International Symposium on Parallel Processing
Exploiting Data Locality on Scalable Shared Memory Machines with Data Parallel Programs
Euro-Par '00 Proceedings from the 6th International Euro-Par Conference on Parallel Processing
Exploiting Multiple Levels of Parallelism in OpenMP: A Case Study
ICPP '99 Proceedings of the 1999 International Conference on Parallel Processing
A transparent runtime data distribution engine for OpenMP
Scientific Programming
Hi-index | 0.00 |
In contrast to the common belief that OpenMP requires data-parallel extensions to scale well on architectures with non-uniform memory access latency, recent work has shown that it is possible to develop OpenMP programs with good levels of memory access locality, without any extension of the OpenMP API. The vehicle for localizing memory accesses transparently to the programming model, is a runtime memory manager, which uses memory access tracing and dynamic page migration to implement automatic data distribution. This paper evaluates the effectiveness of using this runtime data distribution method in non embarrassingly parallel codes, such as the SPEC benchmarks. We investigate the extent up to which sophisticated management of physical memory in the runtime system can speedup programs for which the programmer has no knowledge of the memory access pattern. Our runtime memory management algorithms improve the speedup of five SPEC benchmarks by 20-25% on average. The speedups are close to the theoretical maximum speedups for the problem sizes used and they are obtained with a minimal programming effort of about a couple of hours per benchmark.