Submitted by Bruno Chinelato Honorio (brunochonorio@gmail.com) on 2018-09-16T23:56:19Z No. of bitstreams: 1 DissertacaoMestrado.pdf: 942500 bytes, checksum: 267b4e03ea0654a9a66bd58f2490310b (MD5) / Rejected by Elza Mitiko Sato null (elzasato@ibilce.unesp.br), reason: Solicitamos que realize correções na submissão seguindo as orientações abaixo: Problema 01) Está faltando o LOGO (Símbolo)da Universidade/Câmpus na capa do seu trabalho.(este item é obrigatório) Problema 02) Solicito que corrija a descrição na natureza da pesquisa na folha de rosto e insira na folha de aprovação): Dissertação apresentada como parte dos requisitos para obtenção do título de Mestre em Ciência da Computação, junto ao Programa de Pós-Graduação em Ciência da Computação, do Instituto de Geociências e Ciências Exatas da Universidade Estadual Paulista “Júlio de Mesquita Filho”, Câmpus de Rio Claro Problema 03) A paginação deve ser sequencial, iniciando a contagem na folha de rosto e mostrando o número a partir da introdução, a ficha catalográfica ficará após a folha de rosto e não deverá ser contada; a contagem no seu arquivo começou na introdução. Problema 04) Quando a financiadora é FAPESP, deve constar o nome dela e o número do processo também na folha de aprovação e nos agradecimentos, é norma do convênio. Lembramos que o arquivo depositado no repositório deve ser igual ao impresso, o rigor com o padrão da Universidade se deve ao fato de que o seu trabalho passará a ser visível mundialmente. Agradecemos a compreensão on 2018-09-17T14:32:13Z (GMT) / Submitted by Bruno Chinelato Honorio (brunochonorio@gmail.com) on 2018-09-19T22:38:43Z No. of bitstreams: 1 dissertacaoMestrado.pdf: 1125894 bytes, checksum: f24c8da48aae1c09a95bd67d010c2e68 (MD5) / Approved for entry into archive by Elza Mitiko Sato null (elzasato@ibilce.unesp.br) on 2018-09-20T14:44:36Z (GMT) No. of bitstreams: 1 honorio_bc_me_sjrp.pdf: 1093610 bytes, checksum: 238491c1445e63f7afbd08da117f2a87 (MD5) / Made available in DSpace on 2018-09-20T14:44:36Z (GMT). No. of bitstreams: 1 honorio_bc_me_sjrp.pdf: 1093610 bytes, checksum: 238491c1445e63f7afbd08da117f2a87 (MD5) Previous issue date: 2018-08-09 / Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP) / Memória Transacional (Transactional Memory – TM) possibilita que programadores utilizem-se do conceito de transação na escrita de código concorrente. Nesse contexto, uma transação pode ser entendida como um bloco de instruções que é executado atomicamente e de forma isolada, ou seja, os estados intermediários no processamento de uma transação não são vistos pelas demais. Embora inicialmente confinada ao ambiente acadêmico, TM está se tornando cada vez mais popular. Prova disto é a adição de hardware transacional aos novos processadores da Intel e IBM, além de suporte para codificação de transações provido por compiladores como o GCC. A grande vantagem do modelo transacional é o maior nível de abstração fornecido ao programador, facilitando a escrita de programas concorrentes e evitando erros de sincronização famosos causados pelas travas (locks), como o deadlock. Infelizmente, o suporte em software para execução de transações ainda não provê desempenho muito bom. Em particular, o código transacional, produzido por compiladores e o sistema de tempo de execução associado, ainda pode ser considerado ineficiente. Nesta dissertação é realizado um estudo atualizado sobre a geração de código transacional do compilador GCC com o objetivo de encontrar a razão da deficiência de desempenho do compilador. O trabalho feito indica que uma das principais fontes de ineficiência são as barreiras de leitura e escrita inseridas pelo compilador. O problema dessa instrumentação acontece quando o compilador não consegue determinar, em tempo de compilação, se uma região de memória será acessada concorrentemente ou não, forçando o compilador a tomar uma decisão pessimista e instrumentar essa região de memória. Esse fenômeno é chamado de instrumentação excessiva. Para superar essas limitações, esta dissertação propõe uma nova construção de linguagem através de uma nova cláusula pragma que permite que programadores especifiquem quais regiões de memória não precisam ser instrumentadas. Para validar a nova cláusula pragma, esta dissertação conduziu experimentos usando o pacote STAMP, composto por aplicações transacionais. Os resultados obtidos mostram um grande ganho de desempenho para as aplicações que usaram o pragma proposto, com essas aplicações sendo até 7.2x mais rápidas que o código original gerado pelo GCC. / Transactional Memory (TM) allows programmers to utilize the concept of transaction for writing concurrent code. In this context, a transactioncan be extended as a block of instructions that is executed atomically and isolated, that is, the intermediate states of the processing of a transaction can not be seen by the other transactions. Although initially confined to the academic field, TM is becoming more popular. An evidence of this is the addition of transactional hardware to the new processors from Intel and IBM, as well as the support for transactional code provided by compilers such as GCC. The biggest advantage to the transactional model is the bigger level of abstraction provided to the programmer, making the process of writing parallel code easier, as well as avoiding famous synchronization errors caused by traditional locks, such as the deadlock problem. Unfortunately, the software support for execution of transaction still does not provide a good performance. In particular, transactional code, produced by compilers and the associated runtime system, can still be considered inefficient. This thesis performs an up-to-date study of the GCC transactional code generation and with the objective to find where the main performance losses are coming from. The study done indicates that one of the main sources of inefficiency is the read and write barriers inserted by the compiler. The problem of this instrumentation is that the compiler cannot determine, at compile time, if a memory region will be accessed concurrently or not, forcing the compiler to take a pessimist approach and instrument this memory region. This phenomenom is called Over-instrumentation. To overcome these limitations, this thesis proposes a new language construct through a new pragma clause that allows programmers to specify which memory regions do not need to be instrumented. To validade the new pragma clause, this thesis conducted experiments using the STAMP benchmark suite, composed of transactional applications. The obtained results show a great performance gain for applications that used the proposed pragma, with them being up to 7.2x faster than the original code generated by GCC. / 2016/12103-7