Multi-programmed workloads
Contents
In addition to simulating parallel applications in a Pin-based execution-driven mode, Sniper supports playing back instruction traces. One single-threaded trace can be fed into each simulated core. This allows for the simulation of multi-programmed workloads. Collecting and playing back traces were added in Sniper version 2.0.
Collecting traces
Make sure you have Sniper 2.0 or higher installed and compiled. Then use the record-trace
script to record a dynamic instruction trace of your single-threaded application:
~/sniper$ ./record-trace -o fft -- test/fft/fft -p1
This will create the file fft.sift
. Using the tool sift/siftdump
you can look at its contents:
./sift/siftdump fft.sift | less
If you want to skip a certain number of instructions before starting to record the trace, use the -f
(instructions to fast-forward) switch. Similarly, the -d
(instructions to simulate in detail) switch allows you to stop recording the trace once it contains a given number of instructions.
SimPoints
Using the -b
(block size) parameter of record-trace
, you can split up the instruction trace into multiple files, each a fixed number of instructions long. For example, this command will run the FFT benchmark and create the files fft.0.sift, fft.1.sift, etc; each containing 1 million instructions:
~/sniper$ ./record-trace -o fft -b 1000000 -- test/fft/fft -p1 -m20
Additionally, basic block vectors will be generated for each block in the fft.*.bbv files. These are text files, first line of each is the number of instructions in the block (except for the last block, this number should match the block size parameter), the next lines are the basic block vector components in a scale that runs from 0 to 65535.
Playing back traces
Starting a multi-programmed simulation uses the regular run-sniper
script, which allows you to specify all configuration parameters just like in the Pin-based multi-threaded mode. But rather than specifying the benchmark's command line, you now use the --traces=
option to pass in the trace files to use for each core. Make sure to provision enough simulated cores (at least as many as there are trace files):
./run-sniper -c gainestown -n 2 --traces=swim.sift,gcc.sift,swim.sift,equake.sift
The simulation will end as soon as one of the trace files completes.
Collecting and playing back traces simultaneously
If trace files are taking up too much space, it might be a good alternative to run the applications at the same time you are simulating them. In this scenario, there are no guarantees that the simulator will see the exact same instruction trace for each run.
# Make a pipe for each application cd ~/sniper mknod fft1_pipe.sift p mknod fft2_pipe.sift p # Start recording traces for each application ./record-trace -o fft1_pipe -- ./test/fft/fft -p 1 & ./record-trace -o fft2_pipe -- ./test/fft/fft -p 1 & # Run Sniper, pointing to the instruction trace pipe files ./run-sniper -c gainestown -n 2 --traces=fft1_pipe.sift,fft2_pipe.sift