Supporting the Memory System Evaluation with a Monitor Simulator
Jie Tao
LRR-TUM, Institut für Informatik,
Technische Universität München, 85748 Garching, Germany
E-mail: tao@in.tum.de
Abstract
Memory system is one of the most important issues which
exhibit a critical impact on the performance of applica-
tions running on both uni- and multi-processors. This pa-
per presents a simulation approach capable of collecting
detailed information about the complete memory hierarchy,
providing thereby feedback that can support explicit opti-
mizations as well as automatic tuning of programs with re-
spect to memory efficiency. The deployed simulator is a flex-
ible and independent component modeling an existed hard-
ware monitor which observes the inter-node communica-
tions. The monitor simulator is also capable of tracing the
transactions within a single processor. In addition, it can
be optionally combined with any level of the entire mem-
ory system and used in combination with various simulation
tool. This allows a collection of accurate and comprehen-
sive performance data, while keeping the monitoring com-
ponent extensible, portable, and well applicable.
1 Motivation
Memory access latency is a general performance issue on
various compute systems including uniprocessors and mul-
tiprocessors especially those with distributed shared mem-
ory. For the former, the gab between processors and mem-
ory speeds continues to grow, incurring a drastic impact on
the overall performance. For the latter, the problem is more
severe since accesses to remote memories usually show a
significant high latency. Data locality is therefore becoming
increasingly addressed. In uniprocessors, this is presented
as cache locality which can be improved by reducing the
cache misses [8, 14]. In shared memory multiprocessors,
additional locality issues exist which are related to the data
distribution capable of being optimized by limiting the ne-
cessity to access remote memories [11, 13].
The basis for such optimizations, however, is the ability
to acquire performance data. Common used approaches are
Proceedings of the Eleventh Euromicro Conference on Parallel,Distributed and Network-Based Processing (Euro-PDP’03)
0-7695-1875-3/03 $17.00 © 2003 IEEE
hardware counters [7], software profiling [3], and simula-
tion [5]. Compared with the first two approaches, simula-
tion has the advantages of being able to support not only the
evaluation of existed systems but also the prediction of new
architectures. This approach is hence used within the work
presented here.
The simulation approach has long been used for pre-
dicting and analyzing performance on target architectures.
Among the developed simulation tools, the most compre-
hensive system is SimOS [4], which models the entire
uniprocessor and multiprocessor computer systems allow-
ing a collection of performance data on different hardware
components. The data collection is done by annotations
which are simple Tcl scripts executed when an event of in-
terest occurs in the simulator. Another well known simu-
lation system is SIMICS [9] which accurately models the
system view of the target machine. A profiling approach is
deployed within SIMICS for data acquisition. Besides these
simulation tools which usually target the complete architec-
ture, several simulators address special issues like network
routing [6] and I/O devices [1].
However, all existed systems acquire performance data
via inserting annotations or instrumentation instructions in
the simulator. As a full instrumentation is not allowed, the
collected data can be incomplete. In addition, performance
data can be only provided at the end of the simulation pro-
cess, rendering any on-line performance analysis as impos-
sible.
Hence, we develops a monitor simulator specially for
collecting performance data about the complete memory
system including caches, memory accesses, and inter-node
communications. The monitor concept is based on a hard-
ware monitor [5] implemented for observing the intercon-
nection traffic on a NUMA-like cluster. It is designed to
snoop a local bus over which inter-node transactions are
transfered. It then extracts information from the transac-
tions. The acquired information, i.e. access source, desti-
nation, and access address, is first stored in its registers and
further delivered to a ring buffer. From the ring buffer, data
can be accessed by the users and system softwares.
 This concept is extended in the monitor simulator in or-
