Using Barrier Elision to Improve Transactional Code Generation

Bibliographic Details
Main Author: Honorio, Bruno Chinelato
Publication Date: 2022
Other Authors: Carvalho, Joao P. L. de, Morales, Catalina Munoz, Baldassin, Alexandro [UNESP], Araujo, Guido
Format: Article
Language: eng
Source: Repositório Institucional da UNESP
Download full: http://dx.doi.org/10.1145/3533318
http://hdl.handle.net/11449/237847
Summary: With chip manufacturers such as Intel, IBM, and ARM offering native support for transactional memory in their instruction set architectures, memory transactions are on the verge of being considered a genuine application tool rather than just an interesting research topic. Despite this recent increase in popularity on the hardware side of transactional memory (HTM), software support for transactional memory (STM) is still scarce and the only compiler with transactional support currently available, the GNU Compiler Collection (GCC), does not generate code that achieves desirable performance. For hybrid solutions of TM (HyTM), which are frameworks that leverage the best aspects of HTM and STM, the subpar performance of the software side, caused by inefficient compiler generated code, might forbid HyTM to offer optimal results. This article extends previous work focused exclusively on STM implementations by presenting a detailed analysis of transactional code generated by GCC in the context of HybridTM implementations. In particular, it builds on previous research of transactional memory support in the Clang/LLVM compiler framework, which is decoupled from any TM runtime, and presents the following novel contributions: (a) it shows that STM's performance overhead, due to an excessive amount of read and write barriers added by the compiler, also impacts the performance of HyTM systems; and (b) it reveals the importance of the previously proposed annotation mechanism to reduce the performance gap between HTM and STM in phased runtime systems. Furthermore, it shows that, by correctly using the annotations on just a few lines of code, it is possible to reduce the total number of instrumented barriers by 95% and to achieve speed-ups of up to 7x when compared to the original code generated by GCC and the Clang compiler.(1)
id UNSP_f73a26c144591f9abbba6387bddbfe49
oai_identifier_str oai:repositorio.unesp.br:11449/237847
network_acronym_str UNSP
network_name_str Repositório Institucional da UNESP
repository_id_str 2946
spelling Using Barrier Elision to Improve Transactional Code GenerationTransactional memoryDebuggingWith chip manufacturers such as Intel, IBM, and ARM offering native support for transactional memory in their instruction set architectures, memory transactions are on the verge of being considered a genuine application tool rather than just an interesting research topic. Despite this recent increase in popularity on the hardware side of transactional memory (HTM), software support for transactional memory (STM) is still scarce and the only compiler with transactional support currently available, the GNU Compiler Collection (GCC), does not generate code that achieves desirable performance. For hybrid solutions of TM (HyTM), which are frameworks that leverage the best aspects of HTM and STM, the subpar performance of the software side, caused by inefficient compiler generated code, might forbid HyTM to offer optimal results. This article extends previous work focused exclusively on STM implementations by presenting a detailed analysis of transactional code generated by GCC in the context of HybridTM implementations. In particular, it builds on previous research of transactional memory support in the Clang/LLVM compiler framework, which is decoupled from any TM runtime, and presents the following novel contributions: (a) it shows that STM's performance overhead, due to an excessive amount of read and write barriers added by the compiler, also impacts the performance of HyTM systems; and (b) it reveals the importance of the previously proposed annotation mechanism to reduce the performance gap between HTM and STM in phased runtime systems. Furthermore, it shows that, by correctly using the annotations on just a few lines of code, it is possible to reduce the total number of instrumented barriers by 95% and to achieve speed-ups of up to 7x when compared to the original code generated by GCC and the Clang compiler.(1)Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP)Center for Computational Engineering and Sciences (CCES)Univ Estadual Campinas, UNICAMP, Inst Comp, Av Albert Einstein 1251,Cidade Univ, BR-13083852 Campinas, SP, BrazilUniv Alberta, Dept Comp Sci, 2-21 Athabasca Hall, Edmonton, AB T6G 2E8, CanadaState Univ Sao Paulo, UNESP, Inst Geociencias & Ciencias Exatas, Dept Estat Matemat Aplicada & Comp, Campus Rio Claro DEMAC,Ave 24 A,1515, BR-13506900 Rio Claro, SP, BrazilState Univ Sao Paulo, UNESP, Inst Geociencias & Ciencias Exatas, Dept Estat Matemat Aplicada & Comp, Campus Rio Claro DEMAC,Ave 24 A,1515, BR-13506900 Rio Claro, SP, BrazilAssoc Computing MachineryUniversidade Estadual de Campinas (UNICAMP)Univ AlbertaUniversidade Estadual Paulista (UNESP)Honorio, Bruno ChinelatoCarvalho, Joao P. L. deMorales, Catalina MunozBaldassin, Alexandro [UNESP]Araujo, Guido2022-11-30T13:46:31Z2022-11-30T13:46:31Z2022-09-01info:eu-repo/semantics/publishedVersioninfo:eu-repo/semantics/article23http://dx.doi.org/10.1145/3533318Acm Transactions On Architecture And Code Optimization. New York: Assoc Computing Machinery, v. 19, n. 3, 23 p., 2022.1544-3566http://hdl.handle.net/11449/23784710.1145/3533318WOS:000851454700017Web of Sciencereponame:Repositório Institucional da UNESPinstname:Universidade Estadual Paulista (UNESP)instacron:UNESPengAcm Transactions On Architecture And Code Optimizationinfo:eu-repo/semantics/openAccess2024-11-27T14:10:05Zoai:repositorio.unesp.br:11449/237847Repositório InstitucionalPUBhttp://repositorio.unesp.br/oai/requestrepositoriounesp@unesp.bropendoar:29462024-11-27T14:10:05Repositório Institucional da UNESP - Universidade Estadual Paulista (UNESP)false
dc.title.none.fl_str_mv Using Barrier Elision to Improve Transactional Code Generation
title Using Barrier Elision to Improve Transactional Code Generation
spellingShingle Using Barrier Elision to Improve Transactional Code Generation
Honorio, Bruno Chinelato
Transactional memory
Debugging
title_short Using Barrier Elision to Improve Transactional Code Generation
title_full Using Barrier Elision to Improve Transactional Code Generation
title_fullStr Using Barrier Elision to Improve Transactional Code Generation
title_full_unstemmed Using Barrier Elision to Improve Transactional Code Generation
title_sort Using Barrier Elision to Improve Transactional Code Generation
author Honorio, Bruno Chinelato
author_facet Honorio, Bruno Chinelato
Carvalho, Joao P. L. de
Morales, Catalina Munoz
Baldassin, Alexandro [UNESP]
Araujo, Guido
author_role author
author2 Carvalho, Joao P. L. de
Morales, Catalina Munoz
Baldassin, Alexandro [UNESP]
Araujo, Guido
author2_role author
author
author
author
dc.contributor.none.fl_str_mv Universidade Estadual de Campinas (UNICAMP)
Univ Alberta
Universidade Estadual Paulista (UNESP)
dc.contributor.author.fl_str_mv Honorio, Bruno Chinelato
Carvalho, Joao P. L. de
Morales, Catalina Munoz
Baldassin, Alexandro [UNESP]
Araujo, Guido
dc.subject.por.fl_str_mv Transactional memory
Debugging
topic Transactional memory
Debugging
description With chip manufacturers such as Intel, IBM, and ARM offering native support for transactional memory in their instruction set architectures, memory transactions are on the verge of being considered a genuine application tool rather than just an interesting research topic. Despite this recent increase in popularity on the hardware side of transactional memory (HTM), software support for transactional memory (STM) is still scarce and the only compiler with transactional support currently available, the GNU Compiler Collection (GCC), does not generate code that achieves desirable performance. For hybrid solutions of TM (HyTM), which are frameworks that leverage the best aspects of HTM and STM, the subpar performance of the software side, caused by inefficient compiler generated code, might forbid HyTM to offer optimal results. This article extends previous work focused exclusively on STM implementations by presenting a detailed analysis of transactional code generated by GCC in the context of HybridTM implementations. In particular, it builds on previous research of transactional memory support in the Clang/LLVM compiler framework, which is decoupled from any TM runtime, and presents the following novel contributions: (a) it shows that STM's performance overhead, due to an excessive amount of read and write barriers added by the compiler, also impacts the performance of HyTM systems; and (b) it reveals the importance of the previously proposed annotation mechanism to reduce the performance gap between HTM and STM in phased runtime systems. Furthermore, it shows that, by correctly using the annotations on just a few lines of code, it is possible to reduce the total number of instrumented barriers by 95% and to achieve speed-ups of up to 7x when compared to the original code generated by GCC and the Clang compiler.(1)
publishDate 2022
dc.date.none.fl_str_mv 2022-11-30T13:46:31Z
2022-11-30T13:46:31Z
2022-09-01
dc.type.status.fl_str_mv info:eu-repo/semantics/publishedVersion
dc.type.driver.fl_str_mv info:eu-repo/semantics/article
format article
status_str publishedVersion
dc.identifier.uri.fl_str_mv http://dx.doi.org/10.1145/3533318
Acm Transactions On Architecture And Code Optimization. New York: Assoc Computing Machinery, v. 19, n. 3, 23 p., 2022.
1544-3566
http://hdl.handle.net/11449/237847
10.1145/3533318
WOS:000851454700017
url http://dx.doi.org/10.1145/3533318
http://hdl.handle.net/11449/237847
identifier_str_mv Acm Transactions On Architecture And Code Optimization. New York: Assoc Computing Machinery, v. 19, n. 3, 23 p., 2022.
1544-3566
10.1145/3533318
WOS:000851454700017
dc.language.iso.fl_str_mv eng
language eng
dc.relation.none.fl_str_mv Acm Transactions On Architecture And Code Optimization
dc.rights.driver.fl_str_mv info:eu-repo/semantics/openAccess
eu_rights_str_mv openAccess
dc.format.none.fl_str_mv 23
dc.publisher.none.fl_str_mv Assoc Computing Machinery
publisher.none.fl_str_mv Assoc Computing Machinery
dc.source.none.fl_str_mv Web of Science
reponame:Repositório Institucional da UNESP
instname:Universidade Estadual Paulista (UNESP)
instacron:UNESP
instname_str Universidade Estadual Paulista (UNESP)
instacron_str UNESP
institution UNESP
reponame_str Repositório Institucional da UNESP
collection Repositório Institucional da UNESP
repository.name.fl_str_mv Repositório Institucional da UNESP - Universidade Estadual Paulista (UNESP)
repository.mail.fl_str_mv repositoriounesp@unesp.br
_version_ 1854949068791349248