Data speculation support for a chip multiprocessor

Abstract

Thread-level speculation is a technique that enables parallel execution of sequential applications on a multiprocessor. This paper describes the complete implementation of the support for threadlevel speculation on the Hydra chip multiprocessor (CMP). The support consists of a number of software speculation control handlers and modifications to the shared secondary cache memory system of the CMP. This support is evaluated using five representative integer applications. Our results show that the speculative support is only able to improve performance when there is a substantial amount of medium-grained loop-level parallelism in the application. When the granularity of parallelism is too small or there is little inherent parallelism in the application, the overhead of the software handlers overwhelms any potential performance benefits from speculative-thread parallelism. Overall, thread-level speculation still appears to be a promising approach for expanding the class of applications that can be automatically parallelized, but more hardware intensive implementations for managing speculation control are required to achieve performance improvements on a wide class of integer applications.

A scalable architecture for ordered parallelism

“…Much prior work has investigated thread-level speculation (TLS) schemes to parallelize sequential programs [25,28,60,61,66,69]. TLS schemes ship tasks from function calls or loop iterations to different cores, run them speculatively, and commit them in program order.…”

“…However, it creates complex chains of dependences among speculative tasks. Thus, upon detecting mispeculation, most TLS schemes abort the task that caused the violation and all later speculative tasks [25,28,61,66,68]. TCC [29] and Bulk [11] are the exception: they do not forward data and only abort later readers when the earlier writer commits.…”

“…To address this, we contribute a novel conflict detection scheme based on eager version management that allows both forwarding speculative data and selective aborts of dependent tasks. Commit serialization: Prior TLS schemes enforce inorder commits by passing a token among ready-to-commit tasks [28,61,66,68]. Each task can only commit when it has the token, and passes the token to its immediate successor when it finishes committing.…”

“…By contrast, most TLS systems use lazy versioning (buffering speculative data in caches) or more expensive multiversioning [11,25,28,29,56,60,61,66,68,69] to limit the cost of aborts. Some early TLS schemes are eager [25,80], and they still suffer from the limitations discussed in Sec.…”

“…Moreover, many of these algorithms rarely have true data dependences among tasks, and their maximum achievable parallelism exceeds 100×. It may seem that thread-level speculation (TLS) [28,60,66,68], which speculatively parallelizes sequential programs, could exploit this parallelism. However, this is not the case due to two reasons (Sec.…”