Difference between revisions of "Multi-programmed workloads"
(Created page with "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 e...") |
|||
Line 10: | Line 10: | ||
<code>./sift/siftdump fft.sift | less</code> | <code>./sift/siftdump fft.sift | less</code> | ||
+ | |||
+ | |||
+ | === SimPoints === | ||
+ | |||
+ | Using the <code>-b</code> (block size) parameter of <code>record-trace</code>, 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: | ||
+ | |||
+ | <code>~/sniper$ ./record-trace -o fft -b 1000000 -- test/fft/fft -p1 -m20</code> | ||
+ | |||
+ | 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 <code>run-sniper</code> 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 <code>--traces=</code> 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): | ||
+ | |||
+ | <code>./run-sniper -c gainestown -n 2 --traces=swim.sift,gcc.sift,swim.sift,equake.sift</code> | ||
+ | |||
+ | The simulation will end as soon as ''one'' of the trace files completes. |
Revision as of 06:58, 6 March 2012
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
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.