Downloads
CVP2v2.2 - A trace-based simulator (click to download) : (Second CVP2 release, February 2021)
- Reads instructions from a trace in .gz format directly.
- One instruction from the trace may generate several "pieces" that contestants will have the opportunity to predict.
- The number of pieces depend on the number of 64-bit output values. For instance :
- A vector instruction that writes 128-bit registers will cause two pieces to be generated.
- A scalar instruction that produces two general purpose registers will cause two pieces to be generated.
- A vector instruction that writes 2 128-bit registers will cause four pieces to be generated.
- In general, however, instructions from the trace will only generate a single piece.
- Schedules instructions according to the dataflow as well as structural constraints :
- Configurable window size.
- Configurable superscalar width.
- Configurable number of execution lanes.
- 3-level cache hierarchy with simple stride prefetching.
- Branch direction and target prediction.
- Oracle memory disambiguation.
- Report soverall cycle count.
- See README for more detailed use information.
Currently unavailable, work in progress to rehost, 135 small traces + 2013 large traces :
- 30M/(100M [Sampled workload] 20-600M [Entire workload]) Insts.
- Mix of compute (INT and FP), crypto and server-class
- Temporary backup for small traces, expiring 3/20/21
As all traces from CVP1 are public, ranking will be done using a subset of the 100M traces. However, the particular subset will not be made public until the workshop.
General Rules and Tracks
The championship has three tracks :
- Track 1: Predict all instructions (32KB budget)
- Track 2: Predict load instructions only (32KB budget)
- Track 3: Predict load instructions only with oracle L1/L2/L3 hit/miss feedback (32KB budget)
Competitors can choose not to compete in a particular track. In each track, an additional side buffer of unbounded size is allowed for tracking additional information used by the predictor (e.g., global history). Top submissions will be invited to present at the CVP2 workshop. All source code, write-ups and performance results will be made publicly available through the leaderboard.
Before You Submit
Each submission should include an abstract, write-up (up to 4 pages using a standard double-column template), and predictor code. We should be able to simulate your predictor with a reasonable amount of memory (not exceeding 16GB), and within six hours of simulation time. Predictors:
- Must not violate causality (cannot use future information to predict the current value).
- Are not allowed to spawn another thread from the predictor code.
- Cannot call functions internal to the infrastructure: No header from ./lib may be included.
Lastly, the simulator must be run with default parameters (e.g., issue-width, window size, etc.), although authors are welcome to change the default values for their own experiments. Please see the README.md file for examples on how to run the simulator with VP enabled.
- Please mention the key evaluation result (the Average [geomean] IPC obtained by your predictor over the 135 public traces) in the abstract.
- Please report the storage computations in a dedicated table. Specifically, each predictor structure should have its own line, how many bits are used, and a pointer to code structure that implements this structure. While there is no limit on the size of the side buffer used to track inflight metadata, we also ask that you provide the number of bits required (or at least number of bits per entry). For authors concerned with page-count, this table may be added as appendix.
- In the code, please comment the structures that are used with what the structure corresponds to, how many bits it is using if it counts toward the storage budget, and why not if it does not, as well as a pointer to the line in the table of the write-up corresponding to that structure.
- Please consider adding a permissive licence to your code such that it can be reused by other researchers (some possible licences).
Submissions may be sent back to the contestants after a short write-up and code review if the write-up is not clear enough and/or there are issues with the code (e.g., does not compile, does not run, does not follow the rules).
Submitting Your Predictor
To submit your entry, you will first need to create a tarball named after the first author, using the following instructions.
1. Create a directory with the full name of the first author (say John Smith) and CVP subdirectories: mkdir JohnSmith cd JohnSmith mkdir cvp_all mkdir cvp_loads mkdir cvp_loads_oracle 2. Copy the predictor files mypredictor.h and mypredictor.cc to each relevant directory. For example, to submit to the "all instructions" track, you would have: cvp_all/mypredictor.h cvp_all/mypredictor.cc You are allowed to submit to multiple track within the same tarball. For example to submit to the "only loads" category also, you would take the "only loads" predictor and copy it to cvp_loads directory as cvp_loads/mypredictor.h and cvp_loads/mypredictor.cc 3. Copy your writeup as paper.pdf within the JohnSmith directory. The paper must be written in conference format (double column, 10 point font) with a limit of 4-pages. The paper should clearly describe the organization of the predictor, the working of the predictor, and computation of the storage budget. 4. Create a text file called README.txt within the JohnSmith directory with the following information: 1. Contact author name, institution and email address. 2. Any conflicts authors have with organizers. 3. Which track(s) your submission is targeting. 5. Type "ls" (It should now give you the following) == cvp_all/ cvp_loads/ cvp_loads_oracle/ paper.pdf README.txt == 6. Create the zipped tarball, using the following commands: cd .. tar -cvf JohnSmith.tar JohnSmith/ gzip JohnSmith.tar.gz 7. To submit your entry, send an email to [email protected] (not a typo, we are reusing the address for CVP2) with the following: Author Names (in the order) Tarball (AuthorName.tar.gz)