See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220244788

The gem5 simulator

Article  in  ACM SIGARCH Computer Architecture News · August 2011

DOI: 10.1145/2024716.2024718 · Source: DBLP

CITATIONS READS

3,133 5,188

16 authors, including:

Nathan L. Binkert Bradford Beckmann

University of Michigan Advanced Micro Devices
59 PUBLICATIONS   6,744 CITATIONS    23 PUBLICATIONS   5,776 CITATIONS   

SEE PROFILE SEE PROFILE

Ali Saidi Arkaprava Basu

ARM University of Wisconsin–Madison
40 PUBLICATIONS   5,576 CITATIONS    13 PUBLICATIONS   3,733 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

University of Michigan, Ann Arbor View project

Photonic Architectures View project

All content following this page was uploaded by Bradford Beckmann on 21 April 2015.

The user has requested enhancement of the downloaded file.

 The gem5 Simulator
Nathan Binkert1 , Bradford Beckmann2 ,
Gabriel Black , Steven K. Reinhardt2 , Ali Saidi4 , Arkaprava Basu5 , Joel Hestness6 ,
3

Derek R. Hower5 , Tushar Krishna7 , Somayeh Sardashti5 , Rathijit Sen5 , Korey Sewell8 ,
Muhammad Shoaib5 , Nilay Vaish5 , Mark D. Hill5 , and David A. Wood5

http://gem5.org

Abstract emergence of multicore systems and deeper cache hier-

archies has presented architects with several new dimen-
The gem5 simulation infrastructure is the merger of the sions of exploration. On the other hand, researchers need
best aspects of the M5 [4] and GEMS [9] simulators. a flexible simulation framework that can evaluate a wide
M5 provides a highly configurable simulation framework, diversity of designs and support rich OS facilities includ-
multiple ISAs, and diverse CPU models. GEMS comple- ing IO and networking.
ments these features with a detailed and flexible mem- Computer architecture researchers also need a simula-
ory system, including support for multiple cache coher- tion framework that allows them to collaborate with their
ence protocols and interconnect models. Currently, gem5 colleagues in both industry and academia. However, a
supports most commercial ISAs (ARM, ALPHA, MIPS, simulator’s licensing terms and code quality can inhibit
Power, SPARC, and x86), including booting Linux on that collaboration. Some open source software licenses
three of them (ARM, ALPHA, and x86). can be too restrictive, especially in an industrial setting,
The project is the result of the combined efforts of many because they require publishing any simulator enhance-
academic and industrial institutions, including AMD, ments. Furthermore, poor code quality and the lack of
ARM, HP, MIPS, Princeton, MIT, and the Universities modularity can make it difficult for new users to under-
of Michigan, Texas, and Wisconsin. Over the past ten stand and modify the code.
years, M5 and GEMS have been used in hundreds of pub- The gem5 simulator overcomes these limitations by
lications and have been downloaded tens of thousands providing a flexible, modular simulation system that is
of times. The high level of collaboration on the gem5 capable of evaluating a broad range of systems and is
project, combined with the previous success of the com- widely available to all researchers. This infrastructure
ponent parts and a liberal BSD-like license, make gem5 a provides flexibility by offering a diverse set of CPU mod-
valuable full-system simulation tool. els, system execution modes, and memory system models.
A commitment to modularity and clean interfaces allows
researchers to focus on a particular aspect of the code
1 Introduction without understanding the entire code base. The BSD-
based license makes the code available to all researchers
Computer architecture researchers commonly use soft- without awkward legal restrictions.
ware simulation to prototype and evaluate their ideas. This paper provides a brief overview of gem5’s goals,
As the computer industry continues to advance, the range philosophy, capabilities, and future work along with
of designs being considered increases. On one hand, the pointers to sources of additional information.

1 Hewlett-Packard Labs, Palo Alto, Cal.

2 Advanced Micro Devices, Inc., Bellevue, Wash. 2 Overall Goals
3 Google, Inc., Mountain View, Cal.
4 ARM, Inc., Austin, Tex.
5 University of Wisconsin, Madison, Wisc.
The overarching goal of the gem5 simulator is to be a
6 University of Texas, Austin, Tex. community tool focused on architectural modeling. Three
7 Massachusetts Institute of Technology, Cambridge, Mass. key aspects of this goal are flexible modeling to appeal to
8 University of Michigan, Ann Arbor, Mich. a broad range of users, wide availability and utility to
 operating system (OS) by emulating most system-level
