Download the GASP specification v1.5
For older versions of GASP and a brief changelog, see this page.
For information and some tips on how to add GASP support to your GAS model implementation, please see this link.
While adding GASP support into GCC UPC, we kept a detailed implementation log which might be useful or insightful for other GASP language implementors.
For an example GASP tool, please check out the GASP dump tool source code tarball. It demonstrates the GASP interface from the tool side by providing a simple tool that logs all GASP events to a file.
H. Su, D. Bonachea, A. Leko, H. Sherburne, M. Billingsley III, and A. George, “GASP! A Standardized Performance Analysis Tool Interface for Global Address Space Programming Models,” Lawrence Berkeley National Lab Tech Report LBNL-61659, September 2006. PDF copy
Please email us at upcgroup AT hcs DOT ufl DOT edu. We want to see the interface become adopted by as many GAS language implementations as possible.
This section is meant to give a quick, “30-second” overview of the GASP performance tool interface - what it is and why you should care about it.
The GASP tool interface is a way to allow writers of performance tools to support several different GAS compilers and runtime systems without having to know intimate details about each system they want to support.
GAS languages such as UPC often rely on the “cleverness” of programmers to exploit locality for good performance, but sometimes it can be very challenging to get good performance out of programs at runtime. And since GAS programs generally undergo all sorts of transformations before they are compiled down to an executable, trying to figure out exactly what a program is doing at runtime and where time is being spent can be tricky.
Most GAS languages currently have very limited support from performance tools. Since these languages do not define a standard way of getting information from different systems, adding support for GAS programs to a performance tool can be time-consuming. Also, since there are several different compilation strategies used by existing GAS compilers, adding support for every existing system would be almost impossible. This is where GASP comes into play - it defines a standard way for GAS systems (such as UPC) and performance tools to interact with one another.
Getting the performance tool interface adopted into the GAS implementations would allow your favorite existing performance tools to easily add support for UPC and other global-address space models. This will allow you to write faster code using less development time, and will give you a more accurate picture of how your GAS program is performing and where it is wasting time.
Right now, the entry barriers for creating UPC performance tools are very high. Adding a performance tool interface would make it significantly easier to add tool support to UPC. This should help reduce user frustrations when they don't get their desired performance since by providing them with a more powerful tool than printf to debug performance problems. In turn, this should help encourage more widespread adoption of the language.
Additionally, implementations that incorporate GASP support can expect a quick turnaround from the PPW performance tool, which is a portable GASP-aware tool available under a very liberal BSD license at the PPW website.
The GASP tool interface uses a pretty simple callback mechanism to notify performance tool code when certain events, such as remote variable accesses, occur at runtime. The full mechanism is described in the specification below.
YES! Please visit the Parallel Performance Wizard website to see an working performance tool that employs the GASP interface to debug the performance of UPC applications.
Berkeley UPC has added GASP support beginning in version 2.3.16, which is available from this website.