Performance Improvement via Always-Abort Hardware Transacti

CURATOR

A pinboard by

this curator

Ph.D. Student, University of Rochester

PINBOARD SUMMARY

This work proposes that a counter-intuitive hardware instruction should be included on future CPU processors. Prior CPU processors have implemented a functionality called "hardware transactional memory." Hardware transactional memory, or HTM, gives a program the ability to make a series of changes (a "transaction") while hiding intermediate steps, preventing its scratch work from becoming visible. If anyone else tries to see this scratch work, the attempt is aborted, leaving the global state unchanged (the program can then retry).

Our proposal argues that an always-abort HTM functionality is useful. A program using always-abort HTM (AAHTM) expects that, no matter what, the global state will remain unchanged after the transaction. This idea is useful because we can use AAHTM to "warm-up" the hardware before actually executing the real attempt. Since we can use AAHTM when it would be otherwise unsafe to execute code, and we can use it when a program would otherwise be waiting, we can use the functionality to accelerate a large class of programs. Notably, we are able to accelerate older versions of database software by up to 2.5x, and can accelerate modern matrix libraries by 15%.

3 ITEMS PINNED

Using the Xeon Phi Platform to Run Speculatively-Parallelized Codes

Abstract: Intel Xeon Phi accelerators are one of the newest devices used in the field of parallel computing. However, there are comparatively few studies concerning their performance when using most of the existing parallelization techniques. One of them is thread-level speculation, a technique that optimistically tries to extract parallelism of loops without the need of a compile-time analysis that guarantees that the loop can be executed in parallel. In this article we evaluate the performance delivered by an Intel Xeon Phi coprocessor when using a software, state-of-the-art thread-level speculative parallelization library in the execution of well-known benchmarks. We describe both the internal characteristics of the Xeon Phi platform and the particularities of the thread-level speculation library being used as benchmark. Our results show that, although the Xeon Phi delivers a relatively good speedup in comparison with a shared-memory architecture in terms of scalability, the relatively low computing power of its computational units when specific vectorization and SIMD instructions are not fully exploited makes this first generation of Xeon Phi architectures not competitive (in terms of absolute performance) with respect to conventional multicore systems for the execution of speculatively parallelized code.

Pub.: 08 Apr '16, Pinned: 29 Jun '17

Hardware extensions to make lazy subscription safe

Abstract: Transactional Lock Elision (TLE) uses Hardware Transactional Memory (HTM) to execute unmodified critical sections concurrently, even if they are protected by the same lock. To ensure correctness, the transactions used to execute these critical sections "subscribe" to the lock by reading it and checking that it is available. A recent paper proposed using the tempting "lazy subscription" optimization for a similar technique in a different context, namely transactional systems that use a single global lock (SGL) to protect all transactional data. We identify several pitfalls that show that lazy subscription \emph{is not safe} for TLE because unmodified critical sections executing before subscribing to the lock may behave incorrectly in a number of subtle ways. We also show that recently proposed compiler support for modifying transaction code to ensure subscription occurs before any incorrect behavior could manifest is not sufficient to avoid all of the pitfalls we identify. We further argue that extending such compiler support to avoid all pitfalls would add substantial complexity and would usually limit the extent to which subscription can be deferred, undermining the effectiveness of the optimization. Hardware extensions suggested in the recent proposal also do not address all of the pitfalls we identify. In this extended version of our WTTM 2014 paper, we describe hardware extensions that make lazy subscription safe, both for SGL-based transactional systems and for TLE, without the need for special compiler support. We also explain how nontransactional loads can be exploited, if available, to further enhance the effectiveness of lazy subscription.

Pub.: 23 Jul '14, Pinned: 29 Jun '17

Inherent Limitations of Hybrid Transactional Memory

Abstract: Several Hybrid Transactional Memory (HyTM) schemes have recently been proposed to complement the fast, but best-effort, nature of Hardware Transactional Memory (HTM) with a slow, reliable software backup. However, the fundamental limitations of building a HyTM with nontrivial concurrency between hardware and software transactions are still not well understood. In this paper, we propose a general model for HyTM implementations, which captures the ability of hardware transactions to buffer memory accesses, and allows us to formally quantify and analyze the amount of overhead (instrumentation) of a HyTM scheme. We prove the following: (1) it is impossible to build a strictly serializable HyTM implementation that has both uninstrumented reads and writes, even for weak progress guarantees, and (2) under reasonable assumptions, in any opaque progressive HyTM, a hardware transaction must incur instrumentation costs linear in the size of its data set. We further provide two upper bound implementations whose instrumentation costs are optimal with respect to their progress guarantees. In sum, this paper captures for the first time an inherent trade-off between the degree of concurrency a HyTM provides between hardware and software transactions, and the amount of instrumentation overhead the implementation must incur.

Pub.: 17 Feb '15, Pinned: 29 Jun '17

Performance Improvement via Always-Abort Hardware Transactional Memory