der to be able to observe the buses between CPU and the L1
cache, L1 and the L2 cache, as well as L2 and the local main
memory. In addition, the monitor simulator post-processes
the monitoring information generating coarse-grained per-
formance data such as access histograms. This enables an
easy evaluation of the target component and a detection of
access hot spots.
More specially, the monitor simulator is an independent
component and can be combined with any simulation tool
capable of modeling the memory system. It can also be se-
lectively inserted in any level of the memory hierarchy. This
allows the user to flexibly choose the hardware of interest.
In addition, monitoring data is stored in a specific physical
memory space and periodically refreshed allowing an on-
line analysis by performance tools. Besides these, the mon-
itor simulator can be restarted during the simulation proce-
dure. This enables the acquisition of per-phase information
which can be used to optimize the synchronization opera-
tions, like locks and barriers, which generally have a critical
performance impact on shared memory applications.
The monitor simulator has been combined with a sim-
ulation tool called SIMT [12]. SIMT is an event-driven
multiprocessor simulator modeling the parallel execution
of shared memory applications on SMPs and NUMA ma-
chines, with a focus on the memory hierarchy. For the mon-
itor simulator, SIMT serves as a base simulation platform
contributing memory references. First results have shown
the feasibility and applicability of this monitoring approach.
The remainder of this paper is structured as follows. Sec-
tion 2 describes the monitor simulator in detail, including
the monitoring concept, the simulation implementation, the
processing of the monitoring information, and the interface
to a simulation tool. Section 3 briefly outlines the simula-
tion environment SIMT on which the monitor simulator is
validated. In Section 4, first experimental results with an
initial evaluation of the memory system are discussed. The
paper concludes with some concluding remarks in Section
5.
2 The Monitor Simulator
Simulation is regarded as a valuable approach for study-
ing the target architectures. Developed simulation systems,
however, usually embed the data collection in the simula-
tors themselves preventing a full acquisition of performance
data as well as an on-line analysis.
This work deploys a single data collection mechanism,
which uses a monitor simulator to allow the generation of
complete information about hardwares. As the focus is on
the memory system, this monitoring component is designed
to observe the memory traffic performed on caches and the
distributed memories. The benefit of using a monitor sim-
Proceedings of the Eleventh Euromicro Conference on Parallel,Distributed and Network-Based Processing (Euro-PDP’03)
0-7695-1875-3/03 $17.00 © 2003 IEEE
ulator is the feasibility, flexibility, and the portability. Fea-
sibility means that the gathered performance data is accu-
rate and complete due to the full trace of memory transac-
tions. Flexibility means that the user can optionally insert
the monitor simulator in different levels of the memory hi-
erarchy in order to focus the study on a specific component
or the entire memory system. Finally, the monitor simu-
lator is an independent software package and can be used
with various simulation tools forming another feature: the
portability.
2.1 Hardware Model
The monitor simulator uses a monitoring concept based
on the hardware device [5] developed for an SCI-based 1
PC cluster. This monitoring facility is developed for trac-
ing NUMA interconnection transactions in order to provide
information about inter-node communications.
This hardware monitor comprises three components: a
link interface, a counter array, and a PCI interface. The
link interface is used to snoop a local bus, which connects a
single node to the actual interconnection fabric, and extract
information from the transactions transfered over this bus.
The counter array, the primary part of the hardware monitor,
consists of registers for storing the information extracted by
the link interface. The PCI interface, an interface between
the PCI bus and the monitor, offers direct access to the host
node enabling the users or system software modules to con-
figure the hardware monitor and read the gathered monitor-
ing data.
The hardware monitor can be configured into two work-
ing modes: static mode and dynamic mode. The static
mode allows to explicitly program the hardware for event
triggering and action processing on special memory regions
of interest, while the dynamic working mode is based on
histogram-driven monitoring, in which all memory transac-
tions through the local interconnect bus are monitored in
order to provide fine-grain monitoring statistics across the
complete application’s working set. In order to be able to
record all remote memory accesses to and from a node with
only limited hardware resources, a large user-defined ring
buffer is maintained in the main memory. Whenever all
counters of the hardware monitor are filled or one counter
is about to overflow, a counter is evicted from the hardware
monitor and stored in the ring buffer. The free counter is
then reclaimed by the monitoring hardware for the further
monitoring process.
As the goal of this work is to provide comprehensive in-
formation about memory operations, it is not necessary to
simulate the static mode which is specially considered for
1 SCI (Scalable Coherent Interface): an IEEE-standardized interconnec-
tion technology with high bandwidth, low latency, and global physical ac-
cess space.
 event triggering. In addition, the detailed hardware design