services. Meanwhile, Full-System (FS) mode executes
both user-level and kernel-level instructions and models
a complete system including the OS and devices.
• Memory System. The gem5 simulator includes two
different memory system models, Classic and Ruby.
The Classic model (from M5) provides a fast and eas-
ily configurable memory system, while the Ruby model
(from GEMS) provides a flexible infrastructure capable
of accurately simulating a wide variety of cache coher-
ent memory systems.

The gem5 simulator can also execute workloads in a

Figure 1: Speed vs. Accuracy Spectrum. number of ISAs, including today’s most common ISAs,
x86 and ARM. This significantly increases the number of
workloads and configurations gem5 can simulate.
the community, and high level of developer interaction to Section 4 provides a more detailed discussion of these
foster collaboration. capabilities.

2.1 Flexibility 2.2 Availability

Flexibility is a fundamental requirement of any success- There are several types of gem5 user; each has different
ful simulation infrastructure. For instance, as an idea goals and requirements. These include academic and cor-
evolves from a high-level concept to a specific design, ar- porate researchers, engineers in industry, and undergrad-
chitects need a tool that can evaluate systems at various uate and graduate students. We want the gem5 simulator
levels of detail, balancing simulation speed and accuracy. to be broadly available to each of these types of user. The
Different types of experiments may also require different gem5 license (based on BSD) is friendly both to corporate
simulation capabilities. For example, a fine-grain clock users, since businesses need not fear being forced to re-
gating experiment may require a detailed CPU model, veal proprietary information, and to to academics, since
but modeling multiple cores is unnecessary. Meanwhile, they retain their copyright and thus get credit for their
a highly scalable interconnect model may require several contributions.
CPUs, but those CPUs don’t need much detail. Also, by
using the same infrastructure over time, an architect will 2.3 High level of collaboration
be able to get more done more quickly with less overhead.
The gem5 simulator provides a wide variety of capa- Full-system simulators are complex tools. Dozens of
bilities and components which give it a lot of flexibility. person-years of effort have gone into the gem5 simula-
These vary in multiple dimensions and cover a wide range tor, developing both the infrastructure for flexible model-
of speed/accuracy trade offs as shown in Figure 1. The ing and the numerous detailed component models. By
key dimensions of gem5’s capabilities are: being an open source, community-led project, we can
leverage the work of many researchers, each with differ-
• CPU Model. The gem5 simulator currently provides ent specialties. The gem5 community is very active and
four different CPU models, each of which lie at a unique leverages a number of collaborative technologies to fos-
point in the speed-vs.-accuracy spectrum. AtomicSim- ter gem5 use and development, including mailing lists, a
ple is a minimal single IPC CPU model, TimingSimple wiki, web-based patch reviews, and a publicly accessible
is similar but also simulates the timing of memory refer- source repository.
ences, InOrder is a pipelined, in-order CPU, and O3 is
a pipelined, out-of-order CPU model. Both the O3 and
InOrder models are “execute-in-execute” designs [4]. 3 Design Features
• System Mode. Each execution-driven CPU model This section focuses on a few key aspects of gem5’s im-
can operate in either of two modes. System-call Emula- plementation: pervasive object orientation, Python inte-
tion (SE) mode avoids the need to model devices or an gration, domain-specific languages, and use of standard
interfaces. While most of these features are simply good two domain-specific languages, one for specifying instruc-
software engineering practice, they are all particularly tion sets (inherited from M5) and one for specifying cache
useful for designing simulators. coherence protocols (inherited from GEMS).
ISA DSL. The gem5 ISA description language unifies
the decoding of binary instructions and the specification
3.1 Pervasive Object-Oriented Design
of their semantics. The gem5 CPU models achieve ISA
Flexibility is an important goal of the gem5 simulator independence by using a common C++ base class to de-
and key aspect of its success. Flexibility is primarily scribe instructions. Derived classes override virtual func-
achieved through object-oriented design. The ability to tions like execute() to implement opcodes, such as add.
construct configurations from independent, composable Instances of these derived classes represent specific ma-
objects leads naturally to advanced capabilities such as chine instructions, such as add r1,r2,r3. Implementing
multi-core and multi-system modeling. a specific ISA thus requires a set of C++ declarations for
All major simulation components in the gem5 simu- these derived classes, plus a function that takes a machine
lator are SimObjects and share common behaviors for instruction and returns an instance of one of the derived
configuration, initialization, statistics, and serialization classes that corresponds to that instruction.
(checkpointing). SimObjects include models of concrete The ISA description language allows users to specify
hardware components such as processor cores, caches, in- this required C++ code compactly. Part of the language
terconnect elements and devices, as well as more abstract allows the specification of class templates (more general
entities such as a workload and its associated process con- than C++ templates) that cover broad categories of in-
text for system-call emulation. structions, such as register-to-register arithmetic opera-
Every SimObject is represented by two classes, one in tions. Another portion of the language provides for the
Python and one in C++ which derive from SimObject specification of a decode tree that concisely combines op-
base classes present in each language. The Python class code decoding with the creation of specific derived classes
definition specifies the SimObject’s parameters and is as instances of the previously defined templates.
used in script-based configuration. The common Python While the original ISA description language targeted
base class provides uniform mechanisms for instantiation, RISC architectures such as the Alpha ISA, it has been sig-
naming, and setting parameter values. The C++ class en- nificantly extended to cope with complex variable-length
compasses the SimObject’s state and remaining behavior, ISAs, particularly x86, and ISAs with complex register
including the performance-critical simulation model. semantics like SPARC. These extensions include a mi-
crocode assembler, a predecoder, and multi-level register
index translation. These extensions are discussed in more
3.2 Python Integration
detail in a recent book chapter [5].
The gem5 simulator derives significant power from tight Cache Coherence DSL. SLICC is a domain-specific
integration of Python into the simulator. While 85% of language that gives gem5 the flexibility to implement a
the simulator is written in C++, Python pervades all wide variety of cache coherence protocols. Essentially,
aspects of its operation. As mentioned in Section 3.1, SLICC defines the cache, memory, and DMA controllers
all SimObjects are reflected in both Python and C++. as individual per-memory-block state machines that to-
The Python aspect provides initialization, configuration, gether form the overall protocol. By defining the con-
and simulation control. The simulator begins execut- troller logic in a higher-level language, SLICC allows dif-
ing Python code almost immediately on start-up; the ferent protocols to incorporate the same underlying state
standard main() function is written in Python, and all transition mechanisms with minimal programmer effort.
command-line processing and startup code is written in The gem5 version of SLICC is very similar to the prior
Python. GEMS version of SLICC [9]. Just like the prior version,
gem5 SLICC defines protocols as a set of states, events,
3.3 Domain-Specific Languages transitions, and actions. Within the specification files,
individual transition statements define the valid combi-
In situations that require significant flexibility in perform- nations and actions within each transition specify the op-
ing a specialized task, domain-specific languages (DSLs) erations that must be performed. Also similar to the pre-
provide a powerful and concise way to express a variety vious version, gem5 SLICC ties the state machine-specific
of solutions by leveraging knowledge and idioms common logic to protocol-independent components such as cache
to that problem space. The gem5 environment provides memories and network ports.
 While gem5 SLICC contains several similarities to its networks, devices and multiple systems. This section de-
