GEMS users,
The GEMS team has put its finishing touches on the new 2.1 release, and
it is now available for download at:
http://www.cs.wisc.edu/gems/download.html
Summary of new features:
========================
- Addition of Princeton's interconnect model (Garnet) & interconnect
power model (Orion)
- Detailed modeling of memory controllers for several protocols:
MESI_CMP_filter_directory
MESI_SCMP_bankdirectory
MOESI_CMP_directory
MOSI_SMP_bcast
- Sun Microsystem's Adaptive Transactional Memory Test Platform
(ATMTP) GEMS extension
- Commercial workload setup scripts
- Bugfixes for x86 compilation & protocols
Details
=======
Garnet & Orion
--------------
Garnet is a detailed interconnection network model developed at
Princeton by Niket Agarwal and incorporated inside GEMS. Garnet
includes a "fixed pipeline" model that accurately models a 5-stage
pipeline of a state-of-the-art interconnection network. Garnet also
includes a "flexible pipeline" model that allows the user to vary the
number of router pipeline stages.
Besides performance metrics, Garnet also provides power estimates, as
it incorporates Princeton's Orion interconnect power models. We see
Garnet enabling accurate interconnection network and memory
subsystem evaluations within the GEMS full system simulation
framework.
For more details please visit http://www.princeton.edu/~niketa/garnet.html
Sun's ATMTP
-----------
Sun has recently announced that its forthcoming multicore processor,
code-named Rock, will support a form of hardware transactional memory
(HTM). The Adaptive Transactional Memory Test Platform (ATMTP)
extends GEMS to model Rock's HTM instructions and to provide a
first-order approximation of the success and failure characteristics
of transactions on Rock. ATMTP is not an accurate model of Rock's
implementation or performance, but nonetheless will allow developers
to test and tune their code for Rock, before Rock-based
systems are available. ATMTP will also allow GEMS users to experiment
with extending its functionality or adapting it to model variations on
Rock's HTM support to guide research on future HTM implementations.
Detailed memory controllers
---------------------------
The GEMS memory controller models the timing of DRAM reads and writes,
to more accurately represent performance effects of memory traffic and
memory bandwidth. By convention, protocols that end in "_m" use
the memory controller.
This model assumes a DDR2/DDR3 memory running in closed page mode with
posted CAS. It models bank busy time, memory bus occupancy and
turnaround delays, and refresh. There is currently no support for open page
mode or for FB-DIMM.
Each instance of the memory controller models one address bus, one
data bus, and any number of DIMMs.
Each DIMM has a configurable number of ranks of DRAM. The configuration
and delay values are parameterized; please refer to the comments in
the rubyconfig.defaults file.
Workload scripts
----------------
The GEMS team is happy to include updated checkpoint scripts in the
2.1 release. Changes include increased control over apache
parameters, several bugfixes, and the addition of a dss creation
script (based on the DBmbench suite from Carnegie Mellon). Also,
detailed documentation of the scripts can now be found on the public
GEMS wiki, including information on how to port the new dss script to
an oltp workload.
Documentation
=============
The latest documentation on these new features & components can be
found online at our GEMS wiki:
http://www.cs.wisc.edu/gems/doc/wiki/moin.cgi
Acknowledgments
===============
Thanks to Niket Agarwal and Princeton University for providing us the
code for Garnet & Orion, the Sun Labs group (Mark Moir, Kevin Moore, Dan
Nussbaum) for providing the ATMTP code and integration support, Andrew Phelps for his
detailed memory controller models, and Ruben Titos for his PUTX/PUTS
bugfix to MESI_CMP_filter_directory.
The GEMS development team
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}