of the link and the PCI interface is not relevant to the ac-
curacy of the monitoring data. Both interfaces are hence
simplified using flexible models.
2.2 Simulation Concept
The simulation concept is exactly adopted from the hard-
ware facility with a few extensions. First, the link interface
of the hardware monitor is modeled as a packet generator. It
receives the access address and transaction type as the input
and for each transaction creates a packet which is actually a
data structure for information contained in the transactions.
Stored information includes access source, transaction type,
destination, and access address which are page number and
offset for memory references and the number of cache lines
for accesses to cache memories.
The packets, generated by the packet generator, form the
input to the module simulating the counter array. As the
counter array is the main component of the monitoring fa-
cility, it is also the primary part of the monitor simulator.
Besides inheriting the full ability of the hardware, the sim-
ulated counter array is capable of distinguishing between
memory accesses and cache transactions. In addition, it col-
lects more information, e.g. transaction type, which is not
contained in the hardware registers.
The structure of the monitor simulator is shown in Figure
1. As can be seen, the packet-generator handles the transac-
tions delivered by the base simulation system. The result is
information in the form of single items including the trans-
action type, the source node or process ID depending on
the location of the monitor, the number of virtual pages or
cache lines, and the page offset which is empty for caches.
The transaction type can be read, write, lock, and unlock for
memory accesses, and load, hit, and replace for caches.
Whenever a transaction is issued, this information is
compared with the corresponding parts of the counter array.
If there is a matching entry, the corresponding counter is in-
cremented. For example, a new packet is generated which
corresponds to a read operation issued by node 2 to page
15 with an offset of 32. While there already exists a corre-
sponding entry (the first one) in the counter array, this trans-
action is recorded in the same counter. Otherwise a new
counter will be initialized. In the case that no more space
is available within the counter array, the least recently used
counter is flushed to the ring buffer and the write-pointer of
the buffer is incremented.
As described above, each transaction is recorded using a
single counter entry. Actually, the user does not need this
fine granularity which can lead to large histograms. The
monitor simulator therefore includes the ability to influence
the granularity of the monitoring data and thereby to adjust
the monitor behavior to the intended use of the data.
Proceedings of the Eleventh Euromicro Conference on Parallel,Distributed and Network-Based Processing (Euro-PDP’03)
0-7695-1875-3/03 $17.00 © 2003 IEEE
This granularity control is done in two steps. First, each
transaction is filtered using a predefined mask allowing to
delete unimportant transactions. In the second step transac-
tions on neighboring memory addresses or cache lines are
aggregated during the monitoring process. This aggrega-
tion is controlled by a user–definable parameter specifying
the maximal range of addresses which are allowed to be
combined.
In summary, the simulation concept is close to the hard-
ware design. This can be used to help the hardware imple-
mentation with respect to the trade-off between hardware
costs and runtime overheads for delivering the monitoring
data. In addition, a few extensions have been added to the
monitor simulator. The extensions lie mainly on the moni-
toring of cache transactions which are out of the capability
of the hardware. For this corresponding mechanisms have
been added to both the packet generator and the counter ar-
ray in order to record cache specific information.
2.3 Processing the Monitoring Data
Performance data collected by the monitor simulator is
finally stored in the ring buffer which is a specific physi-
cal space in the main memory. This enables the monitoring
information to be accessed by the users and various perfor-
mance tools. The monitor simulator itself provides func-
tionality to process the monitoring data and generate access
histograms in the following way.
The individual data items directly gathered during the
monitoring process are first sorted into a buffer organized as
a histogram chain. Within this buffer, data is indexed using
page (cache line) numbers where all items with the same
page/line number are linked to the same chain. This enables
a fast searching of the buffer since information about all
transactions performed on a page or cache line can be found
in a single chain.
Based on the histogram chain, the low-level monitoring
information can be transformed to a higher-level and more
readable form at various granularity. For this, a number of
functions have been provided which compute numbers of
accesses on a specific memory region, a complete virtual
page or cache line, and a whole processor node. The type of
accesses can be specified allowing the statistical data about
specific transactions.
2.4 Interface to Simulation Tools
The monitor simulator is intended for the combination
use with a simulation tool which is capable of generating
memory transactions. For this the address and transaction
type are needed from the base simulation tool. On the side
of the monitor simulator, an C-API defines functions for
operating the monitoring. For example:
 access address and transaction type

