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