Skip to content

Cache size based latency modelling #726

Open

Description

@kushagra0902

Is your feature request related to a problem? Please describe.

ChampSim treats cache size/associativity and cache hit latency independently. Increasing cache size does not affect access latency unless it is manually configured, which may lead to unrealistic comparisons during cache design-space exploration.

Describe the solution you'd like

Add an optional cache latency model that estimates hit latency based on cache parameters such as capacity, associativity, and line size, possibly using a simple model or CACTI integration.

Describe alternatives you've considered

Users can manually calculate cache latencies using tools like CACTI and specify them for each configuration, but this becomes cumbersome for large parameter sweeps.

Additional context

The existing manual latency configuration should remain available. The proposed model would be optional and mainly help make cache-size comparisons more realistic.

Activity

  1. ngober commented on Sep 30, 2026

    @ngober
    Collaborator

    This is an interesting idea, but I doubt going all the way integrating CACTI is the right way to go here. The way that I have done this in the past is to write a script that generates configuration files, then doing my study with each of those configuration files. I think that CACTI could be a driver in that config script.

  2. maccoymerrell commented on Sep 30, 2026

    @maccoymerrell
    Contributor

    inc/cache_builder.h, line ~315, already implements this. Whether I ported this to develop or not, I will need to check. It is rather niche, and supporting it as part of ChampSim vs. a CACTI extension is something we would need to consider.

  3. maccoymerrell commented on Sep 30, 2026

    @maccoymerrell
    Contributor

    It is on develop as well, in the legacy_environment parser.

  4. ngober commented on Sep 30, 2026

    @ngober
    Collaborator

    The size-based defaults were simply my way of trying to reduce the number of things the user is required to specify in the configuration file. It correlated to the latencies that were default at the time, but those latencies were never validated to any silicon. So, for anything rigorous, the user probably needs to specify them anyway. Using an external tool to get that specification is probably the simplest way to go about this.

  5. maccoymerrell commented on Sep 30, 2026

    @maccoymerrell
    Contributor

    I did alter the formula to model the curves I found across 4 different Intel and AMD processors at each of their cache levels. #526

  6. ngober commented on Sep 30, 2026

    @ngober
    Collaborator

    Oh hey, I remember that 🤦 Yea, we did validate them I suppose.

  7. kushagra0902 commented on Sep 30, 2026

    @kushagra0902
    Author

    The size-based defaults were simply my way of trying to reduce the number of things the user is required to specify in the configuration file. It correlated to the latencies that were default at the time, but those latencies were never validated to any silicon. So, for anything rigorous, the user probably needs to specify them anyway. Using an external tool to get that specification is probably the simplest way to go about this.
    That makes sense

  8. kushagra0902 commented on Sep 30, 2026

    @kushagra0902
    Author

    Oh hey, I remember that 🤦 Yea, we did validate them I suppose.

    I will go through the other branches once, I as of now didn't look at them. Thanks a lot, for helping out. Would love to use the tool and help in development too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions