Parallel Performance Wizard: A Performance Analysis Tool for Partitioned

Global-Address-Space Programming

Hung-Hsun Su Max Billingsley III

Alan D. George
High-performance Computing and Simulation (HCS) Research Lab
Dept. of Electrical and Computer Engineering
University of Florida, Gainesville, Florida 32611-6200
{su,billingsley,george}@hcs.ufl.edu

Abstract erful systems, various parallel programming models have

been developed, ranging from message-passing to parti-
Given the complexity of parallel programs, developers tioned global-address-space models. Given the added com-
often must rely on performance analysis tools to help them plexity (compared to sequential programming) of these par-
improve the performance of their code. While many tools allel models, users often must rely on performance analy-
support the analysis of message-passing programs, no tool sis tools (PATs) to help them improve the performance of
exists that fully supports programs written in program- their application. Among the available programming mod-
ming models that present a partitioned global address space els, the Message Passing Interface (MPI) has received the
(PGAS) to the programmer, such as UPC and SHMEM. Ex- majority of PAT research and development, as it remains
isting tools with support for message-passing models can- the most well known and widely used parallel programming
not be easily extended to support PGAS programming mod- model. Almost all existing parallel PATs support MPI pro-
els, due to the differences between these paradigms. Fur- gram analysis. These include tools such as HPCToolkit [1],
thermore, the inclusion of implicit and one-sided communi- KOJAK [2], MPE/Jumpshot [3], Paradyn [4], and TAU [5].
cation in PGAS models renders many of the analyses per- Recently, SPMD-based models providing the program-
formed by existing tools irrelevant. For these reasons, there mer with a partitioned global address space (PGAS) ab-
exists a need for a new performance tool capable of han- straction have been gaining popularity, including models
dling the challenges associated with PGAS models. In this such as Unified Parallel C (UPC) [6], SHMEM, Co-Array
paper, we first present background research and the frame- Fortran [7], and Titanium [8]. By extending the mem-
work for Parallel Performance Wizard (PPW), a modular- ory hierarchy to include an additional, higher-level global
ized, event-based performance analysis tool for PGAS pro- memory layer that is partitioned between nodes in the sys-
gramming models. We then discuss features of PPW and tem, these models provide an environment similar to that
how they are used in the analysis of PGAS applications. of threaded sequential programming. This global memory
Finally, we illustrate how one would use PPW in the anal- abstraction is especially important in cluster computing, as
ysis and optimization of PGAS applications by presenting a it no longer requires programmers to manually orchestrate
small case study using the PPW version 1.0 implementation. message exchange between processing nodes. Instead of
the explicit, two-sided data exchange (i.e. send, receive)
required by message-passing models1 , PGAS models al-
low for explicit or implicit one-sided data exchange (i.e.
Keywords Performance analysis tool, partitioned global put, get) through reading and writing of global variables.
address space, UPC, SHMEM, profiling, tracing. These one-sided communication operations greatly reduce
the complexity of data management from a programmer’s
1 Introduction perspective by eliminating the need to carefully match sends
and receives between communicating nodes. Furthermore,
To meet the growing demand for greater computing 1 MPI-2 does support one-sided operations, but with strong usage re-
power, new shared-memory machines and clusters are con- strictions that limit their usefulness (e.g. no concurrent writes are allowed
stantly being built. In order to take advantage of these pow- from different nodes to separate locations in the same window).
PGAS models can enable the development of new algo-
rithms for large systems that are otherwise too complex to
program under a message-passing environment [9].
However, the PGAS abstraction does force the program-
mer to give up some control over the communication be-
tween processing nodes, which can lead to a reduction in
performance (due to increases in the likelihood of unde-
sired program behavior). This situation is especially true
in a cluster environment when inter-node operations are ex-
pensive compared to local operations. Therefore, PAT sup-
Figure 1. Experimental measurement stages
port for PGAS models becomes even more critical to the
programmer. Unfortunately, no tool exists that fully sup-
ports the analysis of programs written using PGAS models. not portable and can only perform simple analyses. Many
In this paper, we present our work on Parallel Perfor- performance tools use the Performance Application Pro-
mance Wizard (PPW), a new parallel performance analysis gramming Interface (PAPI) [11], which provides platform-
tool that supports partitioned global-address-space program independent access to hardware counters on a variety of
analysis. The remainder of the paper is organized as fol- platforms. In addition, some tools, such as KOJAK and
lows: Section 2 provides a brief overview of existing per- Paradyn, also attempt to automatically identify performance
formance analysis tools. In Section 3 we present back- bottlenecks and quantify their impact on performance.
ground research, and in Section 4 we introduce the high-
level framework for PPW. We then discuss features of PPW
and their usage in PGAS application analysis in Section 5. 3 Background Research
Next, in Section 6, we demonstrate how PPW can be used
to optimize PGAS programs by presenting a case study. Fi- In order to develop a suitable framework to fully support
nally, we conclude the paper and give future directions for PGAS models, we conducted several studies, including an
PPW research and development in Section 7. evaluation of existing performance analysis tools [12], an
examination of PGAS programming models, and a study
2 Overview of Performance Analysis Tools of tool usability. Based on the findings from these stud-
ies, we were able to identify several key characteristics and
techniques common to successful PATs that are also appli-
There are numerous performance tools based on the ex-
cable to PGAS models. These findings will be referenced
perimental measurement approach available for sequential
throughout the remainder of this paper.
and parallel programming [10]. In this approach, pro-
grams are executed and performance data are gathered 1. It is critical for a successful tool to provide source-code
through sampling or event recording under tracing or profil- correlation so a user can easily associate performance
ing mode. In tracing mode, instances of performance data data with actual code.
are recorded separately from one another, while in profiling
mode only statistical information is kept. Figure 1 illus- 2. Profiling data allow users to quickly identify possible
trates the typical stages in the experimental measurement areas to focus their tuning efforts, while tracing data
approach. In this cycle, user code is first instrumented by provide detailed information that is often necessary to
the tool to provide some entry point for performance data determine the cause of performance degradation. Both
to be collected. This instrumented version is then executed of these types of data are useful in their own right.
and event data are measured and recorded during runtime.
Based on these data, the tool then performs various data pro- 3. The wrapper approach for instrumentation commonly
cessing and automatic analyses, and the result is presented found in MPI tools works well with SHMEM libraries,
to the user through a text-based or graphical interface. Fi- but would be inadequate for compiler-based imple-
nally, optimizations are made to the original code and the mentations of other PGAS models. A new instrumen-
whole cycle repeats until an acceptable level of performance tation method is needed to support PGAS models.
is reached.
In terms of model support, tools supporting sequen- 4. The inability of most existing tools in tracking and ana-
tial C and MPI are the most common, with some also lyzing implicit one-sided communication remains one
supporting shared-memory programming models such as of the biggest roadblocks in extending them to support
OpenMP. Few tools have any support for SHMEM or UPC, PGAS models. A new model is needed to handle im-
and tools with basic support for these models are typically plicit one-sided communication.
 5. Although PATs are effective in troubleshooting perfor-
