Paper Title: WaveScalar
Problem:
- Processor scalability
- Communication overhead
- Dataflow locality
- [Discussion point] Does O3 execution model destroys dataflow locality?
- [Possible answer] Not efficient to extract dataflow locality but not destroying it
- Clock speed
- Complexity
- Limitations of von Neumann architecture
- Basic components: instructions, memory, program counter (PC), CPU
- Problem defined by authors:
- Instruction fetching: sequential nature of von Neumann architecture
- [Discussion point] Is this really as bad as authors stated?
- Memory interface: load-store ordering should be guaranteed
- [Discussion point] Can relaxed consistency models solve this problem?
Intended users:
- Users who are wants high performance of single thread over scalability
- Programmers who are used to the semantics of von Neumann languages (more than binary compatibility)
- Designers, general users, etc.
Unique solutions:
- Supporting von Neumann programming semantics on a dataflow machine
- Distributed memory management
- Minimizing communication overhead
- ISA design
Mechanisms:
- Dataflow
- Instructions fire when operands are ready
- Unify data dependency and control dependency
- Branches
- φ: predication (conditional selector)
- Tradeoff: parallelism vs. energy efficiency (one path will be discarded)
- φ−1: traditional branch (conditional split)
- φ: predication (conditional selector)
- Waves
- Single entrance and multiple exits
- [Discussion point] difference between hyper-block and waves?
- [Discussion point] super-block vs. hyper-block?
- Wave number
- Required to distinguish between different instances of same instruction
- [Discussion point] How would the proposed scheme support nested loops?
- Memory ordering
- Total load/store ordering
- [Discussion point] To support such memory ordering, it will still be centralized at the memory controller side. However, authors’ goal is to build a completely decentralized dataflow processor that eliminates all the large hardware structures that make superscalars non-scalable. There is a discrepancy between what they aim and what they end up with.
- WaveCache
- No coherence among L1 caches
- [Discussion point] In the experiment, the authors assume perfect L1 data caches. It this a valid assumption? If not, why?
- Intra-cluster communication: shared bus
- Inter-cluster communication: routers and routing algorithm
- [Discussion point] Not evaluated but mentioned that not many memory requests left their clusters
- Static mapping
- [Discussion point] Not evaluated about the mapping
- Miss handling: input queue could be non-empty. Some idle instructions should be evicted.
- No coherence among L1 caches
Evaluation:
- Fairness issue
- To make the comparison between the WaveCache and the superscalar fair, what kind of things did the authors consider?
- [Discussion point] If we add cost and area constraints to make the comparison fair, will these be reasonable constraints?
- Performance metric: AIPC
- [Discussion point] Why does this metric make sense? And why not execution time?
Methodology
- Configuration, what metrics to use to quantify fairness of comparison
- Die size, silicon cost
- Design effort
- Metrics
- cluster size. inter-cluster communication overhead is 1 cycle/hop, fair or not?
- no coherence protocol overhead discussed
- private cache in each cluster introduces coherence problem
- control flow handle register not memory
- static instruction overhead
- source: wave-advance, memory ordering
- no branch prediction, not mention misprediction
- workloads benefit from wavescalar: scientific workloads
- instruction mapping: static mapping, LRU replacement
Is evaluation convincing?
- miss several points (memory, coherence traffic)
- Confirmation biased
Reason to choose this paper
- Dataflow. Appealing. Benefit in certain situation, abundant parallelism
- WaveScalar.
- Pretend to obey von Neumann semantic
- Shortcut benefits (binary translation instead of design new compiler)
- How to compare different ISA? IPC (throughput)
- General purpose: good at operating OS, handle exception, takes any code and run well consistently
