Organización para la ejecución del proyecto

There are many computer architecture simulators that are used for doing re- search in multi-core systems. In this section, we cover the ones with some special interest either because they are widely used or because they use some of the simulation time reduction techniques explained in Section 2.4.

2.5.1

Simplescalar and Derivatives

Simplescalar [43, 21] is an execution-driven simulator and one of the most used computer architecture simulators in the 2000s with more than 4000 citations in research papers. It models a single out-of-order superscalar core with two levels of cache and a fixed latency to main memory. The core model assumes a unified structure for the issue queue, reservation stations and reorder buffer that, together with the functional units, it is called the register update unit.

This simple model made Simplescalar attractive because introducing modi- fications and getting experimental results was a relatively fast procedure. Also, the fact that some works compared its accuracy to real hardware [64] also in- creased its popularity although it was shown to have an average error on a set of SPEC CPU 2000 benchmarks of up to 36% on IPC.

There have been works to improve the modeling accuracy of Simplescalar or extending it for simulating multi-cores [64, 182, 53, 17, 178, 58, 111].

One of them is the Zesto simulator [111]. The main objective of Zesto is to increase the modeling detail of Simplescalar. It provides separate issue queues, reservation stations and reorder buffer, models caches in more detail with limited miss handling status registers (MSHR) and prefetching support, among others, and adds a DRAM detailed model together with a model of the memory controller. Because of this low-level detail, Zesto is claimed to be slower than other research pipeline simulators of the time. Zesto is aimed to single core simulations, but it can also simulate multi-cores but it is limited to multiprogrammed workloads.

Another multi-core simulator based in SimpleScalar is SlackSim [58]. Slack- Sim, apart from extending Simplescalar to simulate multiple cores, it also par-

2.5. Chip Multiprocessor Simulators Chapter 2. Background allelizes simulation. It allows multiple cores to run in parallel but preventing them to be ahead of other threads by more than a given number of cycles (slack). By adjusting this slack appropriately they minimize timing violations (see Sec- tion 2.4). They also incorporate a mechanism to periodically save the machine state (checkpoint), and backtrack simulation to the lastest checkpoint in case of a timing violation [59]. This mechanism is not new though, as it was already proposed in 1982 with the name of Time Warp [99].

2.5.2

Simics and Derivatives

Simics [114] is a full-system functional simulator, thus execution-driven, that supports a large variety of ISAs. Its main target is to work as a virtual platform for software development. However, it has the option to run having a notion of timing and, in this mode, it allows to plug timing models.

Simics was introduced in the early 2000s and became a popular alternative for carrying out full-system simulation. Simics models all the necessary devices to run unmodified versions of a large variety of operating systems including Linux, Windows, MS-DOS and Solaris. This eased the work of researchers that just had to use Simics together with their custom timing models to perform their experiments [1, 22, 40, 60].

A timing model for Simics that has been widely used is GEMS [116]. GEMS includes a SPARC core pipeline model called Opal, and a cache hierarchy, in- terconnection network and memory model called Ruby. Simulations can be per- formed with Ruby only or with Ruby and Opal together. Ruby supports several cache coherence protocols, including broadcast-, token- [115], and directory- based versions of MSI, MESI or MOESI. The Opal model is very detailed and this results in accurate but slow simulations. As shown later in Chapter 4, adding the Opal core modeling over Ruby makes simulation an order of magni- tude slower.

Another timing model for Simics is Flexus [91]. Flexus is interesting because it implements the TurboSMARTS [175] sampling technique explained in Sec- tion 2.4.4. As explained before, this sampling technique consists in simulating only some statistically representative parts of a benchmark to reduce simulation time. To do this, they save the machine state (checkpoint) before each represen- tative chunk of the benchmark. To save all the required checkpoints fast, they do it using functional simulation. Then, for detailed simulation, they restore the machine state at the beginning of a representative sample and then perform detailed simulation from there and until the end of the sample. They repeat the process for all samples.

Both GEMS and Flexus are mainly used for simulating multi-cores, but their detailed slow operation generally limits simulation to 32 and 16 cores respectively.

2.5.3

M5/gem5

M5 [34] is a full-system execution-driven simulator initially targeted to network- ing workloads. For this purpose, M5 allows the simulation of multiple machines and run client/server applications to analyze the performance of network pro- tocols and interconnects with a focus on hardware/software co-design.

M5 is open-source and that made it attractive as an alternative to Simics, which is a commercial product. That is the case that, in 2009, it started the merge of GEMS and M5, giving birth in 2011 to the gem5 simulator [33]. Since then, GEMS (for Simics) is discontinued and the efforts of the GEMS team are focused on gem5. With this merge, researchers have not only the M5 cores, caches and interconnects models, but also Opal and Ruby from GEMS available for simulation with gem5.