mance problems, they are often too difficult to use and
as a result are not used by programmers. An intuitive
and easy-to-learn user interface is often the most crit-
ical quality of a productive tool. In addition, the tool
should automate the optimization process as much as
possible to alleviate the amount of effort needed from
the user.

4 PPW Framework

Figure 2 shows the framework of Parallel Performance

Wizard, which consists of modules corresponding to the
stages of the experimental performance analysis cycle.
While the overall design of our framework is similar to that
of other performance tools, there are a few key differences Figure 2. The high-level framework of PPW
in the design to accommodate the goal of supporting multi- organized with respect to the stages of ex-
ple PGAS models in a single tool. Note that the optimiza- perimental measurement
tion stage is not included in the framework because auto-
matic code optimization is still not practical with current
technologies.
One important, novel aspect of the design of this frame- compiler optimization and lacks the means to handle a re-
work is the use of generic operation types instead of model- laxed memory model. Binary instrumentation, in which the
specific constructs whenever possible. This approach is vi- compiled binary is modified to facilitate data collection, is
tal in providing support for multiple PGAS models success- not available on some architectures, and it is often difficult
fully while minimizing the number of components needed. to relate the data back to the source code. Finally, the in-
For each supported programming model, the Event Type termediate library approach (such as PMPI), in which li-
Mapper maps the model-specific constructs to their appro- brary functions are wrapped with versions invoking mea-
priate generic operation types (e.g. upc_memget maps to surement code, does not work for “pure” compilers, such
one-sided get, shmem_barrier maps to all-to-all, etc.). as GCC UPC, that translate parallel constructs directly into
Once this classification has been made, the majority of the byte code.
components in PPW then work with the generic operation To accommodate the many instrumentation techniques
types and consult the Event Type Mapper only when model- appropriate for various PGAS model implementations,
specific information is needed. As a result, only a single without introducing multiple measurement components, we
implementation of a component is often needed, which sig- proposed an Instrumentation-Measurement Interface called
nificantly reduces the effort needed to support multiple pro- the Global Address Space Performance (GASP) interface
gramming models. Currently, PPW includes the follow- [14]. Such an interface shifts the responsibility of where
ing operation types applicable to existing PGAS models: to add instrumentation code and how to obtain source code
startup, termination, barrier, collective, point-to-point syn- information (finding 1) from the tool writer to the compiler
chronization, one-sided put, one-sided get, non-blocking writer, which improves the accuracy of the data gathered.
operation synchronization, and work sharing. The follow- The simplicity of the interface minimizes the effort required
ing paragraphs describe each component in the framework from the compiler writer to add PAT support to their sys-
in more detail. tem. In addition, a PAT can quickly add support for any
The Instrumentation Units deal with how to enable PGAS compiler which includes an implementation of the
recording of performance data and specify when these data GASP interface by simply defining the body of a generic
are gathered (i.e. what is considered an event and how it event notification function (findings 1, 3, 5). We were able
will trigger the recording of data). Due to the differences to demonstrate that this is a suitable approach for PGAS
in techniques used in the development of PGAS program- models with the Berkeley UPC GASP implementation3 (for
ming environments, no single existing instrumentation tech- which we observed profiling overhead < 3% and tracing
nique works well for all PGAS model implementations2 . overhead < 5%).
Source instrumentation, in which entry points to data col- The Measurement Unit deals with what type of data to
lection are added in the original source code, may prevent record and how to acquire the data accurately. Like many
2 See [13] for more information on various instrumentation techniques. 3 Developed by the Berkeley UPC group for BUPC version 2.4+ [15].
 could be different even though they are both classified as
