In order to exploit the flexibility of OpenMP in parallelizing large scale multi-physics applications where different modes of parallelism are needed for efficient computation, it is first necessary to be able to scale OpenMP codes as well as MPI on large core counts. In this research we have implemented fine grained OpenMP parallelism for a large CFD code GenIDLEST and investigated the performance from 1 to 256 cores using a variety of performance optimization and measurement tools. It is shown through weak and strong scaling studies that OpenMP performance can be made to match that of MPI on the SGI Altix systems for up to 256 cores. Data placement and locality were established to be key components in obtaining good scalability with OpenMP. It is also shown that a hybrid implementation on a dual core system gives the same performance as standalone MPI or OpenMP. Finally, it is shown that in irregular multi-physics applications which do not adhere solely to the SPMD (Single Process, Multiple Data) mode of computation, as encountered in tightly coupled fluid-particulate systems, the flexibility of OpenMP can have a big performance advantage over MPI.

OpenMP is a defacto standard API for shared memory programming with widespread vendor support and a large user base. The OpenMP Architecture Review Board has sanctioned an interface specification known as the ”OpenMP Runtime API for Profiling” to enable tools to collect performance data for OpenMP programs. This paper describes the interface and our experiences implementing it in OpenUH, an open source OpenMP compiler.

Parallel programming languages/libraries including OpenMP, MPI, and UPC are either in the process of defining or have already established standard performance profiling interfaces. The OpenMP Architecture Review Board (ARB) recently sanctioned an interface specification for profiling/tracing tools that defines a protocol for two-way communications and control between the OpenMP runtime library and performance tools, known as the collector API. Reference implementations of the collector are sparse and are primarily closed-source. We provide a description of our efforts towards a full implementation of an open-source performance monitoring tool for OpenMP based on the collector API. This effort(a) evaluates the collector's approach to performance measurement, assesses what is necessary to implement a performance tool based on the collector interface, and also provides information Useful to performance tool developers interested in interfacing with the collector for performance measurements.

Most OpenMP performance analysis tools are usually stand-alone and provide data to the user after an application completes running. Considerable time and effort can be spent learning to use different tools and waiting for results to become available post-execution. It is beneficial to develop a runtime system that exploits the synergistic effects between compilers and performance tools to alleviate this overhead. An added advantage for such a system is that the instrumentation points do not interefere with static compiler optimizations because they reside in the runtime environment. But as with most run-time systems, the problem of runtime overheads must be addressed. In this project, we address these issues and build a prototype implementation of a run-time performance environment that applies a light-weight sampling based technique to extract low level performance metrics and map these metrics to higher levels of abstraction. Experiments are run on our environment using a kernel application and we display preliminary data.

The motivation, design, implementation, and current status of a new set of software tools called PerfSuite that is targeted to performance analysis of user applications on Linux-based systems is described. These tools emphasize ease of use/deployment and portability/reuse in implementation details as well as data representation and format. After a year of public beta availability and production deployment on Linux clusters that rank among the largest-scale in the country, PerfSuite is gaining acceptance as a user-oriented and flexible software tool set that is as valuable on the desktop as it is on leading-edge terascale clusters.

Throw more hardware at it or make it run faster? Here's the elegant, low-budget way to high performance.

Many factors contribute to overall application performance in today’s highperformance cluster computing environments. These factors include the memory subsystem, network hardware and software stack, compilers and libraries, and I/O subsystem. The large variability in hardware and software configurations present in clusters can cause application performance to also exhibit large variability on different platforms or on the same platform over time. Compute-intensive applications may perform well on an architecture with efficient utilization of CPU and single-processor memory, such as the Intel Xeon, while memory-intensive applications may perform well on an architecture with good scalability of the memory subsystem, such as the AMD Opteron node [6]. Even with a fixed hardware configuration, software factors can cause large variations in performance. Compilers that produce acceptable code on some platform configurations may produce suboptimal code on other platform variants. Some math libraries require hand tuning of various compiled-in parameters, and a library that is hand-tuned for one platform may perform poorly on a different variant of the same platform. Some libraries (e.g., BLAS, LAPACK) have standardized APIs that are shared across different implementations that can have considerable variations in performance. It can be difficult to predict which library variant will perform best on a particular platform without testing each variant on that platform. If an application is updated and/or ported to a platform originally not supported, the optimization flags in the application Makefile may be anachronistic or otherwise inappropriate and may need to be altered to achieve acceptable performance on new target platforms and platform variants.

A framework for induction of decision trees suitable for implementation on shared- and distributed-memory multiprocessors or networks of workstations is described. The approach, called Parallel Decision Trees (PDT), overcomes limitations of equivalent serial algorithms that have been reported by several researchers, and enables the use of the very-large-scale training sets that are increasingly of interest in real-world applications of machine learning and data mining.

Induction systems that represent concepts in the form of production rules have proven to be useful in a variety of domains where both accuracy and comprehensibility of the resulting models are important. However, the computational requirements for inducing a set of rules from large, noisy training sets can be enormous, so that techniques for improving the performance of rule induction systems by exploiting parallelism are of considerable interest. Recent work to parallelize the C4.5 rule generator algorithm is described. After presenting an overview of the algorithm and the parallelization strategy employed, empirical results of the parallel implementation that demonstrate substantial speedup over serial execution are provided.

-performance cluster computing environments. These factors include the memory sub-system, network hardware and software stack, compilers and libraries, and I/O sub-system. The large variability in hardware and software configurations present in clusters can cause application performance to also exhibit large variability on differ-ent platforms or on the same platform over time. Compute-intensive applications may perform well on an architecture with efficient utilization of CPU and single-processor memory, such as the Intel Xeon, while memory-intensive applications may perform