predecessor design, the language does include several en- scribes some of the different options available in these
hancements. First, the language itself is now imple- categories.
mented in Python rather than C++, making it easier ISAs. The gem5 simulator currently supports a variety
to read and edit. Second, to adhere to the gem5 SimOb- of ISAs including Alpha, ARM, MIPS, Power, SPARC,
ject structure, all configuration parameters are specified and x86. The simulator’s modularity allows these differ-
as input parameters and gem5 SLICC automatically gen- ent ISAs to plug into the generic CPU models and the
erates the appropriate C++ and Python files. Finally, memory system without having to specialize one for the
gem5 SLICC allows local variables to simplify program- other. However, not all possible combinations of ISAs
ming and improve performance. and other components are currently known to work. An
up-to-date list can be found on the gem5 website.
Execution Modes. The gem5 simulator can oper-
3.4 Standard Interfaces ate in two modes: System-call Emulation (SE) and Full-
Standard interfaces are fundamental to object-oriented System (FS). In SE mode, gem5 emulates most com-
design. Two central interfaces are the port interface and mon system calls (e.g. read()). Whenever the pro-
the message buffer interface. gram executes a system call, gem5 traps and emulates
Ports are one of the interfaces used to connect two the call, often by passing it to the host operating system.
memory objects together in gem5. In the Classic memory There is currently no thread scheduler in SE mode, so
system, the ports interface connects all memory objects threads must be statically mapped to cores, limiting its
including CPUs to caches, caches to busses, and busses use with multi-threaded applications. The SPEC CPU
to devices and memories. Ports support three mecha- benchmarks are often run in SE mode.
nisms for accessing data (timing, atomic, and functional) In FS mode, gem5 simulates a bare-metal environment
and an interface for things like determining topology and suitable for running an OS. This includes support for in-
debugging. Timing mode is used to model the detailed terrupts, exceptions, privilege levels, I/O devices, etc.
timing of memory accesses. Requests are made to the Because of the additional complexity and completeness
memory system by sending messages, and responses are required, not all ISAs current support FS mode.
expected to return asynchronously via other messages. Compared to SE mode, FS mode improves both the
Atomic mode is used to get some timing information, but simulation accuracy and variety of workloads that gem5
is not message-oriented. When an atomic call is made can execute. While SPEC CPU benchmarks can be run
(via a function call), the state change for the operation in SE mode, running them in FS mode will provide more
is performed synchronously. This has higher performance realistic interactions with the OS. Workloads that require
but gives up some accuracy because message interactions many OS services or I/O devices may only be run in FS
are not modeled. Finally, functional accesses update the mode. For example, because a web server relies on the
simulator state without changing any timing information. kernel’s TCP/IP protocol stack and a network interface
These are generally used for debugging, system-call emu- to send and receive requests and a web browser requires
lation, and initialization. a X11 server and display adapter to visualize web pages
Ruby utilizes the ports interface to connect to CPUs these workloads must be run is FS mode.
and devices, and adds message buffers to connect to Ruby CPU Models. The gem5 simulator supports four dif-
objects internally. Message buffers are similar to ports in ferent CPU models: AtomicSimple, TimingSimple, In-
that they provide a standard communication interface. Order, and O3. AtomicSimple and TimingSimple are
However, message buffers differ in some subtle ways with non-pipelined CPU models that attempt to fetch, decode,
regards to message typing and storage. In the future, execute and commit a single instruction on every cycle.
ports and message buffers may evolve into a unified in- The AtomicSimple CPU is a minimal, single IPC CPU
terface. which completes all memory accesses immediately. This
low overhead makes AtomicSimple a good choice for sim-
ulation tasks such as fast-forwarding. Correspondingly,
4 Simulation Capabilities the TimingSimple CPU also only allows one outstanding
memory request at a time, but the CPU does model the
The gem5 simulator has a wide range of simulation capa- timing of memory accesses.
bilities ranging from the selection of ISA, CPU model, and The InOrder model is an “execute-in-execute” CPU
coherence protocol to the instantiation of interconnection model emphasizing instruction timing and simulation ac-
curacy with an in-order pipeline. InOrder can be config- require Ruby’s detailed protocol modeling but that can
ured to model different numbers of pipeline stages, issue sacrifice detailed network modeling for faster simulation.
width, and numbers of hardware threads. The second Ruby network model is the Garnet network
Finally, the O3 CPU is a pipelined, out-of-order model model [1]. Unlike the simple network, Garnet models the
that simulates dependencies between instructions, func- router micro-architecture in detail, including all relevant
tional units, memory accesses, and pipeline stages. Pa- resource contention and flow control timing. This model
rameterizable pipeline resources such as the load/store is suitable for on-chip network studies.
queue and reorder buffer allow O3 to simulate superscalar Devices. The gem5 simulator supports several I/O
architectures and CPUs with multiple hardware threads devices ranging from simple timers to complex network
(SMT). The O3 model is also “execute-in-execute”, mean- interface controllers. Base classes are available that en-
ing that instructions are only executed in the execute capsulates common device interfaces such as PCI to avoid
stage after all dependencies have been resolved. code duplication and simplify implementing new devices.
Cache Coherence Protocols. SLICC enables Currently implemented models includes NICs, an IDE
gem5’s Ruby memory model to implement many differ- controller, a frame buffer, DMA engines, UARTs, and
ent types of invalidation-based cache coherence protocols, interrupt controllers.
from snooping to directory protocols and several points Modeling Multiple Systems. Because of the simu-
in between. SLICC separates cache coherence logic from lator’s object oriented design it also supports simulating
the rest of the memory system, providing the necessary multiple complete systems. This is done by instantiating
abstraction to implement a wide range of protocol logic. another set of objects (CPU, memory, I/O devices, etc.).
Similar to its GEMS predecessor [9], SLICC performs all Generally, the user connects the systems via the network
operations at a cache-block granularity. The word-level interfaces described above to create a client/server pair
granularity required by update-based protocols is not cur- that communicate over TCP/IP. Since all the simulated
rently supported. This limitation has not been a issue systems are tightly coupled within gem5 the results of
so far because invalidation-based protocols dominate the multi-system simulation is still deterministic.
commercial market. Specifically, gem5 SLICC currently
models a broadcast-based protocol based on the AMD
OpteronTM [7], as well as a CMP directory protocol [10].
5 Future Work
Not only is SLICC flexible enough to model different While gem5 is a highly capable simulator, there is always
types of protocols, but it also simulates them in sufficient a desire for additional features and other improvements.
depth to model detailed timing behavior. Specifically, A few of the efforts underway or under consideration in-
SLICC allows specifying transient states within the in- clude:
dividual state machines as cache blocks move from one
base state to another. SLICC also includes separate vir- • A first-class power model. While external power mod-
tual networks (a.k.a. network message classes) so message els such as Orion [6] and McPAT [8] have been used
dependencies and stalls can be properly modeled. Using with GEMS and M5, we are working on a more com-
these virtual networks, the SLICC-generated controllers prehensive, modular, and integrated power model for
connect to the interconnection network. gem5.
Interconnection Networks. The Ruby memory
• Full cross-product ISA/CPU/memory system support.
model supports a vast array of interconnection topologies
The modularity and flexibility of gem5 enables a wide
and includes two different network models. In essence,
variety of combinations of ISAs, CPU models, and
Ruby can create any arbitrary topology as long as it is
memory systems, as illustrated in Figure 1, each of
composed of point-to-point links. A simple Python file
which can be used in SE or FS mode. Because each
declares the connections between components and short-
component model must support the union of all fea-
est path analysis is used to create the routing tables.
tures required by any ISA in any mode, particular com-
Once Ruby creates the links and routing tables, it can
ponent models do not always work in every conceivable
implement the resulting network in one of two ways.
circumstance. We continue to work to eliminate these
The first Ruby network model is referred to as the Sim- inconsistencies.
ple network. The Simple network models link and router
latency as well as link bandwidth. However, the Simple • Parallelization. To address the inherent performance
network does not model router resource contention and limitations of detailed simulation and leverage the ubiq-
flow control. This model is great for experiments that uity of multi-core systems, we have been refactoring
 gem5’s internal event system to support parallel dis- The gem5 simulator has been developed with gen-
