What does “fast-forwarding” mean in the context of CPU simulation?

Question

I'm using a simulator for my thesis and I've come across the term "Fast-forwarding" but I have found no definition anywhere in the documentation or online. From a pdf I've been reading about the simulator I am using (gem5), I've come across this section:

The gem5 simulator supports four different CPU models: AtomicSimple, TimingSimple, InOrder, and O3. AtomicSimple and TimingSimple are non-pipelined CPU models that attempt to fetch, decode, execute and commit a single instruction on every cycle. The AtomicSimple CPU is a minimal, single IPC CPU which completes all memory accesses immediately. This low overhead makes AtomicSimple a good choice for simulation tasks such as fast-forwarding. Correspondingly, the TimingSimple CPU also only allows one outstanding memory request at a time, but the CPU does model the timing of memory accesses.

Does anyone know what this term actually means?

Answer 1

Fast forwarding is used to warm-up microarchitectural state (caches, branch predictors, etc.) in preparation for more accurate simulation of a particular section of interest within an application. Since microarchitectural state can depend on operation ordering (e.g., cache replacement for data accesses and interactions between threads), speculation (e.g., instruction caching behavior), and even timing (e.g., thermal behavior), this is not a perfectly accurate warm-up, but "all models are wrong".

Answer 2

Here I will complement the perfectly correct information that Paul gave with more gem5 specifics.

The major use case for fast-forwarding is when you have to boot Linux/Android and only then run your content.

The boot could take a very long time compared to your content, and so it is very important to find a way to not run it for every experiment, since you usually need to run several versions of an executable with several different input parameters.

The solution is to first run content on a less detailed CPU (e.g. the default AtomicSimpleCPU) and then just before you start running the executable, you switch to a more detailed CPU, e.g. DerivO3CPU, which is about 5x slower to execute).

gem5 fs.py provides two ways to do this:

• --fast-forward <time> option: runs up to a given time cycles on the first (faster) CPU then switches
• -r + m5 checkpoint: you instrument the guest, run boot with the fast CPU, take a checkpoint from instrumentation after init, and then restore after boot with the slower CPU

Of the two above approaches, checkpoint restore is much more convenient because:

• you can restore multiple times with different parameters without re-running the boot on the fast CPU
• it is hard to know the right clock time to switch in the first place

Checkpoint restore also works on syscall emulation, although it is not as commonly used in that case, since then you don't have any boot to skip.

Information above valid as of gem5 2235168b72537535d74c645a70a85479801e0651, February 2020.