On the efficiency of transactional code generation: A GCC case study
Autor(a) principal: | |
---|---|
Data de Publicação: | 2018 |
Outros Autores: | , |
Tipo de documento: | Artigo de conferência |
Idioma: | eng |
Título da fonte: | Repositório Institucional da UNESP |
Texto Completo: | http://dx.doi.org/10.1109/WSCAD.2018.00037 http://hdl.handle.net/11449/190536 |
Resumo: | Memory transactions are becoming more popular as chip manufacturers are building native support for their execution. Although current Intel and IBM microprocessors support transactions in their instruction set architectures, there is still room for improvement in the compiler and runtime front. The GNU Compiler Collection (GCC) has language support for transactions, although performance is still a hindrance for its wider use. In this paper we perform an up-to-date study of the GCC transactional code generation and highlight where the main performance losses are coming from. Our study indicates that one of the main source of inefficiency is the read and write barriers inserted by the compiler. Most of this instrumentation is required because the compiler cannot determine, at compile time, whether a region of memory will be accessed concurrently or not. To overcome those limitations, we propose new language constructs that allow programmers to specify which memory locations should be free from instrumentation. Initial experimental results show a good speedup when barriers are elided using our proposed language support compared to the original code generated by GCC. |
id |
UNSP_8ee2032a37452c885942f0a9bf1ba6a3 |
---|---|
oai_identifier_str |
oai:repositorio.unesp.br:11449/190536 |
network_acronym_str |
UNSP |
network_name_str |
Repositório Institucional da UNESP |
repository_id_str |
2946 |
spelling |
On the efficiency of transactional code generation: A GCC case studyCompilersOptimizationOver-instrumentationParallel programmingTransactional memoryMemory transactions are becoming more popular as chip manufacturers are building native support for their execution. Although current Intel and IBM microprocessors support transactions in their instruction set architectures, there is still room for improvement in the compiler and runtime front. The GNU Compiler Collection (GCC) has language support for transactions, although performance is still a hindrance for its wider use. In this paper we perform an up-to-date study of the GCC transactional code generation and highlight where the main performance losses are coming from. Our study indicates that one of the main source of inefficiency is the read and write barriers inserted by the compiler. Most of this instrumentation is required because the compiler cannot determine, at compile time, whether a region of memory will be accessed concurrently or not. To overcome those limitations, we propose new language constructs that allow programmers to specify which memory locations should be free from instrumentation. Initial experimental results show a good speedup when barriers are elided using our proposed language support compared to the original code generated by GCC.São Paulo State University UNESPUniversity of Campinas UNICAMPSão Paulo State University UNESPUniversidade Estadual Paulista (Unesp)Universidade Estadual de Campinas (UNICAMP)Honorio, Bruno Chinelato [UNESP]De Carvalho, Joao Paulo LabegaliniBaldassin, Alexandro Jose [UNESP]2019-10-06T17:16:23Z2019-10-06T17:16:23Z2018-10-01info:eu-repo/semantics/publishedVersioninfo:eu-repo/semantics/conferenceObject184-190http://dx.doi.org/10.1109/WSCAD.2018.00037Proceedings - 2018 Symposium on High-Performance Computing Systems, WSCAD 2018, p. 184-190.http://hdl.handle.net/11449/19053610.1109/WSCAD.2018.000372-s2.0-85069848170Scopusreponame:Repositório Institucional da UNESPinstname:Universidade Estadual Paulista (UNESP)instacron:UNESPengProceedings - 2018 Symposium on High-Performance Computing Systems, WSCAD 2018info:eu-repo/semantics/openAccess2021-10-22T21:09:50Zoai:repositorio.unesp.br:11449/190536Repositório InstitucionalPUBhttp://repositorio.unesp.br/oai/requestopendoar:29462024-08-05T20:41:58.402852Repositório Institucional da UNESP - Universidade Estadual Paulista (UNESP)false |
dc.title.none.fl_str_mv |
On the efficiency of transactional code generation: A GCC case study |
title |
On the efficiency of transactional code generation: A GCC case study |
spellingShingle |
On the efficiency of transactional code generation: A GCC case study Honorio, Bruno Chinelato [UNESP] Compilers Optimization Over-instrumentation Parallel programming Transactional memory |
title_short |
On the efficiency of transactional code generation: A GCC case study |
title_full |
On the efficiency of transactional code generation: A GCC case study |
title_fullStr |
On the efficiency of transactional code generation: A GCC case study |
title_full_unstemmed |
On the efficiency of transactional code generation: A GCC case study |
title_sort |
On the efficiency of transactional code generation: A GCC case study |
author |
Honorio, Bruno Chinelato [UNESP] |
author_facet |
Honorio, Bruno Chinelato [UNESP] De Carvalho, Joao Paulo Labegalini Baldassin, Alexandro Jose [UNESP] |
author_role |
author |
author2 |
De Carvalho, Joao Paulo Labegalini Baldassin, Alexandro Jose [UNESP] |
author2_role |
author author |
dc.contributor.none.fl_str_mv |
Universidade Estadual Paulista (Unesp) Universidade Estadual de Campinas (UNICAMP) |
dc.contributor.author.fl_str_mv |
Honorio, Bruno Chinelato [UNESP] De Carvalho, Joao Paulo Labegalini Baldassin, Alexandro Jose [UNESP] |
dc.subject.por.fl_str_mv |
Compilers Optimization Over-instrumentation Parallel programming Transactional memory |
topic |
Compilers Optimization Over-instrumentation Parallel programming Transactional memory |
description |
Memory transactions are becoming more popular as chip manufacturers are building native support for their execution. Although current Intel and IBM microprocessors support transactions in their instruction set architectures, there is still room for improvement in the compiler and runtime front. The GNU Compiler Collection (GCC) has language support for transactions, although performance is still a hindrance for its wider use. In this paper we perform an up-to-date study of the GCC transactional code generation and highlight where the main performance losses are coming from. Our study indicates that one of the main source of inefficiency is the read and write barriers inserted by the compiler. Most of this instrumentation is required because the compiler cannot determine, at compile time, whether a region of memory will be accessed concurrently or not. To overcome those limitations, we propose new language constructs that allow programmers to specify which memory locations should be free from instrumentation. Initial experimental results show a good speedup when barriers are elided using our proposed language support compared to the original code generated by GCC. |
publishDate |
2018 |
dc.date.none.fl_str_mv |
2018-10-01 2019-10-06T17:16:23Z 2019-10-06T17:16:23Z |
dc.type.status.fl_str_mv |
info:eu-repo/semantics/publishedVersion |
dc.type.driver.fl_str_mv |
info:eu-repo/semantics/conferenceObject |
format |
conferenceObject |
status_str |
publishedVersion |
dc.identifier.uri.fl_str_mv |
http://dx.doi.org/10.1109/WSCAD.2018.00037 Proceedings - 2018 Symposium on High-Performance Computing Systems, WSCAD 2018, p. 184-190. http://hdl.handle.net/11449/190536 10.1109/WSCAD.2018.00037 2-s2.0-85069848170 |
url |
http://dx.doi.org/10.1109/WSCAD.2018.00037 http://hdl.handle.net/11449/190536 |
identifier_str_mv |
Proceedings - 2018 Symposium on High-Performance Computing Systems, WSCAD 2018, p. 184-190. 10.1109/WSCAD.2018.00037 2-s2.0-85069848170 |
dc.language.iso.fl_str_mv |
eng |
language |
eng |
dc.relation.none.fl_str_mv |
Proceedings - 2018 Symposium on High-Performance Computing Systems, WSCAD 2018 |
dc.rights.driver.fl_str_mv |
info:eu-repo/semantics/openAccess |
eu_rights_str_mv |
openAccess |
dc.format.none.fl_str_mv |
184-190 |
dc.source.none.fl_str_mv |
Scopus 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 |
|
_version_ |
1808129236352892928 |