Table 1. Example events recorded for each one-sided get operations), multiple model-specific resolu-
generic operation type tion units are needed. Finally, the High-Level Analysis
Unit provides analyses applicable to the entire program,
such as critical-path analysis, scalability analysis, and load-
Operation Type Event of Interest4 balancing analysis.
all-to-all time, system size (num nodes) The Data Format Converter unit is solely responsible
point-to-point time, sender, receiver for converting PPW performance data into other estab-
one-sided data transfer time, sender, receiver, data size lished performance data formats. Again, only a single
all other time component implementation is needed because of the use of
generic operation types (e.g. converting upc_memput and
shmem_memput to another format is essentially the same,
since the data recorded for both is the same).
existing PATs, this unit supports both tracing and profiling The Visualization Manager provides the user-friendly,
of data and allows the recording of PAPI hardware coun- graphical interface of the tool (finding 5). It is responsible
ters (finding 2). However, instead of dealing with model- for generating useful visualizations from the performance
specific constructs as existing PATs do (which often leads data gathered by the Measurement Unit or generated by the
to multiple measurement units being needed for multiple analysis module. Version 1.0 of PPW includes traditional
model support), this unit works with a generic data format. visualizations such as charts and tabular views of profile
This format, which is based on generic operation types de- data, a graphical data-transfer view, and a novel shared-
fined in the Event Type Mapper, describes a set of events of array distribution diagram (see Section 4 for more informa-
interest to record for each operation type (Table 1). Using tion regarding these), all with source code correlation when
this generic data format, additional model support requires appropriate (finding 1). In addition, viewing of trace data
no modification of the Measurement Unit as long as the con- in a timeline format is achieved by exporting through the
structs of the new model can be associated with the existing Data Format Converter to viewers such as Jumpshot and
generic operation types of the Event Type Mapper. Vampir [16]. With these, we were able to avoid replicat-
Once the performance data are collected by the Mea- ing the capabilities of these full-featured timeline viewers,
surement Unit, they are passed to the Performance Data while bringing these capabilities to the world of PGAS pro-
Manager. The primary responsibilities of this unit include gramming.
access and storage of data, merging of data, and simple
post-processing of data (e.g. calculating averages). Like
the Measurement Unit, this data manager operates on the
5 PPW Features and Usage
generic data format to support multiple models through a
single component implementation. In this section, we present several features of PPW and
outline how each is used in the optimization process. Many
The analysis module aims to provide the tool with semi-
of these features are borrowed from existing tools, helping
automatic program analysis capability. A new bottleneck
minimize the time needed to learn a new tool. Where ap-
detection and resolution model based on the generic opera-
propriate, new features have been developed as needed for
tion types is currently being developed (the details of which
analyzing the performance of PGAS programs.
are beyond the scope of this paper). The roles of each of
the three units in the analysis module are briefly mentioned
here. The Bottleneck Detection Unit, which operates on 5.1 Semi-Automatic Instrumentation
the generic operation types, is responsible for the identifi-
cation of potential performance bottlenecks in a given ap- One of the key features of PPW is the ability to en-
plication. Once these are identified, the model-specific Bot- able performance data collection with little or no user input.
tleneck Resolution Unit then tries to provide additional in- Through GASP implementations, all system events (user
sights into what caused these performance degradations and functions and parallel model constructs) are automatically
possibly provide suggestions on how to remove them from instrumented by the tool (finding 5). In addition, users are
the application. Since resolution techniques can be differ- free to track the performance of any region of the program,
ent for particular models even for the same type of oper- as GASP supports user-defined events that can be manually
ation (e.g. a technique to fix the performance degradation defined anywhere in the application. During execution time,
stemming from upc_memget versus from shmem_get PPW then automatically collects the data for all system and
user-defined events under trace or profile mode (as speci-
4 Note that PPW can record PAPI counter events for any type of opera- fied by the user). At the same time, PPW also captures in-
tion, though they are mainly used for local analysis. formation regarding the execution environment such as op-
 Figure 4. PPW Experimental Set Comparison
Figure 3. PPW Region-based Load Balancing chart providing side-by-side comparison of
Analysis visualization to facilitate the identi- data files loaded
fication of load imbalance issues

the user to quickly associate performance data and corre-

timization flags used, machine hostnames, etc. These data sponding source code (finding 1). These statistical data,
are then processed and used to create various visualizations such as total time, percentage of whole program, average
described in the following sections. time, minimum time, maximum time, and number of calls,
are useful in identifying specific code regions with long ex-
5.2 Visualizations for Program Perfor- ecution time. Moreover, the user can use them to identify
mance Overview potential bottlenecks. A region with the minimum or maxi-
mum time far below or exceeding its average execution time
Amdahl’s Law suggests that to maximize the perfor- could potentially be a bottleneck in the application. An ex-
mance gain from optimization, one should concentrate on ample is when particular instances of the region’s execution
optimizing the most time-consuming parallelizable part of took much longer than others to complete, which suggests
the program. As a result, many programmers begin perfor- that these instances were not executed optimally (PPW also
mance analysis by identifying application regions that took provides a Load Balancing Analysis visualization to detect
the longest time to run. Once identified, programmers then this behavior, as shown in Figure 3). In addition, if the user
concentrate their effort on finding performance issues re- has some idea of the region’s expected execution time (e.g.
lated to these regions. To this end, PPW provides charts and shmem_barrier takes around 100µs to execute when no
diagrams to facilitate the identification of time-consuming bottleneck exists), he or she can quickly identify potential
application segments (for example, one of the pie charts in- bottleneck regions if the actual average execution time far
cluded in PPW shows the breakdown of time spent in the exceeds the expected value.
10 longest running regions with respect to the total program
execution time). 5.4 Multiple Data Set Support

5.3 Statistical Data Tables PPW supports the loading of multiple performance data
sets at once, a feature that proves useful when working with
Like other successful tools, PPW displays high-level sta- multiple related experimental runs. Included also in PPW
tistical performance information in the form of two tables is the Experiment Set Comparison chart (Figure 4) that the
that show statistical data for all regions of a program. The user can use to quickly compare the performance of data
Profile Table reports flat profile information while the Tree sets loaded. For example, when the user loads the data sets
Table (Figure 7) separately reports the performance data for for the same program running on different system sizes, he
the same code region executed in individual callpaths. Se- or she can quickly determine the scalability of the program
lecting an entry in these tables highlights the corresponding and identify sequential and parallel portions of the program.
line in the source code viewer below the tables, allowing Another use is to load data sets for different revisions of the
 Figure 6. PPW Array Distribution visualiza-
tion showing the physical layout of a 7x8 ar-
ray with blocking factor of 3 on a system with
Figure 5. PPW Data Transfers visualization 8 nodes
showing the communication volume between
processing nodes for put operations
have distributed the data as desired, a particularly important
consideration when using the PGAS abstraction. We are
program running on the same system size and compare the also currently investigating the possibility of incorporating
effect of the revisions on performance. communication pattern information with this visualization
to give more insight into how specific shared objects are be-
5.5 Communication Pattern Visualization ing accessed. This extension would allow PPW to provide
more specific details as to how data transfers behaved dur-
In many situations, especially in cluster computing, sig- ing program execution.
nificant performance degradation is associated with poorly
arranged inter-node communications. The Data Transfer vi-
sualization (Figure 5) provided by PPW is helpful in iden- 6 Case Study
tifying communication related bottlenecks such as commu-
nication hot spots. While this visualization is not unique In this section, we present a small case study conducted
to PPW, ours is able to show communications from both using PPW version 1.0 [17]. We ran George Washington
implicit and explicit one-sided data transfer operations in University’s UPC implementation [18] of the FT bench-
the original program. By default, this visualization depicts mark (which implements an FFT algorithm) from the NAS
the inter-node communication volume for all data transfer benchmark suite 2.4 using Berkeley UPC 2.4, which in-
operations in the program, but users are able to view the cludes a fully functional GASP implementation. Tracing
information for a subset of data transfers (e.g. puts only, performance data were collected for the class B setting exe-
gets with payload size of 8-16kB, etc.). Threads that initi- cuted on a 32-node Opteron 2.0 GHz cluster with a Quadrics
ate an inordinate amount of communication will have their QsNetII interconnect. Initially no change was made to the
corresponding blocks in the grid stand out in red. Similarly, FT source code.
threads that have affinity to data for which many transfers From the Tree Table for the FT benchmark (Figure 7),
occur will have their column in the grid stand out. it was immediately obvious that the fft function call (3rd
row) constitutes the bulk of the execution time (9s out of
5.6 Array Distribution Visualization 10s of total execution time). Further examination of per-
formance data for events within the fft function revealed
A novel visualization provided by PPW is the Array Dis- that upc_barriers (represented as upc_notify and
tribution, which graphically depicts the physical layout of upc_wait) in transpose2_global (6th row) ap-
shared objects in the application on the target system (Fig- peared to be a potential bottleneck. We came to this con-
ure 6). Such a visualization helps users verify that they clusion from the fact that the actual average execution time
 Figure 8. Annotated Jumpshot view of the
original version of FT showing the serialized
Figure 7. PPW Tree Table visualization for the
nature of upc memget
original FT shown with code yielding part of
the performance degradation

sion of upc_memget with a parallel one. Fortunately,

Berkeley UPC includes such an asynchronous memget
for upc_barrier at lines 1943 (176 ms) and 1953 (0.5s) operation (bupc_memget_async). When the original
far exceeds the expected value of 2ms on our system for upc_memget was replaced with the asynchronous ver-
32 nodes (we obtained this value by running a benchmark sion, we were able to cut down the execution time of the
with no bottlenecks). Looking at the code between the two FT benchmark by 1.56s, an improvement of 14% over the
barriers, we saw that multiple upc_memgets were issued original version.
and suspected that the performance degradation might be In this small case study, we have shown how PPW was
related to these upc_memgets. However, we were unable used to optimize a PGAS program. With little knowledge
to confirm this suspicion based on the data provided by the of how the FT benchmark works, we were able to remove a
Tree Table alone, since we did not know the expected execu- major bottleneck in the program within a few hours of using
tion time for upc_memget for that payload size. More de- PPW.
tailed performance data regarding these lines of code were
needed. 7 Conclusions
We next converted the performance data from the PPW
format into the Jumpshot SLOG-2 format in order to look As hardware technologies for parallel computing mature,
at the behavior of upc_barriers and upc_memgets so too does the development of programming models to
in a timeline format. With the viewer, we discovered support the execution of parallel applications. While such
that the upc_barrier at line 1953 was waiting for applications have the potential to achieve very high perfor-
upc_memget calls to complete. In addition, we saw that mance, this is often not realized due to the complexity of
upc_memget calls issued from the same node were un- the execution environment. To tackle this problem, many
necessarily serialized, as shown in the annotated screenshot parallel performance analysis tools have been developed to
of the Jumpshot viewer in Figure 8 (note the zigzag pattern help users optimize their code, with most tools support-
for these memgets). Looking at the start and end time of ing the message-passing model. However, newer models
the upc_memget calls issued from node 0 to all nodes in such as those for partitioned global-address-space program-
the system, we saw that the later upc_memget must wait ming have very limited tool support. In this paper, we have
for the earlier upc_memget to complete before initiating, outlined the bridging of this gap with the introduction of
even though the data obtained are not related. our PGAS performance analysis tool called Parallel Perfor-
The apparent solution to improve the performance of mance Wizard. We presented the high-level framework de-
the FT benchmark was to replace the serialized ver- sign of PPW based on generic operation types, and we then
discussed features and usage of these features provided by [7] B. Numrich and J. Reid, “Co-Array Fortran for Parallel
the tool. We also demonstrated the effectiveness of PPW in Programming”, ACM Fortran Forum, 17(2), pp. 1–31,
PGAS application analysis through a small case study using 1998.
the version 1.0 release of the tool.
We are currently working to complete the development [8] K. Yelick, L. Semenzato, G. Pike, C. Miyamoto, B. Lib-
of the bottleneck detection and resolution model mentioned lit, A. Krishnamurthy, P. Hilfinger, S. Graham, D. Gay, P.
above and to improve the usability of the tool’s user inter- Colella, and A. Aiken, “Titanium: A High-Performance
face. In addition, we are in the process of extending the Java Dialect”, Workshop on Java for High-Performance
design and implementation of PPW to fully support a vari- Network Computing, Las Vegas, Nevada, June 1998.
ety of additional programming models, including MPI and [9] A. Johnson, “CFD on the Cray X1E Using Unified Par-
Reconfigurable Computing (RC) systems. Finally, we are allel C”, a PowerPoint presentation, 5th UPC Workshop,
also investigating the possibility of mixed-model analysis September 2005.
for applications written using multiple programming mod- http://www.gwu.edu/˜upc/upcworkshop05/ahpcrcUPC
els. User Forum.pdf

Acknowledgments [10] L. DeRose, B. Mohr and K. London, “Performance

Tools 101: Principles of Experimental Performance
This work was supported in part by the U.S. Department Measurement and Analysis,” SC2003 Tutorial M-11.
of Defense. We would like to acknowledge former mem- [11] K. London, S. Moore, P. Mucci, K. Seymour, R.
bers of the UPC group at UF, Adam Leko, Hans Sherburne, Luczak, “The PAPI Cross-Platform Interface to Hard-
and Bryan Golden, for their involvement in the design and ware Performance Counters”, Department of Defense
development of PPW. Also, we would like to express our Users’ Group Conference Proceedings, Biloxi, Missis-
thanks for the helpful suggestions and cooperation of Dan sippi, June 2001.
Bonachea and the UPC group members at UCB and LBNL.
[12] S. Shende, “The Role of Instrumentation and Mapping
References in Performance Measurement”, Ph.D. Dissertation, Uni-
versity of Oregon, August 2001.
[1] J. Mellor-Crummey, R. J. Fowler, G. Marin, and N. [13] A. Leko, H. Sherburne, H. Su, B. Golden, A.D.
Tallent. “HPCVIEW: A tool for top-down analysis of George. “Practical Experiences with Modern Parallel
node performance”. The Journal of Supercomputing, Performance Analysis Tools: An Evaluation”.
23(1):81–104, August 2002. http://www.hcs.ufl.edu/upc/toolevaluation.pdf
[2] B. Mohr and F. Wolf. “KOJAK – a tool set for au- [14] H. Su, D. Bonachea, A. Leko, H. Sherburne, M.
tomatic performance analysis of parallel applications”. Billingsley III, and A. George, “GASP! A Standard-
European Conference on Parallel Computing (EuroPar), ized Performance Analysis Tool Interface for Global
pages 1301–1304, Klagenfurt, Austria, LNCS 2790, Au- Address Space Programming Models”, Proc. of Work-
gust 26–29, 2003. shop on State-of-the-Art in Scientific and Parallel Com-
[3] A. Chan, W. Gropp, and E. Lusk. “Scalable log files for puting (PARA06), Umeå, Sweden, June 18–21, 2006.
parallel program trace data(draft)”, 2000. http://gasp.hcs.ufl.edu/

[4] B. P. Miller, M. D. Callaghan, J. M. Cargille, J. [15] Berkeley UPC project website. http://upc.lbl.gov/
K. Hollingsworth, R. B. Irvin, K. L. Karavanic, K.
[16] Vampir tool website. http://www.vampir-ng.de/
Kunchithapadam, and T. Newhall. “The paradyn par-
allel performance measurement tool”. IEEE Computer, [17] PPW Project website. http://ppw.hcs.ufl.edu/
28(11):37–46, November 1995.
[18] GWU UPC NAS 2.4 benchmarks.
[5] S. S. Shende and A. D. Malony. “The Tau Par- http://www.gwu.edu/ upc/download.html
allel Performance System”. International Journal of
High-Performance Computing Applications (HPCA),
20(2):297–311, May 2006.
[6] The UPC Consortium, “UPC Language Specifica-
tions”, May 2005.
http://www.gwu.edu/˜upc/docs/upc specs 1.2.pdf