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.

One 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.

Checkpoint restore also works on gem5's syscall emulation. I had never used it in that case, since there is no boot to skip, but some people have to skip initialization outside of the region of interest.

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 and continues simulation
• -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

Both of those very likely use the exact same internal implementation, except that the checkpoint method has to serialize and serialize state to/from disk.

Of the two 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

Syscall emulation can actually be seen as an alternative fastforwarding approach, as it always dispenses boot, and I've measured a runtime gain of about 2x speed for it at one point with Dhrystone, the downside being that the system is less representative and you have to implement any possibly missing syscalls yourself: https://stackoverflow.com/questions/48986597/when-to-use-full-system-fs-vs-syscall-emulation-se-with-userland-programs-in-gem

For the actual details of which hardware parameters can be modified or not across a restore see: https://stackoverflow.com/questions/60876259/which-system-characteristics-such-as-number-of-cores-of-cache-configurations-can/60876260#60876260

One question that then comes up, is: how can I set different parameters to the program after each restore, if the checkpoint restore restore memory state exactly to what it was? This tutorial covers several possibilities: https://cirosantilli.com/linux-kernel-module-cheat/#gem5-restore-new-script

• mount host filesystems on guest (9P, NFS)
• use a second disk image (you must mount it after the restore however, since the Linux kernel sets up memory data structures): https://stackoverflow.com/questions/50862906/how-to-attach-multiple-disk-images-in-a-simulation-with-gem5-fs-py/51037661#51037661
• magic guest instructions/addresses that read host stuff, e.g. m5 readfile and m5 initparam, more details: https://cirosantilli.com/linux-kernel-module-cheat/#m5ops-instructions

The information above valid as of gem5 2235168b72537535d74c645a70a85479801e0651, February 2020.