packet−generator counter array

trans_type source/PID page_num/line_num offset counter

read 2 15 32 counter 1

read_ptr write 1 24 4 counter 2

lock 0 10 8 counter 3
unlock 4 15 4 counter 4

load 1 30 counter 5
read hit 2 3 counter 6

write hit 1 5 counter 7

replace 1 10 counter 8
write_ptr

ring buffer
specific physical space

Figure 1. Working principle of the monitor simulator.

 Monitor config(void *monin, int gran, int mask, int
counters): allocates space for the counters and initial-
izes the parameters for granularity control.
 Monitor on(void *monin): switches the specified
monitor on or off. In the case of an off operation, all
monitoring data in the counter array is delivered to the
ring buffer.
 Packet generate(int source, unsigned long addr, int
transtype, Paket *paket): generates an information
packet for the corresponding transaction.
 Monitor(Paket paket, void *monin): records the packet
in the corresponding monitor.
Besides these functions for operating the monitor, the C-
API contains other routines for processing the performance
data obtained during the monitoring process. These rou-
tines fulfill the complete data handling described in the pre-
vious subsection, from raw data reading up to the creation
of memory access histograms. The latter can be used to
analyze the access pattern and improve the data locality of
applications.
3 SIMT as an Evaluation Platform
The monitor simulator has been combined with a simu-
lation system, called SIMT (SIMulation Tool)[12]. SIMT
simulates NUMA-characterized PC clusters with a focus on
the behavior of remote memory accesses and the goal of aid-
ing the data locality optimization on the distributed shared
memory. SIMT runs applications from the SPLASH-2
Benchmark suite [15] and any other application written in
C/C++ using m4 macros [2] in a fashion similar to SPLASH
and SPLASH-2 applications. It supports a thread-based
programming model with a shared address space and a pri-
vate stack space for each thread.
SIMT comprises a front-end (a memory reference gen-
erator) and a backend modeling the target system. This is
shown in Figure 2. The front-end is based on Augmint [10],
a multiprocessor simulation toolkit for Intel x86 architec-
tures. It simulates the parallel execution of multiple pro-
cesses running on multiple processors and generates events
of interest. The main contributions of the front-end are
memory references which can be captured by the backend.
The latter is a user-defined target system simulator invoked
every time a significant event (memory access and synchro-
nization operation) occurs.
Memory events Target
Reference System
Generator Simulator
(frontend) process (backend)
control
Figure 2. The two simulation components of
SIMT.

Proceedings of the Eleventh Euromicro Conference on Parallel,Distributed and Network-Based Processing (Euro-PDP’03)
0-7695-1875-3/03 $17.00 © 2003 IEEE
 CPU L1 cache L2 cache