crete event simulation [11]. erous support from several sources, including the Na-
tional Science Foundation, AMD, ARM, Google, Hewlett-
• Checkpoint import. Although gem5’s simple CPU Packard, IBM, Intel, Microsoft, MIPS, Sandia National
models are much faster than their detailed counter- Laboratories and Sun. Individuals working on gem5
parts, they are still considerably slower than binary have also been supported by fellowships from Intel, Lu-
translation-based emulators such as QEMU [3] and cent, and the Alfred P. Sloan Foundation. This material
SimNowTM [2]. Rather than duplicating the enor- is based upon work supported by the National Science
mous effort of developing a binary translation capabil- Foundation under the following grants: CCR-0105503,
ity within gem5, we plan to enable the transfer of state CCR-0219640, CCR-0324878, EAI/CNS-0205286, CCR-
checkpoints from these emulators into gem5. Users will 0105721, CRI-0551401, CSR-0720565, CCF-0916725, and
be able to fast-forward large workloads to interesting CCF-1017650.
points using these high-performance alternatives, then Any opinions, findings and conclusions or recommenda-
simulate from those points in gem5. Even higher per- tions expressed in this material are those of the author(s)
formance may be possible by using a hardware virtual and do not necessarily reflect the views of the National
machine environment such as KVM1 rather than binary Science Foundation (NSF) or any other sponsor.
translation.

