gem5 Simulation Time faster with caches than without

[Skyfarmer007]

Hi everyone,

I wanted to compare several aspects between a RISC-V Timing CPU with and without caches using embench as evaluation programs. I derived the gem5 configurations from the examples given in the gem5 repository. What I noticed is that the simulation time for the configuration without caches takes considerably longer. Does anyone know why this happens or is there something wrong my configuration?

I attached both scripts to the discussion.
gem5 scripts.zip

[Will-Shaddix]

The memory models are more complex than the cache models, so I believe there's more events to schedule and overall more computation to be done when a request goes to the memory controller instead of being handled by the cache.

[Jagadeesh-pradhani]

The observation you're making about the increased simulation time for a RISC-V Timing CPU without caches is actually expected behavior in gem5. Let me break down why this happens.

Timing CPU Behavior:

1. A TimingSimpleCPU in gem5 models a processor without microarchitectural timing details but with accurate memory timings. This means that while the CPU's internal execution isn't modeled in detail, memory interactions (such as accesses to main memory) are timed and can significantly affect performance.

Cache Impact:

1. With Caches: When caches are present, frequently accessed data can be retrieved from the cache, which is significantly faster than accessing main memory (typically by orders of magnitude). The caches reduce the number of costly accesses to main memory, improving the overall performance and lowering the simulation time.

2. Without Caches: In the absence of caches, every memory access, both instruction fetches and data loads/stores, has to go all the way to main memory. This leads to much higher latency per memory access. Since memory is slower than caches, each memory access will take longer, increasing the simulation time.

Simulation Model Complexity:

1. The TimingSimpleCPU doesn't model pipeline stages and other microarchitectural details. But when caches are removed, the simulation becomes bottlenecked by memory latency because all memory requests take significantly longer to complete.

2. The lack of caching leads to more frequent memory accesses to DRAM, which introduces more delays and drags down the overall simulation speed.

[Skyfarmer007]

Thanks for your quick reply! I also used perf to profile gem5 and confirmed that the additional simulation complexity stems from the DRAM simulation.