monitor monitor
simulator simulator
L1 access L2 access
histogram histogram
Performance data: memory access histograms
Figure 3. Using multiple monitor simulators to observe the memory system.
The backend consists of functionality representing the
handling of these events on real hardware. As SIMT is in-
tended primarily for research in the area of memory system
design, the main components of the backend are a cache
simulator modeling a two level cache hierarchy with sev-
eral cache consistency protocols, a shared memory simu-
lator modeling the distributed shared memory with a spec-
trum of data distribution policies, and a network mechanism
modeling the data transfer across processor nodes.
Memory references delivered by the front-end are first
filtered by the cache simulator. Those references, which are
not satisfied within L1 or L2, are handled by the memory
simulator as accesses to the main memory. Depending on
the data distribution policies, these accesses can be either
local accesses or remote ones. For a local access, a bus-
request is issued and scheduled to be completed in a con-
stant time corresponding to the simulated CPU. For a non-
local memory reference, a network request with a times-
tamp is generated and inserted into a priority queue. This
request is handled when it has the lowest timestamp in the
queue and arranged to be completed in the time specified
for remote memory accesses, according to the property of
the simulated interconnection fabric. Numbers of local and
remote accesses across the whole shared virtual space are
counted and the memory access histogram of an application
is formed.
As SIMT aims at supporting the study of remote mem-
ory accesses, it offers only hit and miss ratios with respect
to caches. In order to be capable of supplying complete in-
formation about the various levels contained in the memory
hierarchy including CPU–L1, L1–L2, L2–memory, and lo-
cal memory–remote memory, the monitor simulator is com-
Proceedings of the Eleventh Euromicro Conference on Parallel,Distributed and Network-Based Processing (Euro-PDP’03)
0-7695-1875-3/03 $17.00 © 2003 IEEE
local memory
inter−
connection
network
monitor monitor
simulator simulator
histogram of histogram of
local accesses remote accesses
bined with SIMT and added on each level of the memory
hierarchy (see Figure 3) in the same way.
As shown in Figure 3, each monitor simulator gener-
ates independent memory access histogram occurring at
the corresponding locations in the system. These access
histograms can be individually used for analyzing specific
component and also be combined into a final result, which
shows the combined memory access information serving as
the base of evaluating the complete memory system.
4 First Experimental Result
Using the monitor simulator in combination with SIMT,
a set of benchmark applications taken from the SPLASH-
II suite [15] have been simulated. These codes are intended
for shared memory machines and capable of being executed
on top of SIMT. A few of them are chosen for showing.
These include FFT, a fast Fourier transformation, LU, an
LU-decomposition for dense matrices, RADIX, an integer
radix sort, and WATER for evaluation of water molecule
systems.
For the following experiments, a cluster system is used
on which shared data is distributed over the system in a
round-robin fashion. Each processor node has an 8 KB
L1 cache and a 64 KB L2 cache, each with 32 byte cache
lines and a two–way associative organization. L1 uses the
write-through scheme, while L2 uses the write-back pol-
icy. Caches in different processors are maintained coherent
with a hardware-like coherence protocol which invalidates
all cache copies by a write operation to shared data.
 80
RM
Number of accesses 70 LM
60 L2
L1
50

40

30

20

10

0
0

6
44

92

40

88

36

84

32

80

28

76

24

72

20

68

16

64
44

89
13

17

22

26

31

35

40

44

49

53

58

62

67

71

76

80
Address of accessed location

Figure 4. Parts of a complete memory access histogram (FFT on a 8 node system).