gem5 supports Linux for the Alpha, ARM and x86 ISAs, and Solaris for the SPARC ISA. This has attracted several companies, such as AMD and ARM, to benefit from full-system simulation which is necessary for the analysis of OS-intensive applications. It has also attracted researchers to use it for their experiments, to integrate it with other existing simulation platforms [93], or to assess its accuracy [45].

2.5.4

Graphite

Graphite [121, 120] is a parallel simulator that uses PIN [113], a dynamic- binary instrumentator, for functional simulation. It models a tiled multi-core architecture and is able to simulate each tile on a separate host thread. It is also able to spread the simulation over multiple host machines.

To avoid the overhead of synchronization on every access to shared resources out of a tile, namely the interconnection network, it uses lax synchronization. It does not synchronize on every access out of the tile, but only on those where the receiver is behind the sender, that is the receiver does not process the message until it is at the same time stamp as when the message was sent. However, if the receiver is ahead of the sender, that is it receives a message in the past, it just processes the message and assumes the error. It also allows to synchronize on application synchronization operations such as barriers and point-to-point synchronizations. With lax synchronization, they get better speedup at the expense of accuracy. They report a 4x speedup by using 80 cores (10 host machines).

Sniper [52] is an extension to Graphite that replaces the core model by an analytical model called interval simulation [83]. It also employs sampling, is integrated with the McPAT power model [110] and provides visualization support.

2.5.5

TPTS - Filtered Traces

TPTS (Two-Phase Trade-driven Simulation) [108] is a trace-driven simulator that includes techniques to model the performance of an out-of-order superscalar core using memory access traces. For this purpose, it generates memory access traces using Simplescalar and embeds for each memory access the number of cycles and instructions to the previous memory access and the dependencies with previous memory accesses. It uses the number of cycles to issue the memory access and the number of instructions to manage the size of the reorder buffer. Then, only memory accesses that are in the reorder buffer, considering the number of non-memory instructions in between accesses, are issued to memory if they do not have dependencies with pending memory accesses. This model is called reorder buffer occupancy analysis (ROA) [109] and assumes that the reorder buffer is the performance limiting factor of the processor core. This

2.5. Chip Multiprocessor Simulators Chapter 2. Background assumption is based on the analysis of the performance of superscalar processors in a previous work [102].

The main purpose of TPTS is to explore cache hierarchy and main memory configurations while assuming the same core configuration as in the Simplescalar trace generation run.

They also extend their experiments to multithreaded applications. In this case, they assume statically-scheduled applications and synchronize threads on lock and barrier operations as explained in Section 2.3.

Another interesting feature of this work is that they employ stripped memory access traces [138]. They propose several ways to deal with the inaccuracies of using stripped memory access traces for multithreaded applications, but do not evaluate them in their work. We cover the concept of using stripped memory access traces for multithreaded applications and propose a technique to improve its accuracy in Chapter 5.

2.5.6

Others

MPSim [13] is an extension to the SMTSim single-core simulator [165] that adds the simulation of multiple cores and uses a trace-driven front-end for multi- programmed workloads. It has been used to simulate the Alpha and PowerPC ISAs. MPsim has been used as the multi-core simulator in a multi-scale sim- ulation methodology for the simulation of large HPC applications running in supercomputers [89]. This methodology is validated against the MareNostrum supercomputer [3] showing an error within 33% for MPsim dual-core simulations of complex HPC applications.

PTLsim [181] is a full-system execution-driven simulator for the x86 ISA. It became popular because it was the only open-source x86 full-system simulator at the time of its release in 2006. It gets full-system support by integrating the Xen virtual machine monitor [26] and provides in-order and out-of-order core models. The accuracy of PTLsim was assessed against a real AMD K8 core showing an error withing 5% for the rsync application [181].

MARSS [133] is an extension of PTLsim to use QEMU [76] as the front-end for full-system simulation instead of Xen.

COTSon [18] is a full-system execution-driven simulator that uses the AMD SimNow emulator [28] as a front-end. It has shown a case to simulate 1000 cores by parallelizing simulation [122].

Turandot [125, 127] is a trace-driven multi-core simulator modeling a multi- core resembling the IBM POWER4. Turandot was validated [126] and shown to have a deviation within 5% for SPECint95. It provides a detailed power model [42] and it has also been parallelized [66]. In the parallel implementation, multiple simulated cores run on separate threads and synchronize on accesses to the shared L2 cache. It is reported to have a 1.5x speedup running on three threads. In this same work, they extend Simplescalar for simulating multiple cores and parallelize it using the same strategy.

CMP$im [97, 98] is a cache hierarchy and memory system simulator using PIN for functional simulation. Its focus is on memory behavior analysis of multi- cores running single-threaded, multithreaded or multiprogrammed workloads.

SESC [145] is an execution-driven simulator that uses MINT [168], a MIPS emulator, for functional simulation. It models an out-of-order core, caches and

interconnection network. It is claimed to be simple and fast (1.5 MIPS), and this has made many researchers to adopt it for their experiments.