系列文章 : [gem5] 從零開始的 gem5 學習筆記

這邊嘗試看看，假如修改硬體參數的話，運行 dhrystone 所輸出的效能數據會有怎麼樣的變化

cache size

在這個實驗裡，同樣使用 minor CPU model，其他參數都不變，只改變 cache size。

• icache size : 1KiB

  • 第一次實驗

    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 126155458
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 19.096452
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime : 6307784
      # how many mtime ticks

  • 第二次實驗

    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 126150854
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 19.095755
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime : 6307758
      # how many mtime ticks
• icache size : 8KiB
  • 第一次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 124066175
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 18.780192
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime : 6203302
      # how many mtime ticks
  • 第二次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 124061045
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 18.779416
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime_low : 6203059
      # how many mtime ticks

總結一下數據

• 從 simInsts 可以看到，兩個不同的硬體設定，都是執行相同的指令數。
• 從 system.cpu.numCycles 可以看到，儘管執行了相同的指令數，比較大的 icache 還是能夠減少總 cycle 數，進而減少 cpi，優化了效能。

CPU model

在這個實驗裡，我們比較 minor CPU 跟 O3 CPU 的效能差異，其他硬體參數都不改變。

• minor CPU model
  • 第一次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 124066175
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 18.780192
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime : 6203302
      # how many mtime ticks
  • 第二次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 124061045
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 18.779416
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime_low : 6203059
      # how many mtime ticks
• O3 CPU model
  • 第一次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 16365196
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 2.477239
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime : 818251
      # how many mtime ticks
  • 第二次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 16361642
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 2.476701
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime : 818082
      # how many mtime ticks

總結一下數據

• 從 simInsts 可以看到，兩個不同的硬體設定，都是執行相同的指令數。
• 從 system.cpu.numCycles 可以看到，儘管執行了相同的指令數，使用 O3 的 CPU 效能有驚人的提升! 儘管實務上，O3 CPU 的面積與耗電也會驚人的提升，性價比在挑選 CPU 時也是很重要的指標。

memory latency

在這個實驗裡，我們比較 memory latency 帶來的效能差異，其他硬體參數都不改變。

• dram latency : 60ns
  • 第一次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 212992717
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 32.241214
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime : 10649626
      # how many mtime ticks
  • 第二次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 212992717
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 32.241214
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime : 10649220
      # how many mtime ticks
• dram latency : 30ns
  • 第一次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 124066175
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 18.780192
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime : 6203302
      # how many mtime ticks
  • 第二次實驗
    • simInsts : 6606225
      # Number of instructions simulated (Count)
    • system.cpu.numCycles : 124061045
      # Number of cpu cycles simulated (Cycle)
    • system.cpu.cpi : 18.779416
      # CPI: cycles per instruction (core level) ((Cycle/Count))
    • use_mtime_low : 6203059
      # how many mtime ticks

總結一下數據

• 從 simInsts 可以看到，兩個不同的硬體設定，都是執行相同的指令數。
• 從 system.cpu.numCycles 可以看到，儘管執行了相同的指令數，不同的 memory latency 也會大幅的影響效能。

總結

利用 gem5 模擬器，我們可以評估說，假如 ( what if ) 我使用不同的硬體參數，所跑出來的效能差異會是如何。會是更好嗎 ? 還是更差 ? 對於這個 workload，某個硬體參數會有多大的影響。

有時候我們可能想知道說，當我們想優化一個 workload，什麼樣的硬體參數是比較重要的因素 ? 可能 cache size 對於該 workload 的影響較大，而 memory latency 較小，這些問題都可以透過 gem5 這樣的 timing model 獲得解答。

而這個解答的可信度，需要基於模擬器是否可以反映出實際硬體的效能，這就需要先對模擬器所產生的效能數據，跟實際硬體進行比對 ( correlation )。

然而就算模擬器沒有跟實際硬體進行效能校準，我們還是能直觀的取得一些資訊，例如說某個 workload 受到 cache size 的影響較大，或是某個 workload 受到 bus memory latency 的影響較大。這時候就有機會影響硬體實作時的決策。

當然太不準的話，可能要挨罵了 XD。花了那麼多時間實作硬體並跑實驗 ( 實作 RTL，一連串痛苦且耗時的 DV 驗證，上板子，bring up 軟體與 benchmark )，結果實際的數據表明 cache size 根本不影響重要的 workload 的效能 !! 你們給我回去優化模擬器 !!