Multi-programmed workloads - Revision history

Tcarlson at 04:12, 10 August 2012

2012-08-10T04:12:27Z

Tcarlson: /* Collecting and playing back traces simultaneously */

2012-05-05T13:02:32Z

Collecting and playing back traces simultaneously

Tcarlson: /* Collecting and playing back traces simultaneously */

2012-05-05T12:59:57Z

Collecting and playing back traces simultaneously

Tcarlson: /* Collecting and playing back traces simultaneously */

2012-05-05T11:41:39Z

Collecting and playing back traces simultaneously

Tcarlson: /* Collecting and playing back traces simultaneously */

2012-05-05T11:40:56Z

Collecting and playing back traces simultaneously

Tcarlson at 11:24, 5 May 2012

2012-05-05T11:24:22Z

Wheirman: /* Collecting traces */

2012-03-27T20:18:56Z

Collecting traces

Wheirman at 14:58, 6 March 2012

2012-03-06T14:58:50Z

Wheirman at 14:58, 6 March 2012

2012-03-06T14:58:17Z

Wheirman: 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..."

2012-03-06T14:49:33Z

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

New page

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 <code>record-trace</code> script to record a dynamic instruction trace of your single-threaded application:

<code>~/sniper$ ./record-trace -o fft -- test/fft/fft -p1</code>

This will create the file <code>fft.sift</code>. Using the tool <code>sift/siftdump</code> you can look at its contents:

<code>./sift/siftdump fft.sift | less</code>

← Older revision		Revision as of 04:12, 10 August 2012
Line 44:		Line 44:
	./run-sniper -c gainestown -n 2 --traces=fft1_pipe.sift,fft2_pipe.sift		./run-sniper -c gainestown -n 2 --traces=fft1_pipe.sift,fft2_pipe.sift
	</pre>		</pre>
		+
		+	== Multiple Multi-threaded workloads ==
		+
		+	It is also possible to run multiple, multi-threaded benchmarks simultaneously. To do that, first you will need to [[Download Benchmarks\|install the integrated benchmarks suite]]. After that, one can use the <code>--benchmarks</code> parameter to indicate which benchmarks and configurations you would like to run. For example, you could run the above example with the following command:
		+	<pre>$BENCHMARKS_ROOT/run-sniper -c gainestown --benchmarks=splash2-fft-small-1,splash2-fft-small-1</pre>There is no limit to the number of threads that can be run when running with the <code>--benchmarks</code> parameter, but note that ROI handling is currently not supported in this mode, even for multi-threaded workloads.

@@ Line 39: / Line 39: @@
 mknod fft2_pipe.sift p
 # Start recording traces for each application
-./record-trace -o fft1_pipe -- ./test/fft/fft -p 1 &
+./record-trace -o fft1_pipe -- ./test/fft/fft -p1 &
-./record-trace -o fft2_pipe -- ./test/fft/fft -p 1 &
+./record-trace -o fft2_pipe -- ./test/fft/fft -p1 &
 # Run Sniper, pointing to the instruction trace pipe files
 ./run-sniper -c gainestown -n 2 --traces=fft1_pipe.sift,fft2_pipe.sift
 </pre>

@@ Line 39: / Line 39: @@
 mknod fft2_pipe.sift p
 # Start recording traces for each application
-./record-trace -o fft1_pipe -- ./test/fft/fft -p &
+./record-trace -o fft1_pipe -- ./test/fft/fft -p 1 &
-./record-trace -o fft2_pipe -- ./test/fft/fft -p &
+./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
 </pre>

@@ Line 42: / Line 42: @@
 ./record-trace -o fft2_pipe -- ./test/fft/fft -p &
 # Run Sniper, pointing to the instruction trace pipe files
-./run-sniper -c gainestown -n 2 --traces=fft1.sift,fft2.sift
+./run-sniper -c gainestown -n 2 --traces=fft1_pipe.sift,fft2_pipe.sift
 </pre>

@@ Line 32: / Line 32: @@
 == 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.
+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.
 <pre>
 # Make a pipe for each application

← Older revision		Revision as of 11:24, 5 May 2012
Line 1:		Line 1:
		+	__TOC__
	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.		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.

Line 28:		Line 29:

	The simulation will end as soon as ''one'' of the trace files completes.		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.
		+	<pre>
		+	# 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 &
		+	./record-trace -o fft2_pipe -- ./test/fft/fft -p &
		+	# Run Sniper, pointing to the instruction trace pipe files
		+	./run-sniper -c gainestown -n 2 --traces=fft1.sift,fft2.sift
		+	</pre>

← Older revision		Revision as of 20:18, 27 March 2012
Line 10:		Line 10:

	<code>./sift/siftdump fft.sift \| less</code>		<code>./sift/siftdump fft.sift \| less</code>
		+
		+	If you want to skip a certain number of instructions before starting to record the trace, use the <code>-f</code> (instructions to fast-forward) switch. Similarly, the <code>-d</code> (instructions to simulate in detail) switch allows you to stop recording the trace once it contains a given number of instructions.

	=== SimPoints ===		=== SimPoints ===

@@ Line 10: / Line 10: @@
 <code>./sift/siftdump fft.sift | less</code>
 === SimPoints ===
@@ Line 19: / Line 18: @@
 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 ==

← Older revision		Revision as of 14:58, 6 March 2012
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.