 underlying system performance, and not by decisions made by the compiler.
For SGI IRIX and UNICOS systems, OpenMPdelivers performance comparable to that delivered by the MIPSpro and Autotasking directives currently available on those systems. Because of the similarities between OpenMP and the directives currently available on these systems, existing back-end compiler and library technologies were used to implement OpenMP, and this technology is what determines the ultimate performance of the model.
What about NUMA (Non-Uniform Memory Access) issues?
The current definition of OpenMP does not include any directives or features specifically tied to NUMA architectures. It is expected that for systems where this is important, vendors (including SGI) will supply extensions to OpenMP.
SGI Origin systems have a NUMA architecture, specifically referred to as S2MP. The current MIPSpro Power parallel compiler directives includes several directives that support data distribution on Origin systems. The implementation of OpenMP in MIPSpro compilers allows full interoperability with these data distribution directives. This capability allows an application developer to exploit the portability of OpenMP for expressing parallelism, while using these data distribution directives for NUMA-specific optimizations on the Origin.
Is OpenMP scalable?
OpenMP can deliver scalability for applications using shared-memory parallel programming. Significant effort was spent to ensure that OpenMP can be used for scalable applications.
In the past, many programmers using shared-memory directives were limited to loop-level parallelism, a form of fine grain parallelism. And OpenMP also provides good support for loop-level parallelism. But much of the parallelism inherent in an application may not be expressible simply as iterations of loops, and so loop-level parallelism is inherently non-scalable for most real applications.
OpenMP goes beyond earlier shared-memory directives in that it also supports more scalable, coarse grain parallelism. OpenMP introduces the concept of "orphan" directives, which allow more complex code and the use of parallelized libraries within an application. OpenMP also includes directives that allow you to divide work up among threads.
What about non-shared memory machines like the CRAY T3E or networks of workstations?
As much as it would be nice to think that a single programming model (OpenMP or MPI or HPF or whatever) might run well on all architectures, this is not the case today.
OpenMP was designed to exploit certain characteristics of shared-memory architectures. The ability to directly access memory throughout the system (with minimum latency and no explicit address mapping) combined with very fast shared memory locks, makes shared-memory architectures best suited for supporting OpenMP.
Systems that don't fit the classic shared-memory architecture may provide hardware or software layers that present the appearance of a shared-memory system, but often at the cost of higher latencies or special limitations. For example, OpenMP could be implemented for a distributed memory system on top of MPI, so OpenMP's latencies would be greater than that of MPI (whereas typically the reverse is the case on a shared-memory system).
The extent to which these latencies or limitations reduce application portability or performance will help dictate whether vendors choose to develop OpenMP implementations for distributed memory systems. SGI currently has no plans to implement OpenMP for the CRAY T3E or for running applications across systems in a cluster.
Why will OpenMP succeed when PCF and X3H5 failed?
There are a variety of reasons OpenMP will succeed at being accepted as a standard, where earlier efforts failed.
What about support from debugging and performance tools?
On SGI systems, OpenMP is supported by the standard development tools:
Other system vendors and third-party developers offer tools that support OpenMP; the OpenMP web site includes information on these.
Can I intermix <programming model> with OpenMP?
The ability to intermix 