4.1 Access Histogram on the Complete Memory Cache line No. of accesses Hit Load hit ratio
System 0 121 117 4 0.96
1 96 91 5 0.94
The first experiment is done for acquiring complete ac- 2 90 54 36 0.6
cess histograms on the whole memory system. For this, 3 122 119 3 0.97
each module in the memory hierarchy is connected with a 4 82 38 44 0.46
monitor simulator. The granularity has been set to a single 5 87 48 39 0.55
word and numbers of accesses on different memory words 6 48 41 7 0.85
are computed. 7 74 22 52 0.29
Figure 4 visualizes parts of the complete access his- ... ... ... ... ...
togram obtained by simulating the FFT code on a 8 node
system. The x-axis shows the accessed locations, while the Table 1. L1 access histogram for WATER.
corresponding numbers of accesses hit in L1, L2, the local
memory (LM), and remote memories (RM) respectively are
presented on the y-axis. While a great L1 hit ratio has been
shown, it can also be observed that more accesses target- shows the percentage of cache hits to the total accesses on a
ing main memories are remote when compared to the local single cache line. It can be seen that some cache lines have a
accesses and accesses to the L2 cache. low number of hits and a high number of loads, hence a low
hit ratio. This indicates that such cache lines are highly re-
4.2 Individual access histogram quired, but frequently replaced and reloaded without a con-
tinuous residence in the cache. This scenario can cause sig-
The complete access histogram described above aims at nificant performance loss and has to be avoided.
giving a first overview of the memory behavior. For opti- While the cache histogram supports the optimization of
mizing specific components, various individual access his- data distribution in caches, the histogram of accesses to the
tograms are more usable which can be acquired by a single distributed memory aids in the improvement of memory lo-
monitor. cality on shared memory systems. Such a histogram can
Table 1 shows an access histogram of the L1 cache ac- be achieved by monitoring the interconnection network to-
quired by simulating the WATER code on a uniprocessor. gether with the local memories.
This table presents the first several cache lines with their Figure 5 shows such a histogram acquired by simulating
numbers shown on the first column, the total accesses on the RADIX code on a 4 node system. The figure presents all
the second column, and the number of hit and loading on virtual pages located on node 0. The number of accesses to
the third and fourth column individually. The last column these pages are illustrated using columns, each representing

Proceedings of the Eleventh Euromicro Conference on Parallel,Distributed and Network-Based Processing (Euro-PDP’03)
0-7695-1875-3/03 $17.00 © 2003 IEEE
 8000
Number of accesses 7000
6000
5000
4000
3000
2000
1000
0
0 4 8 12 16
Number of pages
Figure 5. Histogram of accesses to the distributed memory (RADIX).
a single access source. It can be seen that most pages are
required by multiple nodes. However, they are not equally
accessed, rather a node performs dominant accesses. This
information is therefore capable of directing an optimized
placement of data on a distributed system.
5 Conclusions
Performance of the memory system generally shows a
significant impact on the overall performance of a sys-
tem. In order to support the evaluation and optimization of
this kernel, various approaches have been proposed among
which simulation is particularly usable due to its ability to
model new architectures. Such a simulation approach is
presented in this paper.
Common simulation systems, however, usually integrate
the data allocation with the simulation itself and can thereby
provide only performance data at the end of the simulation.
In order to allow a flexible and on-line acquisition of perfor-
mance data, this work deploys a single monitoring compo-
nent which can deliver the monitoring data at run-time dur-
ing the execution and be inserted in any level of the memory
hierarchy. As this monitor simulator is independent of the
target system, it can be selectively added and can be used
with any simulation tool capable of modeling the memory
system. This allows the investigation of various memory
architectures as well as the optimization of individual mod-
ules and the complete memory system.
The first experimental results show that the monitor sim-
ulator is able to supply a variety of access histograms at
different granularity. A few sample results which can be
used to optimize the cache locality and memory locality
Proceedings of the Eleventh Euromicro Conference on Parallel,Distributed and Network-Based Processing (Euro-PDP’03)
0-7695-1875-3/03 $17.00 © 2003 IEEE
local node1
node2 node3
20 24 28 32 36 40 44 48 52
have been presented in this paper. Besides these full ac-
cess histograms, the monitor simulator allows a generation
of per-phase monitoring results which is useful for under-
standing the temporal behavior of applications with distinct
phases. Overall, these results have proven the applicability
and efficiency of the explored monitoring approach.
References
[1] R. Bagrodia, E. Deeljman, S. Docy, and T. Phan. Perfor-
mance Prediction of Large Parallel Applications Using Par-
allel Simulations. ACM SIGPLAN Notices, 34(8):51–162,
August 1999.
[2] J. Boyle, R. Butler, T. Disz, B. Glickfeld, E. Lusk, R. Over-
beek, J. Patterson, and R. Stevens. Portable Programs for
Parallel Processors. Holt, Rinehart, and Winston Incorpora-
tion, New York, NY, 1987.
[3] D. Cortesi. Origin2000 and Onyx2 Performance Tuning and
Optimization Guide, chapter 4. Silicon Graphics Incorpora-
tion, 1998.
[4] S. A. Herrod. Using Complete Machine Simulation to Un-
derstand Computer System Behavior. PhD thesis, Stanford
University, February 1998.
[5] R. Hockauf, W. Karl, M. Leberecht, M. Oberhuber, and
M. Wagner. Exploiting Spatial and Temporal Locality of Ac-
cesses: A New Hardware-based Monitoring Approach for
DSM Systems. In Proceedings of Euro-Par’98 Parallel Pro-
cessing / 4th International Euro-Par Conference Southamp-
ton, volume 1470 of Lecture Notes in Computer Science,
pages 206–215, UK, September 1998.
[6] H. C. Hsiao and C. T. King. MICA: A Memory and Inter-
connect Simulation Environment for Cache-based Architec-
tures. In Proceedings of the 33rd IEEE Annual Simulation
Symposium (SS 2000), pages 317–325, April 2000.
 [7] Intel Corporation. Intel Architecture Software Developer’s