References
6 User Resources
[1] Agarwal, N., Krishna, T., Peh, L.-S., and
All gem5 simulator documentation and information is Jha, N. K. GARNET: A detailed on-chip network
available at the website http://www.gem5.org. The web- model inside a full-system simulator. In Proceedings
site includes instructions on how to check out, build, and of IEEE International Symposium on Performance
run the gem5 simulator, as well as how to download sup- Analysis of Systems and Software (ISPASS) (Apr.
plemental support files like OS binaries and disk images. 2009), pp. 33–42.
The gem5 user community is active and communicates
through three mailing lists: (1) the announce mailing list [2] Barnes, B., and Slice, J. SimNow: A fast and
is used to announce significant modifications or achieve- functionally accurate AMD X86-64 system simula-
ments; (2) the user mailing list is used for general discus- tor. Tutorial at the IEEE International Workload
sions about gem5 and for questions about how to use it; Characterization Symposium, 2005.
and (3) the dev mailing list is for discussions regarding
[3] Bellard, F. QEMU, a fast and portable dynamic
mainline gem5 development.
translator. In Proceedings of the USENIX Annual
Developers will find support resources in the form of
Technical Conference (2005), pp. 41–46.
systems for revision control, bug tracking, code reviews,
and code browsing. All of these can be accessed through [4] Binkert, N. L., Dreslinski, R. G., Hsu, L. R.,
the main website. Lim, K. T., Saidi, A. G., and Reinhardt, S. K.
We encourage you to visit the web site, subscribe to The M5 Simulator: Modeling Networked Systems.
the mailing lists, and help us make gem5 a valuable com- IEEE Micro 26, 4 (Jul/Aug 2006), 52–60.
munity resource.
[5] Black, G., Binkert, N., Reinhardt, S. K.,
and Saidi, A. Processor and System-on-Chip Sim-
Acknowledgements ulation. Springer, 2010, ch. 5, “Modular ISA-
Independent Full-System Simulation”.
The authors of this paper are only a small subset of peo-
ple that have contributed to gem5 over the years. We [6] Kahng, A. B., Li, B., Peh, L.-S., and Samadi,
would like to specially thank all those prior contributors K. ORION 2.0: a fast and accurate NoC power
to GEMS and M5, especially Dan Gibson who played a and area model for early-stage design space explo-
key role in the initial integration effort. Without their ration. In Proceedings of the Conference on Design,
work, the unification of GEMS and M5 would not have Automation and Test in Europe (2009), pp. 423–428.
been possible. [7] Keltcher, C. N., McGrath, K. J., Ahmed, A.,
1 http://linux-kvm.org and Conway, P. The AMD Opteron Processor for
 Multiprocessor Servers. IEEE Micro 23, 2 (Mar/Apr
2003), 66–76.
[8] Li, S., Ahn, J. H., Strong, R. D., Brockman,
J. B., Tullsen, D. M., and Jouppi, N. P. Mc-
PAT: an integrated power, area, and timing modeling
framework for multicore and manycore architectures.
In Proceedings of the 42nd Annual IEEE/ACM In-
ternational Symposium on Microarchitecture (2009),
pp. 469–480.
[9] Martin, M. M. K., Sorin, D. J., Beckmann,
B. M., Marty, M. R., Xu, M., Alameldeen,
A. R., Moore, K. E., Hill, M. D., and Wood,
D. A. Multifacet’s general execution-driven mul-
tiprocessor simulator (GEMS) toolset. SIGARCH
Comput. Archit. News 33, 4 (2005), 92–99.
[10] Marty, M. R., Bingham, J. D., Hill, M. D.,
Hu, A. J., Martin, M. M. K., and Wood, D. A.
Improving multiple-CMP systems using token coher-
ence. In Proceedings of the 11th Annual International
Symposium on High-Performance Computer Archi-
tecture (HPCA) (2005), pp. 328–339.
[11] Reinhardt, S. K., Hill, M. D., Larus, J. R.,
Lebeck, A. R., Lewis, J. C., and Wood, D. A.
The Wisconsin Wind Tunnel: Virtual prototyping
of parallel computers. In Proceedings of the 1993
ACM SIGMETRICS Conference on Measurement
and Modeling of Computer Systems (1993), pp. 48–
60.

Vie