On the efficiency of transactional code generation: A GCC case study

Detalhes bibliográficos
Autor(a) principal: Honorio, Bruno Chinelato [UNESP]
Data de Publicação: 2018
Outros Autores: De Carvalho, Joao Paulo Labegalini, Baldassin, Alexandro Jose [UNESP]
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