Manual for the PentiumII, volume 1–3. published on Intel’s
developer website, 1998.
[8] C. Luk and T. C. Mowry. Memory Forwarding: En-
abling Aggressive Layout Optimizations by Guaranteeing
the Safety of Data Relocation. In Proceedings of the
26th International Symposium on Computer Architecture
(ISCA’99), pages 88–99, May 1999.
[9] P. S. Magnusson and B. Werner. Efficient Memory Simula-
tion in SimICS. In Proceedings of the 8th Annual Simulation
Symposium, Phoenix, Arizona, USA, April 1995.
[10] A.-T. Nguyen, M. Michael, A. Sharma, and J. Torrellas. The
Augmint Multiprocessor Simulation Toolkit for Intel x86
Architectures. In Proceedings of 1996 International Confer-
ence on Computer Design, pages 486–491. IEEE Computer
Society, October 1996.
[11] S. Tandri and T. S. Abdelrahman. Automatic partitioning
of data and computations on scalable shared memory multi-
processors. In Proceedings of the 1997 International Con-
ference on Parallel Processing (ICPP ’97), pages 64–73,
Washington - Brussels - Tokyo, Aug. 1997.
[12] J. Tao, W. Karl, and M. Schulz. Using Simulation to Un-
derstand the Data Layout of Programs. In Proceedings of
the IASTED International Conference on Applied Simula-
tion and Modeling (ASM 2001), pages 349–354, Marbella,
Spain, September 2001.
[13] J. Tao, W. Karl, and M. Schulz. Visualizing the Memory Ac-
cess Behavior of Shared Memory Applications on NUMA
Architectures. In Proceedings of the 2001 International
Conference on Computational Science (ICCS), volume 2074
of LNCS, pages 861–870, San Francisco, CA, USA, May
2001.
[14] D. Truong. Considerations on Dynamically Allocated Data
Structure Layout Optimization. In Proceedings of the first
Workshop on Profile and Feedback-Directed Compilation,
in conjunction with PACT’98, Paris, France, October 1998.
[15] S. C. Woo, M. Ohara, E. Torrie, J. P. Singh, and A. Gupta.
The SPLASH-2 Programs: Characterization and Method-
ological Considerations. In Proceedings of the 22nd Annual
International Symposium on Computer Architecture, pages
24–36, June 1995.

Proceedings of the Eleventh Euromicro Conference on Parallel,Distributed and Network-Based Processing (Euro-PDP’03)
0-7695-1875-3/03 $17.00 © 2003 IEEE