A Dynamically Adaptable Hardware Transactional Memory

Abstract

Abstract-We present Task Superscalar, an abstraction of instruction-level out-of-order pipeline that operates at the tasklevel. Like ILP pipelines, which uncover parallelism in a sequential instruction stream, task superscalar uncovers tasklevel parallelism among tasks generated by a sequential thread. Utilizing intuitive programmer annotations of task inputs and outputs, the task superscalar pipeline dynamically detects intertask data dependencies, identifies task-level parallelism, and executes tasks out-of-order.Furthermore, we propose a design for a distributed task superscalar pipeline frontend, that can be embedded into any manycore fabric, and manages cores as functional units.We show that our proposed mechanism is capable of driving hundreds of cores simultaneously with non-speculative tasks, which allows our pipeline to sustain work windows consisting of tens of thousands of tasks. We further show that our pipeline can maintain a decode rate faster than 60ns per task and dynamically uncover data dependencies among as many as ∼50,000 in-flight tasks, using 7MB of on-chip eDRAM storage. This configuration achieves speedups of 95-255x (average 183x) over sequential execution for nine scientific benchmarks, running on a simulated CMP with 256 cores.Task superscalar thus enables programmers to exploit manycore systems effectively, while simultaneously simplifying their programming model.

An integrated pseudo-associativity and relaxed-order approach to hardware transactional memory

“…For example, while TCC, UTM, VTM, LogTM, PTM, XTM, RTM, Scalable-TCC, ObjectTM, FasTM, Reconfigurable-TM, SEL-TM and SUV-TM [Hammond et al 2004]; [Ananian et al 2005]; [Rajwar et al 2005]; [Moore et al 2006]; [Chuang et al 2006]; [Chung et al 2006b]; [Shriraman et al 2007]; [Chafi et al 2007]; [Khan et al 2008]; [Lupon et al 2008] [Lupon et al 2009]; [Armejach et al 2011]; [Zhao et al 2012]; [Yan et al 2012] focus on reducing static overheads on version management, OneTM, DATM, SBCRHTM, ProactiveTM, EasyTM, DynTM, SON-TM, BFGTS-TM, 42:6 Z. Yan et al and ZEBRA [Blundell et al 2007]; [Ramadan et al 2008]; [Titos et al 2009]; [Blake et al 2009]; [Tomic et al 2009]; [Lupon et al 2010]; [Aydonat and Abdelrahman 2010]; [Blake et al 2011]; propose different TM architectures to alleviate the dynamic overheads incurred by transactional conflicts. However, most of these methods decouple conflict management from version management and do not exploit opportunities availed by the interplay between conflict management and version management.…”

A Waiting Mechanism with Conflict Prediction on Hardware Transactional Memory

“…To reduce the cost for re-execution, some techniques for optimizing rollbacks have been proposed [10]- [12]. Besides, many thread scheduling techniques for reducing conflicts by controlling transactional sequences have been also proposed [13]- [15].…”

Mitigating the Mismatch between the Coherence Protocol and Conflict Detection in Hardware Transactional Memory

“…[8], [27], [28] provides hardware support for a hybrid-mode execution of transactions. While the hybrid approach could boost performance, the complexity of implementing an unbounded lazy mode can be considerably high.…”

“…The transaction with lower priority is stopped to resolve the conflict. As the cache coherence protocol can detect data access conflicts, the majority of HTM designs [6], [7], [8] including commercial implementations (e.g., IBM System z [9]) piggyback onto the coherence protocol (typically directory-based) for conflict detection.…”