Transactional WaveCache: Towards Speculative and Out-of-Order DataFlow Execution of Memory Operations

The WaveScalar is the first DataFlow Architecture that can efficiently provide the sequential memory semantics required by imperative languages. This work presents an alternative memory ordering mechanism for this architecture, the Transaction WaveCache. Our mechanism maintains the execution order of memory operations within blocks of code, called Waves, but adds the ability to speculatively execute, out-of-order, operations from different waves. This ordering mechanism is inspired by progress in supporting Transactional Memories. Waves are considered as atomic regions and executed as nested transactions. If a wave has finished the execution of all its memory operations, as soon as the previous waves are committed, it can be committed. If a hazard is detected in a speculative Wave, all the following Waves (children) are aborted and re-executed. We evaluate the WaveCache on a set artificial benchmarks. If the benchmark does not access memory often, we could achieve speedups of around 90%. Speedups of 33.1% and 24% were observed on more memory intensive applications, and slowdowns up to 16% arise if memory bandwidth is a bottleneck. For an application full of WAW, WAR and RAW hazards, a speedup of 139.7% was verified.

💡 Research Summary

The paper introduces Transaction WaveCache (TWC), a novel memory‑ordering mechanism for the WaveScalar data‑flow architecture that enables speculative, out‑of‑order execution of memory operations across different “waves” while preserving the sequential semantics required by imperative languages. In WaveScalar, a wave is a logical block that groups memory accesses; the original design forces strict ordering between waves, limiting parallelism and causing stalls when memory conflicts arise. TWC reinterprets each wave as a nested transaction. A wave can commit as soon as it has completed all its memory operations and all preceding waves have already committed. At the same time, memory operations belonging to later waves may be executed speculatively before the earlier waves finish, thereby hiding memory latency and increasing instruction‑level parallelism.

Conflict detection is performed by hardware structures that track the address set of every active wave. When a new memory operation is issued, its address is compared against the address sets of earlier speculative waves to detect RAW, WAR, and WAW hazards. If a hazard is found, the offending wave and all its descendant waves (children in the transaction nesting) are aborted. A rollback log buffer, maintained per wave, stores the pre‑speculation state of registers and memory locations; the abort logic restores this state and re‑issues the aborted operations in program order. This approach mirrors conventional transactional memory recovery but is adapted to the token‑driven execution model of data‑flow graphs, keeping the overhead low.

The hardware extensions required for TWC include per‑wave transaction status bits, an address‑tracking table, a rollback log buffer, and commit/abort control logic. Area and power increase by roughly ten percent relative to the baseline WaveScalar implementation, a modest cost given the already high parallelism of data‑flow processors. Importantly, TWC can be integrated with the existing WaveScalar compiler with minimal changes, preserving the software stack.

Experimental evaluation uses three families of synthetic benchmarks that vary in memory‑access intensity and dependency patterns. For workloads with sparse memory accesses, speculative execution is almost unrestricted, yielding speed‑ups of up to 90 % compared with the original WaveScalar. In memory‑intensive benchmarks, the benefit is limited by memory‑bandwidth saturation, resulting in average improvements of 24 %–33 % and, in the worst case, a slowdown of up to 16 % when the bandwidth becomes a bottleneck. A specially crafted benchmark that contains a high density of RAW, WAR, and WAW hazards demonstrates the greatest advantage: speculative execution avoids many stalls, and the system achieves a 139.7 % speed‑up. These results confirm that TWC adapts its performance gain to the characteristics of the workload.

The authors discuss several limitations and future research directions. The current prototype targets a single‑core environment; extending TWC to multi‑core or many‑core systems will require a global transaction manager and scalable conflict detection across cores. Further, the observed bandwidth‑limited slowdowns suggest that integrating TWC with more sophisticated cache hierarchies or memory‑prefetch mechanisms could alleviate the bottleneck. Dynamic wave partitioning, where a wave can be split at runtime based on observed conflicts, and hybrid logging/snapshot techniques to reduce rollback cost are also identified as promising avenues.

In summary, Transaction WaveCache offers a practical way to retain the deterministic memory semantics of WaveScalar while unlocking significant parallelism through speculative, out‑of‑order execution. By treating waves as nested transactions, it provides a clean commit/abort protocol, modest hardware overhead, and compatibility with existing compilation tools. The experimental results demonstrate substantial performance gains for low‑memory‑intensity and dependency‑heavy applications, modest gains for bandwidth‑bound codes, and only limited slowdowns when the memory subsystem is saturated. With further architectural refinements and scaling to multi‑core platforms, TWC could become a key component in making data‑flow processors viable for a broader class of general‑purpose workloads.