Championship Rules
Championship Rules
Every participant should keep the following rules in mind while implementing their proposal:
Participants are free to implement up to one prefetcher at each cache level of L1 data (L1D), L2, and LLC.
To implement a prefetcher, please follow the same guidelines of ChampSim. For a fair comparison, participants are asked to define only the necessary prefetcher functions for implementing their prefetcher, without changing the rest of the simulator code.
All submissions will be compiled against a fresh copy of ChampSim to bar any unwanted changes to the simulator code apart from the prefetcher functions.
The prefetcher implemented at L1D, L2, and LLC should not exceed the storage budget of 32 KB, 128 KB, and 256 KB, respectively. The accompanying paper of every submission must have a section that mentions how does the submission conform the storage budget.
Quantitatively assessing the complexity of a prefetcher is difficult. To simplify the evaluation process, maximize transparency, and minimize the role of subjectivity in selecting a champion, prefetcher complexity will not be factored into the process of ranking contestants.
Every submission will be evaluated using the following methodology:
Each submission will be evaluated using three processor configurations that differ only in the number of cores, size of shared structures (e.g., LLC capacity), and the main memory bandwidth.
For single-core configurations, each submission will be warmed up for 50 million (M) instructions and evaluated for the next 200M instructions.
For multi-core configuration, each submission will be warmed up until all cores have finished at least 20M instructions and then evaluated untill all cores have finished at least 50M instructions.
A single set of prefetcher parameters will be used across all three processor configurations. Unlike previous championships that provided static knobs (e.g., low_bandwidth) to identify configurations, this championship introduces newly-defined API function(s) to expose various system-level feedback information (e.g., dynamic main memory bandwidth usage). Participants may use such APIs to dynamically adapt their prefetcher across changing configuration.
Every submission will get a score for each processor configuration, which would be measured as the speedup provided by the submission in that configuration over the baseline.* The overall score of a submission would be calculated as a weighted mean of individual scores from each configuration. The scoring is mentioned further below.
* Note that, the baseline already contains two prefetchers as mentioned here. For a fair comparison, the prefetchers used in the baseline also employ a single set of parameters and dynamically adapt across configurations only using the provided APIs.
Step 1: Measure speedup (i.e., the ratio of IPC with submitted prefetcher and IPC of baseline) in each trace
Step 2: Final score = non-weighted geometric mean of speedups in all traces
Step 1: For each trace mix, measure Harmonic Speedup (HS) [1, 2] with the submitted prefetchers and in the baseline.
Step 2: For each workload mix, compute the speedup provided by the prefetchers as the ratio of HS-with-prefetchers/HS-baseline.
Step 3: Final score = non-weighted geometric mean of speedups in all trace mixes
The overall score would be the non-weighted geometric mean of all three scores.
[1] Ebrahimi et al., "Coordinated Control of Multiple Prefetchers in Multi-Core Systems", in MICRO, 2009
[2] Ebrahimi et al., "Prefetch-Aware Shared-Resource Management for Multi-Core Systems", in ISCA, 2011
In the interest of assembling a quality program for workshop attendees and future readers, all submissions will go through an overall selection process, of which performance score would be the primary component. To be considered, a submission must conform to the rules described above. A submission will be selected to appear in the workshop on the basis of the performance scores, novelty, practicality of the predictor, overall quality of the paper, and commented code. Note that, novelty is not a strict requirement for selection. For example, a contestant may submit their previously published design or make incremental enhancements to a previously proposed design.