The problem

1
Introduction

• The problem
• Handling memory dependencies in out-of-order
  and/or parallel execution
• Need to minimize recovery penalties from memory
  order violations while also minimizing needless
  stalls from false dependencies

2
Introduction

• Approaches
• Opportunistic (naïve speculation)
• Actually no speculation
• Ok for common case
• Ignores problem
• Causes memory order violations
• Forces performance penalties due to recovery
• Conservative (no speculation)
• Stalls all loads until all prior stores complete
• Eliminates memory order violations
• Creates false dependencies and needless stalls
• Memory Dependence Prediction

3
Store Sets

• Definition of a store set
• A store set contains the unique list of stores on
  which a load has ever depended during the
  execution of a program.
• If these stores are pending execution, the load
  must wait.
• However, if none of the stores on which the load
  depends is outstanding, the load may proceed
  without stalling
• Configurations
• Single A store can only reside in a single
  store set.
• Multiple A store can reside in multiple store
  sets, but only a one store can be present in a
  loads store set.
• Infinite No restrictions store sets have
  numerous stores and a store can reside in any
  store set.

4
Data Structures Used for Implementation
Store Set ID Table (SSIT)
Last Fetched Store Table (LFST)
Load/Store PC
Index
Store Inum
SSID
From Chrysos and Emers Memory Dependence
Prediction using Store Sets
5
Simulation Environment

• SimpleScalar Default Configuration
• Memory Disambiguation in SimpleScalar
• Conservative no speculation
• Opportunistic naïve speculation
• Perfect perfectly speculates every time
• Problems with SimpleScalar
• Default Configuration no load squashes
• Modified Configuration load squashes in
  conservative and perfect settings

6
Benchmarks

• Anagram, gcc, go
• Easy to work with
• gcc and go used in Chrysos and Emers paper
• Tested against six disambiguation schemes
• conservative, opportunistic, perfect
• single, multiple, and infinite store sets

7
Performance

• Two metrics of performance IPC and load
  squashes
• Load squashes equivalent to memory violations,
  tell us how well our disambiguation scheme is
  functioning
• IPC tell us how the load squashes affect the
  program execution

8
Charts
9
Charts
 
Figure 2 Load Squashes
10
Analysis

• Problems with SimpleScalar
• Load squashes in default conservative and
  perfect modes shouldnt happen
• Perfect mode matches opportunistic mode
• Our goal minimize the load squashes present in
  the opportunistic mode
• Not many load squashes to begin with

11
Analysis

• Functions correctly a good thing
• No large slowdowns (except for multiple
  configuration) another good thing
• No large speedups either
• gcc single configuration fewer load squashes
  leads to increased IPC
• Multiple configuration loads in these
  benchmarks depend on more than just one store

12
Conclusion

• Unable to emulate results produced by Chrysos and
  Emer
• Benchmarks used did not have enough memory order
  violations present
• Bugs within Sim-R10K code