Frequently Asked Questions
Q: How can I configure core frequencies/DVFS in Sniper?
A: There are a number of ways to configure the frequencies of processors in Sniper. The easiest way is to set the default startup frequency for all cores is via the run-sniper parameter -g --perf_model/core/frequency=1.0. If you would like to control the per-core frequencies, first define a set of frequency domains (one per core) with -g --dvfs/type=simple -g --dvfs/simple/cores_per_socket=1. Then, in the application itself, you can call either SimSetFreqMHz(core_id, int_freq_in_mhz) or SimSetOwnFreqMHz(int_freq_in_mhz) (these SimAPI calls are defined in sniper/include/sim_api.h). If modification of the application is not possible, or you would like to define the per-core frequency at runtime, you can use the dvfs.py script. An example might look like the following:
user@host:~/sniper/test/fft$ ../../run-sniper -n 4 -c gainestown --roi -sdvfs:0,0,1000,0,1,2000,0,2,3000,0,3,4000 \ -g --dvfs/type=simple -g --dvfs/simple/cores_per_socket=1 -- ./fft -p 4
Where the scripting interface is called with -s<script>:<options> and the dvfs.py script accepts parameters in the form of lists of 3-tuples, defined as (ns_time_to_change_freq, core_id, int_freq_in_mhz). The example above will set the first 4 cores to 1, 2, 3 and 4 GHz at the start of ROI.
Q: Why do the cache statistics in Sniper for a particular application not agree with my HW performance counters?
A: There are two major reasons why the cache numbers might be different when compared to hardware. The first reason is how the cache counters collect data in Sniper. The cache access rates should look comparable to real hardware, but the miss rate can in some cases be rather different. The reason for this is that the overlapping misses in Sniper are counted as hits, while on real hardware they would count as cache misses. Internally, Sniper's memory subsystem completes each access, gets the result immediately, and uses a queuing model to determine contention. Therefore, a miss in real hardware would be a hit in Sniper. (The timing in Sniper is still modeled correctly, as the second memory access would be dependent on the first one so it cannot complete before it.) One way to compare the number of L1-D cache misses that we see in Sniper with hardware would be to compare that number to the number of L2-D accesses (made by the same core). The number of L2-D cache accesses would represent the non-overlapped L1-D misses, which is how the statistics in Sniper are counted. The second reason for differences is because there can be a number of hardware structures or hardware limitations that are either unknown to us, or that we do not model completely.
Q: Why does the CPI-stack format that I generate with Sniper differ from the SC11 paper results?
A: We have recently updated the CPI stack format to better reflect system resource contention. See our recent IISWC publication for more details on these changes.
Q: Why does the TLB code in Sniper not perform the way that I expect?
A: Sniper is a user-space simulator, and therefore doesn't model all of the Hardware-Operating System interactions that one might expect to see. This is because the applications that we are targeting, HPC workloads, tend to see very few TLB misses. As an experiment, we looked into modeling the OS effects of TLB misses, but only from the perspective of OS-handled TLB misses. To use this, one would have to set the TLB size to the last-level TLB of the architecture that you are modeling, and set the miss penalty to 100s of cycles to account for the OS penalty. Modeling L1-TLBs is possible but is not currently implemented. Modifications to the memory subsystem to report TLB misses as a part of the load and store access times would be necessary to get this working properly.
Q: What are the license terms for using Sniper?
A: In short, the interval core model is protected under a US patent application. We automatically grant you a free license for using the interval model inside Sniper for academic purposes. For commercial use, please contact Lieven Eeckhout. All other code is licensed under the very liberal MIT license. You can view the full details on our License page.
