Analyzing CPU and Memory Trade-offs Using gem5

Project Motivation

This project was created as part of CSE 530: Computer Architecture at Pennsylvania State University. The goal was to:

1. Learn gem5: Understand how to use a production-grade architecture simulator
2. Design empirical experiments: Learn to structure a rigorous, reproducible evaluation
3. Understand trade-offs: Quantify the impact of CPU complexity, clock frequency, and memory bandwidth on application performance
4. Practice measurement: Extract meaningful metrics from architectural simulation and present findings clearly

The Quicksort algorithm was chosen because it:

• Is a well-known, classic algorithm with predictable characteristics
• Has moderate working-set size (80,000 integers ≈ 320 KB)
• Exhibits both CPU-intensive and memory-bound phases
• Allows controlled repeated execution (100 runs) for statistical stability

Background Concepts

What is gem5?

gem5 is an open-source, modular architectural simulator developed and maintained by computer architecture researchers and industry practitioners. It allows detailed cycle-level simulation of modern processors without building physical hardware.

CPU Models Tested

Memory Hierarchies

Modern systems use multi-level caches to bridge the speed gap between CPU and main memory.

DRAM Types Tested

Experimental Design

Research Questions

This project answers:

1. How does clock frequency affect performance? Does doubling the clock speed yield 2× speedup?
2. How sensitive is Quicksort to memory bandwidth? Does a faster DRAM significantly reduce execution time?
3. Does CPU pipeline complexity matter? How different are Minor vs. TimingSimple for this workload?
4. Can we achieve linear scaling? Or do bottlenecks (cache misses, memory latency) prevent ideal speedup?

Experimental Matrix

Implementation Details

Quicksort Workload

The benchmark uses a classic in-place Quicksort implementation:

void Quicksort(int a[], int l, int r) {
    /* Partition around pivot a[(l+r)/2] */
    int i = l, j = r;
    int x = a[(l+r) / 2];
    
    do {
        while (a[i] < x) i++;       /* Scan from left */
        while (x < a[j]) j--;       /* Scan from right */
        if (i <= j) {
            /* Swap */
            int w = a[i];
            a[i] = a[j];
            a[j] = w;
            i++; j--;
        }
    } while (i <= j);
    
    /* Recurse on partitions */
    if (l < j) Quicksort(a, l, j);
    if (i < r) Quicksort(a, i, r);
}

Instrumentation with m5ops

The benchmark uses gem5 m5ops for precise measurement:

#ifdef FRMWRK
#include "gem5/m5ops.h"

int main(int argc, char *argv[]) {
    m5_reset_stats(0, 0);           /* Start counters */
    
    for (int i = 0; i < 100; i++) 
        Quick(i);                   /* 100 iterations */
    
    m5_dump_stats(0, 0);            /* Dump counters */
}
#endif

Results & Analysis

X86MinorCPU Performance

X86TimingSimpleCPU Performance

Key Findings

simCycles_at_1.0_GHz  ≈ 12.7 × 10⁹ cycles
simCycles_at_2.0_GHz  ≈ 12.7 × 10⁹ cycles

Lessons & Insights

Reproducibility & Extensibility

How to Reproduce

Build & Run Example

# Step 1: Navigate to a simulation directory
cd quicksort/X86MinorCPU/DDR3_1600_8x8/1.2GHz

# Step 2: Compile quicksort with gem5 m5ops
make all

# Step 3: Run gem5 simulation
/path/to/gem5/build/X86/gem5.opt \
  /path/to/gem5/configs/example/se.py \
  --cmd=./a.out --options="100 100" \
  --cpu-type=X86MinorCPU \
  --caches --l2cache \
  --l1d_size=32768 --l1i_size=32768 \
  --l2_size=262144 \
  --cpu-clock="1.2GHz" \
  --mem-type=DDR3_1600_8x8

# Step 4: Extract results
grep "^simSeconds" m5out/stats.txt
grep "^system.cpu.numCycles" m5out/stats.txt

How to Extend

The experiment framework is easily extensible:

Conclusion

This project demonstrates a principled approach to computer architecture evaluation using simulation. By carefully designing an experiment, implementing a representative workload, and interpreting results through the lens of architectural understanding, we gained actionable insights:

• Clock frequency remains a powerful performance lever for well-designed systems
• Memory bandwidth matters less than cache design for workloads with good locality
• CPU pipeline complexity isn't always necessary—simpler designs suffice when memory isn't the bottleneck

These findings, while demonstrated on Quicksort in gem5, transfer to broader systems and inform real architectural decisions made by researchers and industry practitioners every day.