< Back

Progress to Date

In our proposal, we hoped to have an initial implementation of CADSS modified with a directory-based cache coherence protocol complete by the milestone. So far, we have spent a substantial amount of time understanding and mapping out CADSS, planning necessary modifications, and thinking about the level of simulation depth we need from the cache and interconnect components. In the current state, we have implemented two changes to swap the simulator to directory-based coherence: (1) modifying the coherence network from a bus to one with point-to-point capabilities, and (2) modifying the existing MI protocol to an MSI one that allows shared reads. These two components have been implemented separately, but have not been merged together and are still being tested and refined. A further complication is the development being in C; we expected to be able to work in C++, but mixing languages has been more difficult than anticipated, and we are also experimenting on this front.

Goals and Deliverables Update

Our target goals and deliverables remain similar, and the list from the proposal still holds. We still hope to show speedup graphs from our predictor simulations as our key result - in this case our speedups would be relative to the snooping bus implementations provided by the simulators, as well as speedups for coherence predictor at different prediction accuracies over a regular directory.  We also hope to supplement these with analysis of which application characteristics are most amenable to speedup from directory. We believe we will be able to meet these goals barring significant roadblocks.

Additionally, we have discovered that the base CADSS simulator simplifies and abstracts systems to a greater degree than we expected. As such, we will also analyze our results from the perspective of simulation fidelity, since some benefits we hope to observe may only be observable under a higher resolution simulation. For example, we plan to start with the simpleCache for which source code is provided, keeping in mind that this implementation has infinite capacity. Since the simple processor in the simulator does not model latency on non-memory actions, all our workloads will be severely backend-bound, which may be a good thing in some cases as it brings memory performance to the forefront, but it may be bad because it anulls latency-hiding mechanisms that interleave memory with compute.

We do not have preliminary results at this time, as per our plan, simulator development is a prerequisite and is also the 75% progress point we have yet to meet.

Points of Concern

• C++ conversion. Both members of our group are more familiar with C++ than C, and feel that shifting development to C++ would greatly boost productivity. The frequent use of function pointers and global variables in the simulator is causing issues for our attempts and converting certain modules to C++. We put in some legwork in moving code into C++ but while we were able to move simple, bespoke functions into C++, this inevitably lead to errors when moving interface functions that other modules called (which would benefit most from C-> C++ conversion). As of now we have decided to develop in C so as to ensure forward progress.

• Cache implementation. We are provided source code for the basic and simple caches, but these may be too simplistic for us to observe benefits of an owner predictor given the lack of capacity. We also have the shared binary for a more sophisticated reference cache, but without the source code, we may run into development/verification difficulties. Modifying or developing a cache implementation is somewhat out of scope for our project, so we chose to stick with the provided simplecache and reason about the performance numbers we see from it.

• Latency simulation and measuring. Latency is the key metric we will be measuring for results, but we don’t have a clear idea of how we will handle it in the simulator. We are still deliberating as to which latencies matter and which should be simulated, and the outcome will greatly affect our results. Right now the primary latencies we are looking at are directory lookup latencies, cache<->directory latencies and cache<->transfer latency.