scispace - formally typeset
Search or ask a question
Topic

Transactional memory

About: Transactional memory is a research topic. Over the lifetime, 2365 publications have been published within this topic receiving 60818 citations.


Papers
More filters
Proceedings ArticleDOI
20 Sep 2006
TL;DR: A constraint-based solution, which uses a decision-table to solve the issue of field-to-widget assignment between database table and transactional page and then produces the later automatically, which can be used as a general solution for transactional web applications.
Abstract: In this paper, we propose a novel framework, called CATER, for the automated layout of web application user interfaces. This framework is a constraint-based solution, which uses a decision-table to solve the issue of field-to-widget assignment between database table and transactional page and then produces the later automatically. It caches the code skeleton of autogenerated transactional pages and gathers selection frequency of data items from temporary log files respectively to improve the computing performance and optimize the layout of transactional pages. Furthermore, this framework takes into account the UI layout, data validation, persistent store, navigation (flow control), and maintenance completely. Therefore, it can be used as a general solution for transactional web applications.

2 citations

Journal ArticleDOI
TL;DR: This paper presents the redesign of an existing concurrent hash table using several HTM-based synchronization mechanisms, which shows HTm-based locking scales well on the authors' testing platform, and its performance is higher when running large-scale workloads.
Abstract: Hardware Transaction Memory (HTM) opens a new way to scaling multi-core software. Its main target is to achieve high performance on multi-core systems, and at the same time simplify concurrency control and guarantee correctness. This paper presents the redesign of an existing concurrent hash table using several HTM-based synchronization mechanisms. As compared with a fine-grained lock implementation, HTM-based locking scales well on our testing platform, and its performance is higher when running large-scale workloads. In addition, HTM-based global locking consumes much less memory. In summary, several observations are made in this paper with detailed experimental analysis, which would have important implications for future research of concurrent data structures and HTM.

2 citations

Book ChapterDOI
24 Feb 2011
TL;DR: This paper presents MAPT, which uses static information to guide the programmer to select an STM property, and its integration in the Low Level Virtual Machine compiler framework, and results from the evaluation with test cases and two STAMP benchmarks.
Abstract: With the advent of Transactional Memory, a multitude of Software Transactional Memory (STM) systems evolved. Often, the programmer sets key parameters of an STM system at compile time. The performance of the application depends on choosing the right parameters. Unfortunately, programmers do not always know the application characteristic to decide on a profound basis. As a consequence, the application may run longer than necessary. Thus, we propose MAPT, which uses static information to guide the programmer to select an STM property. In particular, MAPT assists the programmer to select the resolution of the conflict detection scheme. This paper presents MAPT, its integration in the Low Level Virtual Machine compiler framework, and results from the evaluation with test cases and two STAMP benchmarks.

2 citations

Book ChapterDOI
01 Oct 2015
TL;DR: It is found that either speculative execution option always outperforms the other two modes in terms of their convergence characteristics, and the TSX options are very competitive when it comes to runtime performance measured with the “time-to-convergence” criterion introduced in [8].
Abstract: In this paper we continue our investigations started in [8] into the effects of using different synchronization mechanisms in OpenMP-threaded iterative mesh optimization algorithms. We port our test code to the Intel® Xeon® processor (former codename “Haswell”) by employing a user-guided locking API for OpenMP [4] that provides a general and unified user interface and runtime framework. Since the Intel® Transactional Synchronization Extensions (TSX) provide two different options for speculation — Hardware Lock Elision (HLE) and Restricted Transactional Memory (RTM) — we compare a total of four different run modes: (i) HLE, (ii) RTM, (iii) OpenMP critical, and (iv) “unsynchronized”. As we did in [8], we find that either speculative execution option always outperforms the other two modes in terms of their convergence characteristics. Even with their higher overhead, the TSX options are very competitive when it comes to runtime performance measured with the “time-to-convergence” criterion introduced in [8].

2 citations

Proceedings ArticleDOI
01 Feb 2019
TL;DR: This paper examines the code generated by a state-of-theart JavaScript compiler and finds that the code has a high frequency of Stack Map Points, and extends the compiler to generate hardware transactions around SMPs, and performs simple within-transaction optimizations enabled by transactions.
Abstract: Scripting languages’ inferior performance stems from compilers lacking enough static information. To address this limitation, they use JIT compilers organized into multiple tiers, with higher tiers using profiling information to generate high-performance code. Checks are inserted to detect incorrect assumptions and, when a check fails, execution transfers to a lower tier. The points of potential transfer between tiers are called Stack Map Points (SMPs). They require a consistent state in both tiers and, hence, limit code optimization across SMPs in the higher tier. This paper examines the code generated by a state-of-theart JavaScript compiler and finds that the code has a high frequency of SMPs. These SMPs rarely cause execution to transfer to lower tiers. However, both the optimization-limiting effect of the SMPs, and the overhead of the SMP-guarding checks contribute to scripting languages’ low performance. To tackle this problem, we extend the compiler to generate hardware transactions around SMPs, and perform simple within-transaction optimizations enabled by transactions. We target emerging lightweight HTM systems and call our changes NoMap. We evaluate NoMap on the SunSpider and Kraken suites. We find that NoMap lowers the instruction count by an average of 14.2% and 11.5%, and the execution time by an average of 16.7% and 8.9%, for SunSpider and Kraken, respectively. Keywords-JavaScript; Transactional Memory; Compiler Optimizations; JIT Compilation.

2 citations


Network Information
Related Topics (5)
Compiler
26.3K papers, 578.5K citations
87% related
Cache
59.1K papers, 976.6K citations
86% related
Parallel algorithm
23.6K papers, 452.6K citations
84% related
Model checking
16.9K papers, 451.6K citations
84% related
Programming paradigm
18.7K papers, 467.9K citations
83% related
Performance
Metrics
No. of papers in the topic in previous years
YearPapers
202316
202240
202129
202063
201970
201888