Atenção: Todas as denúncias são sigilosas e sua identidade será preservada.
Os campos nome e e-mail são de preenchimento opcional
Metadados | Descrição | Idioma |
---|---|---|
Autor(es): dc.contributor | Universidade Estadual de Campinas (UNICAMP) | - |
Autor(es): dc.contributor | Universidade Estadual Paulista (Unesp) | - |
Autor(es): dc.creator | De Carvalho, Joao P. L. | - |
Autor(es): dc.creator | Honorio, Bruno C. | - |
Autor(es): dc.creator | Baldassin, Alexandra [UNESP] | - |
Autor(es): dc.creator | Araujo, Guido | - |
Data de aceite: dc.date.accessioned | 2022-02-22T00:26:44Z | - |
Data de disponibilização: dc.date.available | 2022-02-22T00:26:44Z | - |
Data de envio: dc.date.issued | 2020-12-11 | - |
Data de envio: dc.date.issued | 2020-12-11 | - |
Data de envio: dc.date.issued | 2020-05-01 | - |
Fonte completa do material: dc.identifier | http://dx.doi.org/10.1109/IPDPS47924.2020.00107 | - |
Fonte completa do material: dc.identifier | http://hdl.handle.net/11449/199200 | - |
Fonte: dc.identifier.uri | http://educapes.capes.gov.br/handle/11449/199200 | - |
Descrição: dc.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. This paper presents a detailed analysis of transactional code generated by GCC and by a proposed transactional memory support added to the Clang/LLVM compiler framework. Experimental results support the following contributions: (a) STM's performance overhead is due to an excessive amount of read and write barriers added by the compiler; (b) a new annotation mechanism for the Clang/LLVM compiler framework that aims to overcome the barrier over-instrumentation problem by allowing programmers to specify which variables should be free from transactional instrumentation; (c) a profiling tool that ranks the most accessed memory locations at runtime, working as a guiding tool for programmers to annotate the code. Furthermore, it is revealed 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 7× when compared to the original code generated by GCC and the Clang compiler. | - |
Descrição: dc.description | Institute of Computing-UNICAMP | - |
Descrição: dc.description | UNESP-Univ Estadual Paulista | - |
Descrição: dc.description | UNESP-Univ Estadual Paulista | - |
Formato: dc.format | 1008-1017 | - |
Idioma: dc.language | en | - |
Relação: dc.relation | Proceedings - 2020 IEEE 34th International Parallel and Distributed Processing Symposium, IPDPS 2020 | - |
???dc.source???: dc.source | Scopus | - |
Palavras-chave: dc.subject | Compilers | - |
Palavras-chave: dc.subject | Debugging | - |
Palavras-chave: dc.subject | Transactional Memory | - |
Título: dc.title | Improving Transactional Code Generation via Variable Annotation and Barrier Elision | - |
Aparece nas coleções: | Repositório Institucional - Unesp |
O Portal eduCAPES é oferecido ao usuário, condicionado à aceitação dos termos, condições e avisos contidos aqui e sem modificações. A CAPES poderá modificar o conteúdo ou formato deste site ou acabar com a sua operação ou suas ferramentas a seu critério único e sem aviso prévio. Ao acessar este portal, você, usuário pessoa física ou jurídica, se declara compreender e aceitar as condições aqui estabelecidas, da seguinte forma: