Programa de P ´os-Graduac¸ ˜ao em Computac¸ ˜ao
Dissertac¸ ˜ao
An ´alise do Impacto de Diferentes Versionamentos de Dados das Mem ´orias Transacionais sobre Mem ´oriasPhase-Change
Felipe Leivas Teixeira
Pelotas, 2016
An ´alise do Impacto de Diferentes Versionamentos de Dados das Mem ´orias Transacionais sobre Mem ´oriasPhase-Change
Dissertac¸ ˜ao apresentada ao Programa de P ´os-Graduac¸ ˜ao em Computac¸ ˜ao da Univer- sidade Federal de Pelotas, como requisito parcial `a obtenc¸ ˜ao do t´ıtulo de Mestre em Computac¸ ˜ao
Orientador: Prof. Dr. Maur´ıcio Lima Pilla Coorientador: Prof. Dr. Andr ´e Rauber Du Bois
Pelotas, 2016
T266a Teixeira, Felipe Leivas
Análise do impacto de diferentes versionamentos de dados das memórias transacionais sobre memórias Phase-Change / Felipe Leivas Teixeira ; Maurício Lima Pilla, orientador; André Rauber Du Bois, coorientador. - Pelotas, 2016.
116 f.
Dissertação (Mestrado) – Programa de Pós-Graduação em Computação, Centro de Desenvolvimento Tecnológico, Universidade Federal de Pelotas, 2016.
1. Memórias transacionais. 2. Memórias Phase-Change. 3. Processamento paralelo. 4. Hierarquia de memória. I. Pilla, Maurício Lima, orient. II. Du Bois, André Rauber, coorient. III. Título.
CDD: 005 Dados Internacionais de Catalogação na Publicação (CIP)
Catalogação na Fonte: Aline Herbstrith Batista CRB 10/ 1737 Biblioteca Campus Porto - UFPel
TEIXEIRA, Felipe Leivas. An ´alise do Impacto de Diferentes Versionamentos de Dados das Mem ´orias Transacionais sobre Mem ´orias Phase-Change. 2016.
116 f. Dissertac¸ ˜ao (Mestrado em Computac¸ ˜ao) – Programa de P ´os-Graduac¸ ˜ao em Computac¸ ˜ao, Centro de Desenvolvimento Tecnol ´ogico, Universidade Federal de Pelotas, Pelotas, 2016.
Dois problemas dos grandes sistemas computacionais atualmente est ˜ao relacio- nados com o consumo de energia e a programac¸ ˜ao concorrente correta que aproveite os recursos disponibilizados. Das v ´arias tecnologias para resolver esses problemas, destacam-se aPhase-Change Memory e as mem ´orias transacionais.
APhase-Change Memory (PCM) ´e uma nova tecnologia que est ´a sendo estudada para substituir as DRAMs, como mem ´oria principal, em grandesdata centers, devido a sua n ˜ao volatilidade que reduz o consumo est ´atico de pot ˆencia. O principal problema da PCM est ´a em suas escritas, que s ˜ao lentas e degradam o seu material, diminuindo assim sua vida ´util.
Mem ´orias transacionais s ˜ao um m ´etodo de sincronizac¸ ˜ao dethreadsdesenvolvido para diminuir as dificuldades e limitac¸ ˜oes de m ´etodos baseados emlocks. Suas prin- cipais vantagens s ˜ao relacionadas a ser um m ´etodo de alto n´ıvel, mais f ´acil de progra- mar e que permite a composic¸ ˜ao e re ´uso de c ´odigo com mais facilidade. Outra vanta- gem das mem ´orias transacionais em comparac¸ ˜ao comlocks ´e a inexist ˆencia do pro- blema dedeadlock. Mem ´orias transacionais s ˜ao baseadas nas transac¸ ˜oes de banco de dados. As transac¸ ˜oes em sistemas de banco de dados satisfazem quatro proprie- dades: atomicidade, consist ˆencia, isolamento e durabilidade, ou ACID. As transac¸ ˜oes das mem ´orias transacionais tamb ´em devem garantir as propriedades ACID, exceto a durabilidade. Para garantir a atomicidade, as mem ´orias transacionais implementam v ´arios mecanismos de versionamento de dados para fazer o gerenciamento dos da- dos.
Desta forma, o objetivo deste trabalho ´e analisar o impacto em PCMs das diferentes implementac¸ ˜oes de versionamento de dados em STMs. Para tanto, foi implementado o Phase-Change Memory - Multicore Simulator (PCM-MS), um simulador de hierar- quia de mem ´oria para arquiteturas de m ´ultiplos n ´ucleos onde a PCM ´e a mem ´oria principal. O PCM-MS faz a simulac¸ ˜ao dos acessos e determina os bits alterados na PCM para estimar o desgaste e o consumo de energia da PCM. Al ´em do PCM-MS, a ferramenta Pintools foi utilizada para gerar arquivos de trac¸o que s ˜ao executados no simulador. Como biblioteca de STM foi utilizada a TinySTM, pois implementa diversos versionamentos e constitui parte do estado da arte de STM. Comobenchmarks, foram utilizados o Eigenbench e o conjunto debenchmarksSTAMP.
n ´umero deaborts dos versionamentos, onde o WBC apresenta um n ´umero deaborts muito menor que os outros, sendo at ´e 39 vezes menor no experimento com o ben- chmark Kmeans com 64 threads. Em trabalhos futuros, pretende-se continuar o de- senvolvimento do simulador, al ´em de fazer a an ´alise do desgaste na PCM de outros sistemas transacionais.
Palavras-chave: Mem ´orias Transacionais, Phase-Change Memory, Processamento Paralelo, Hierarquias de Mem ´oria.
TEIXEIRA, Felipe Leivas. Impact Analysis of Different Version Management of Transactional Memory on Phase-Change Memories. 2016. 116 f. Dissertac¸ ˜ao (Mestrado em Computac¸ ˜ao) – Programa de P ´os-Graduac¸ ˜ao em Computac¸ ˜ao, Centro de Desenvolvimento Tecnol ´ogico, Universidade Federal de Pelotas, Pelotas, 2016.
Two of the major issues in current large computer systems are energy consumption and how to explore concurrent systems in a correct and efficient way. Phase-Change Memories and Transactional Memories are two technologies that intend to solve these issues.
Phase-Change Memory (PCM) is a new memory technology being studied to re- place DRAMs as the main memory in large data centers, as its non-volatility reduces static power consumption. The main problem of PCMs consists in its write operations, which are slow and generate degradation in material, thus reducing its life.
Transactional memories are synchronization methods developed to reduce the dif- ficulties and limitations of lock-based methods. Their main advantages are related to being high-level and allowing composition and reuse of code. Another advantage of transactional memories compared to locks is the absence of deadlocks. Transactional memories are based on database transactions. Transactions in database systems meet four properties: atomicity, consistency, isolation and durability, or ACID. Transac- tional memories must also implement the ACID properties, except for durability. Trans- actional memories implement version management of data to ensure atomicity.
The objective of this study is to analyze the impact on the PCM of different version management techniques implemented by STMs. To that end, the Phase-Change Mem- ory - Multicore Simulator (PCM-MS) was implemented, a memory hierarchy simulator for multi-core systems where the PCM is the main memory. It determines changed bits in PCM to estimate the wear and energy consumption. In addition to the PCM-MS, Pintools was used to generate trace files that run in the simulator. As the STM library, TinySTM was chosen because it implement various version management and it rep- resents the state-of-art in STM. As benchmarks, Eigenbench and the STAMP set of benchmarks were used.
The results showed that the WBC VM had the lowest wear on the PCM in 3 of 7 benchmarks analyzed. These results are related to the number of aborts of VMs, where the WBC presents a much smaller number of aborts than others VM, being up to 39 times lower in the experiment with the benchmark Kmeans with 64 threads. In future works, we intend to enhance the simulator and make the impact analysis in PCM of others transactional systems.
Figura 1 Comparac¸ ˜ao entre oReset, oSete a leitura (Read). Fonte: (WANG;
WU, 2009). . . 21
Figura 2 Alternativas de sistemas de mem ´oria com mem ´oria PCM. Fonte: (XIA et al., 2015) . . . 22
Figura 3 Exemplo de versionamento adiantado (a) e atrasado (b). Fonte: (BALDASSIN, 2009) . . . 23
Figura 4 Detecc¸ ˜ao de conflitos em modo adiantado. Fonte: (RIGO; CENTO- DUCATTE; BALDASSIN, 2007) . . . 25
Figura 5 Detecc¸ ˜ao de conflitos em modo atrasado. Fonte: (RIGO; CENTO- DUCATTE; BALDASSIN, 2007) . . . 26
Figura 6 Como ´e feita a sincronizac¸ ˜ao na tinySTM. Fonte: (FELBER; FET- ZER; RIEGEL, 2008) . . . 26
Figura 7 Gerac¸ ˜ao dos Arquivos de Trac¸o . . . 34
Figura 8 Entrada e Sa´ıda da Simulac¸ ˜ao com o PCM-MS . . . 35
Figura 9 N´ıveis deCache . . . 35
Figura 10 Comunicac¸ ˜ao entre a Hierarquia de Cache e a PCM . . . 36
Figura 11 Resultados do ExperimentoScalability . . . 43
Figura 12 Resultados da Porcentagem M ´axima de Escalabilidade (PME) . . . 43
Figura 13 Resultados do ExperimentoContention . . . 44
Figura 14 N ´umero de Aborts dos Experimentos com a Aplicac¸ ˜aoContention . 45 Figura 15 Resultados do ExperimentoDensity . . . 45
Figura 16 Resultados do ExperimentoTransaction Length . . . 46
Figura 17 Resultados do ExperimentoTemporal Locality . . . 47
Figura 18 Resultados do ExperimentoPollution . . . 47
Figura 19 Resultados do ExperimentoPredominance . . . 48
Figura 20 Resultados do ExperimentoWorking-Set . . . 49
Figura 21 Total de Instruc¸ ˜oes de Acesso `a Mem ´oria doBenchmark Bayes . . 52
Figura 22 Total de Instruc¸ ˜oes de Acesso `a Mem ´oria doBenchmark Genome . 53 Figura 23 Total de Instruc¸ ˜oes de Acesso `a Mem ´oria doBenchmark Intruder . 53 Figura 24 Total de Instruc¸ ˜oes de Acesso `a Mem ´oria doBenchmark Kmeans . 54 Figura 25 Total de Instruc¸ ˜oes de Acesso `a Mem ´oria doBenchmark Labyrinth 55 Figura 26 Total de Instruc¸ ˜oes de Acesso `a Mem ´oria doBenchmark SSCA2 . 55 Figura 27 Total de Instruc¸ ˜oes de Acesso `a Mem ´oria doBenchmark Vacation . 56 Figura 28 N ´umero de Leituras na PCM dos Experimentos com o Benchmark Bayes . . . 57
Figura 30 N ´umero de Leituras na PCM dos Experimentos com o Benchmark Intruder . . . 58 Figura 31 N ´umero de Leituras na PCM dos Experimentos com o Benchmark
Kmeans . . . 59 Figura 32 N ´umero de Leituras na PCM dos Experimentos com o Benchmark
Labyrinth . . . 60 Figura 33 N ´umero de Leituras na PCM dos Experimentos com o Benchmark
SSCA2 . . . 60 Figura 34 N ´umero de Leituras na PCM dos Experimentos com o Benchmark
Vacation . . . 61 Figura 35 N ´umero de Escritas na PCM dos Experientos com o Benchmark
Bayes . . . 61 Figura 36 N ´umero de Escritas na PCM dos Experientos com o Benchmark
Genome . . . 62 Figura 37 N ´umero de Escritas na PCM dos Experientos com o Benchmark
Intruder . . . 63 Figura 38 N ´umero de Escritas na PCM dos Experientos com o Benchmark
Kmeans . . . 63 Figura 39 N ´umero de Escritas na PCM dos Experientos com o Benchmark
Labyrinth . . . 64 Figura 40 N ´umero de Escritas na PCM dos Experientos com o Benchmark
SSCA2 . . . 64 Figura 41 N ´umero de Escritas na PCM dos Experientos com o Benchmark
Vacation . . . 65 Figura 42 Bits Alterados na PCM do Experimento com oBenchmark Bayes . 66 Figura 43 Bits Alterados na PCM do Experimento com oBenchmark Genome 66 Figura 44 Bits Alterados na PCM do Experimento com oBenchmark Intruder 67 Figura 45 Bits Alterados na PCM do Experimento com oBenchmark Kmeans 68 Figura 46 Bits Alterados na PCM do Experimento com oBenchmark Labyrinth 68 Figura 47 Bits Alterados na PCM do Experimento com oBenchmark SSCA2 . 69 Figura 48 Bits Alterados na PCM do Experimento com oBenchmark Vacation 70 Figura 49 Bits Alterados por Escrita . . . 71 Figura 50 Estimativa do Consumo de Energia da PCM . . . 73 Figura 51 Porcentagem do consumo de energia de Sets, Resets e Leituras na
PCM . . . 74
Tabela 1 Definic¸ ˜oes das Caracter´ısticas Ortogonais do EigenBench (HONG
et al., 2010) . . . 37
Tabela 2 Par ˆametros Utilizados com o EigenBench . . . 42
Tabela 3 Par ˆametros Utilizados com cada Benchmark do STAMP . . . 51
Tabela 4 Par ˆametros Utilizados no Simulador PCM-MS . . . 51
ACID Atomicidade, Consist ˆencia, Isolamento e Durabilidade DRAM Dynamic Random Access Memory
HTM Hardware Transactional Memory PCM Phase-Change Memory
PMD Personal Mobile Devices RAM Random Access Memory
RSTM Rochester Software Transactional Memory SSCA2 Scalable Synthetic Compact Applications 2
STAMP StanfordTransactional Applications for Multi-Processing STM Software Transactional Memory
TL2 Transactional Locking 2 TM Transactional Memory VM Vesion Management WBC Write Back Commit-time WBE Write Back Encounter-time WT Write Through
1 INTRODUC¸ ˜AO . . . . 16
1.1 Motivac¸ ˜ao . . . 17
1.2 Objetivos . . . 18
1.3 Metodologia . . . 18
1.3.1 Estudo e caracterizac¸ ˜ao dos versionamentos de dados implementados em STM . . . 18
1.3.2 Implementac¸ ˜ao do simulador . . . 18
1.3.3 Comparac¸ ˜ao dos diferentes versionamentos de dados em relac¸ ˜ao ao impacto em uma mem ´oria PCM . . . 19
1.4 Estrutura do Texto. . . 19
2 BACKGROUND . . . . 20
2.1 Phase-Change Memory . . . 20
2.1.1 Escritas . . . 20
2.1.2 Leituras . . . 20
2.1.3 Limitac¸ ˜oes da PCM . . . 21
2.1.4 Sistemas de Mem ´oria com PCM . . . 21
2.2 Mem ´orias Transacionais . . . 22
2.2.1 Propriedades . . . 22
2.2.2 Versionamento de Dados . . . 23
2.2.3 Detecc¸ ˜ao de Conflito . . . 24
2.3 TinySTM . . . 26
2.3.1 Sincronizac¸ ˜ao e Versionamento . . . 26
2.3.2 Escritas . . . 27
2.3.3 Leituras . . . 27
2.3.4 Gerenciamento de Mem ´oria . . . 28
2.3.5 Gerenciador de Contenc¸ ˜ao . . . 28
2.4 Trabalhos Relacionados . . . 29
2.4.1 Analyzing the Impact of Useless Write-Backs on the Endurance and Energy Consumption of PCM Main Memory . . . 29
2.4.2 Bit Mapping for Balanced PCM Cell Programming. . . 29
2.4.3 An ´alise de desgaste de t ´ecnicas de correc¸ ˜ao de erros em Phase- Change Memories . . . 30
2.4.4 Curling-PCM: Application-Specific Wear Leveling for Phase Change Me- mory based Embedded Systems . . . 30
2.4.5 A three-stage-write scheme with flip-bit for PCM main memory . . . 31
2.4.6 Profiling Patterns of Bit Flipping for Software Transactional Memories . . 31
2.4.8 Experimentos com Gerenciamento de Contenc¸ ˜ao em uma Mem ´oria
Transacional com Suporte em Software . . . 32
2.5 Considerac¸ ˜oes Finais do Cap´ıtulo . . . 33
3 AMBIENTE DE AVALIAC¸ ˜AO . . . . 34
3.1 Phase-Change Memory - Multicore Simulator (PCM-MS) . . . 34
3.1.1 Hierarquia de Mem ´oria . . . 35
3.1.2 Limitac¸ ˜oes . . . 35
3.2 Pintools . . . 36
3.3 Eigenbench . . . 36
3.4 STAMPBenchmark . . . 37
3.4.1 Bayes . . . 38
3.4.2 Genome . . . 38
3.4.3 Intruder . . . 38
3.4.4 Kmeans . . . 38
3.4.5 Labyrinth . . . 39
3.4.6 SSCA2 . . . 39
3.4.7 Vacation . . . 39
3.4.8 Yada . . . 39
3.5 Considerac¸ ˜oes Finais do Cap´ıtulo . . . 40
4 CARACTERIZAC¸ ˜AO DOS VERSIONAMENTOS DE DADOS . . . . 41
4.1 Configurac¸ ˜oes dos Experimentos . . . 41
4.2 Scalability . . . 42
4.3 Contention . . . 44
4.4 Density . . . 45
4.5 Transaction Length . . . 46
4.6 Temporal Locality . . . 46
4.7 Pollution . . . 47
4.8 Predominance . . . 48
4.9 Working-set . . . 48
4.10 Discuss ˜ao . . . 49
5 CARACTERIZAC¸ ˜AO DOS PADR ˜OES DE ACESSO `A MEM ´ORIA . . . . 50
5.1 Configurac¸ ˜oes dos Experimentos . . . 51
5.2 Acessos `a Mem ´oria . . . 52
5.3 Acessos `a Mem ´oria Principal (PCM) . . . 57
5.4 Bits Alterados na PCM . . . 65
5.5 Consumo de Energia . . . 72
5.6 Discuss ˜ao . . . 73
6 CONCLUS ˜AO . . . . 75
6.1 Publicac¸ ˜oes . . . 76
6.2 Trabalhos Futuros . . . 77
REFER ˆENCIAS . . . . 78
AP ˆENDICE A RESULTADOS SCALABILITY . . . . 83
AP ˆENDICE C RESULTADOS DENSITY . . . . 85
AP ˆENDICE D RESULTADOS TRANSACTION LENGHT . . . . 86
AP ˆENDICE E RESULTADOS TEMPORAL LOCALITY . . . . 87
AP ˆENDICE F RESULTADOS POLLUTION . . . . 88
AP ˆENDICE G RESULTADOS PREDOMINANCE . . . . 89
AP ˆENDICE H RESULTADOS WORKING-SET SIZE . . . . 90
AP ˆENDICE I RESULTADOS M ´EDIA DE ACESSOS `A MEM ´ORIA . . . . 91
AP ˆENDICE J RESULTADOS M ´EDIA DE LEITURAS NA PCM . . . . 94
AP ˆENDICE K RESULTADOS N ´UMERO DE ESCRITAS NA PCM . . . . 97
AP ˆENDICE L RESULTADOS N ´UMERO DE BITS ALTERADOS NA PCM . . 100
AP ˆENDICE M RESULTADOS DO CONSUMO DE ENERGIA . . . . 103
AP ˆENDICE N RESULTADOS N ´UMERO DE TRANSAC¸ ˜OES . . . . 106
AP ˆENDICE O RESULTADOS N ´UMERO DEABORTS . . . . 109 AP ˆENDICE P RESULTADOS TAXAS DE HIT E MISS NOS N´IVEIS DE CACHE112
A efici ˆencia energ ´etica ´e crucial para o atual paradigma computacional, onde dis- positivos pessoais m ´oveis ou personal mobile devices (PMD) servem como clientes para acesso `a computac¸ ˜ao em nuvem (PATTERSON; HENNESSY, 2013). Grandes data centers utilizam uma hierarquia onde a mem ´oria principal ´e implementada em tecnologia DRAM. Mem ´orias tradicionais (DRAM) representam entre 20% e 40% do consumo total de um servidor (XIA et al., 2015). Uma alternativa atraente para gran- desdata centers ´e a tecnologia PCM que surgiu como uma alternativa para o consumo proibitivo de energia em mem ´orias tradicionais (LEE et al., 2010). A n ˜ao volatilidade deste tipo de mem ´oria reduz o consumo est ´atico de pot ˆencia. Entretanto, as escritas s ˜ao lentas, pois o processo de armazenamento de um bit altera o estado do material da c ´elula de mem ´oria em quest ˜ao (LEE et al., 2010). Al ´em disso, escritas degradam o material, limitando a vida ´util deste tipo de mem ´oria.
A programac¸ ˜ao concorrente ´e uma ´area que vem ganhando espac¸o e import ˆancia na computac¸ ˜ao, devido aos computadores, que contam com m ´ultiplos processadores.
Isso favorece a programac¸ ˜ao concorrente, visto que ela pode explorar estes m ´ultiplos processadores de forma a melhorar o desempenho de um programa. Por ´em, um dos problemas da programac¸ ˜ao concorrente ´e a condic¸ ˜ao de corrida (SILBERSCHATZ, 2010), que consiste na situac¸ ˜ao em que v ´arias threads ou processos acessam e manipulam os mesmos dados concorrentemente e na qual o resultado da execuc¸ ˜ao depende da ordem espec´ıfica em que o acesso ocorre. A parte do programa que cont ´em os dados manipulados concorrentemente ´e chamada de sec¸ ˜ao cr´ıtica (SIL- BERSCHATZ, 2010). Para que n ˜ao ocorra a condic¸ ˜ao de corrida, podem ser utiliza- dos diferentes m ´etodos de controle de acesso `as mesmas. A sincronizac¸ ˜ao ´e feita para que ocorra a exclus ˜ao m ´utua, que consiste no princ´ıpio que se umathread est ´a manipulando os dados compartilhados dentro de uma sec¸ ˜ao cr´ıtica, nenhuma outra thread pode acessar a mesma sec¸ ˜ao cr´ıtica. Existem v ´arios m ´etodos que fazem a sincronizac¸ ˜ao, entre eles as mem ´orias transacionais.
As mem ´orias transacionais (HERLIHY; ELIOT; MOSS, 1993) outransactional me- mories (TM) s ˜ao uma alternativa para sincronizac¸ ˜ao de threads. Mem ´orias transa-
cionais s ˜ao baseadas em transac¸ ˜oes de banco de dados. A principal vantagem em relac¸ ˜ao `as alternativas convencionais (baseadas emlocks) ´e a maior simplicidade ao escrever o c ´odigo. Outra vantagem das mem ´orias transacionais em comparac¸ ˜ao com locks ´e a inexist ˆencia do problema de deadlock. A composic¸ ˜ao de componentes de software tamb ´em ´e mais simples, aumentando a reusabilidade do c ´odigo. Por es- sas e outras vantagens, mem ´orias transacionais s ˜ao uma alternativa promissora para a escrita de c ´odigo port ´avel e escal ´avel em mem ´oria compartilhada (MORESHET;
BAHAR; HERLIHY, 2006). Primeiramente foram pensadas para serem desenvolvidas em hardware (HTM), mas acabaram ganhando mais popularidade quando desenvol- vidas em software (STM).
Como descrito anteriormente, mem ´orias transacionais s ˜ao baseadas nas transac¸ ˜oes de banco de dados. As transac¸ ˜oes em sistemas de banco de dados satis- fazem quatro propriedades: atomicidade, consist ˆencia, isolamento e durabilidade. Es- sas propriedades podem ser resumidas na sigla ACID. As transac¸ ˜oes das mem ´orias transacionais tamb ´em devem garantir essas propriedades, exceto a durabilidade visto que n ˜ao ´e necess ´ario manter os dados por definitivo na mem ´oria. Para garantir a atomicidade, as mem ´orias transacionais implementam versionamento de dados para fazer o gerenciamento das vers ˜oes dos dados. Existem dois tipos de versionamento de dados: Versionamento Adiantado e Versionamento Atrasado. Esses dois tipos de versionamento se diferenciam na quest ˜ao de onde estar ´a o valor mais atualizado do dado durante a transac¸ ˜ao, esse valor poder ´a estar na mem ´oria (Versionamento Adi- antado) ou em umbuffer auxiliar (Versionamento Atrasado).
1.1 Motivac¸ ˜ao
Tanto mem ´orias transacionais quanto as mem ´orias PCM s ˜ao alternativas promis- soras em suas ´areas, programac¸ ˜ao concorrente (mem ´orias transacionais) e mem ´oria principal (mem ´oria PCM). As mem ´orias transacionais s ˜ao promissoras devido sua maior simplicidade ao escrever um c ´odigo que seja port ´avel e escal ´avel em mem ´oria compartilhada. J ´a a mem ´oria PCM ´e uma alternativa promissora devido a sua n ˜ao vo- latilidade, que reduz o consumo est ´atico de pot ˆencia, fazendo da mem ´oria PCM uma alternativa para o consumo proibitivo de energia em mem ´orias tradicionais.
Ent ˜ao, como mem ´orias transacionais e mem ´orias PCM s ˜ao alternativas promis- soras, analisar o impacto das diferentes implementac¸ ˜oes de versionamento de da- dos das mem ´orias transacionais (que s ˜ao os respons ´aveis pelo gerenciamento das vers ˜oes dos dados na mem ´oria) e ver qual prejudicaria menos a mem ´oria PCM ser ´a importante para prolongar a vida ´util da PCM.
1.2 Objetivos
O objetivo principal deste trabalho ´e analisar o impacto das diferentes implementac¸ ˜oes de versionamento de dados das mem ´orias transacionais em software nas mem ´orias PCM.
Os objetivos espec´ıficos s ˜ao:
1. Caracterizar os diferentes versionamentos de dados das STM;
2. Analisar o desgaste dos diferentes versionamentos de dados em uma mem ´oria PCM;
3. Analisar e caracterizar o consumo de energia dos diferentes versionamentos de dados em mem ´orias PCM; e
4. Apontar qual ´e a melhor opc¸ ˜ao de versionamento de dados para ser executado em uma mem ´oria PCM.
1.3 Metodologia
Esta sec¸ ˜ao descreve os passos metodol ´ogicos que foram realizados para o desen- volvimento deste trabalho.
1.3.1 Estudo e caracterizac¸ ˜ao dos versionamentos de dados implementados em STM
Primeiramente para o desenvolvimento deste trabalho foi necess ´ario estudar, ana- lisar e caracterizar os diferentes versionamentos de dados. Ent ˜ao foi feito um estudo sobre o comportamento de cada versionamento e uma caraterizac¸ ˜ao dos mesmos por meio da execuc¸ ˜ao de experimentos com a biblioteca de STM TinySTM e com o benchmark Eigenbench (HONG et al., 2010), que ´e um microbenchmark que faz uma avaliac¸ ˜ao ortogonal das caracter´ısticas de aplicac¸ ˜oes que formam a base para o comportamento transacional. Ele foi ´util para compreens ˜ao do comportamento dos diferentes versionamentos. O Eigenbench em seu site oficial n ˜ao tem uma vers ˜ao para a TinySTM, ent ˜ao foi feita a portabilidade do Eigenbench para a TinySTM.
1.3.2 Implementac¸ ˜ao do simulador
Para fazer a simulac¸ ˜ao foi implementado um simulador de hierarquia de mem ´oria, com a mem ´oria principal sendo a mem ´oria PCM. O simulador recebe arquivos de trac¸o com os acessos `a mem ´oria e faz a simulac¸ ˜ao. Uma caracter´ıstica deste simulador ´e que ele pode ser utilizado por programas multithread, onde cada thread ter ´a um ar- quivo de trac¸o. Para gerar os arquivos de trac¸o foi utilizada a ferramenta Pintools (LUK et al., 2005). O simulador ser ´a descrito no Cap´ıtulo 3.
1.3.3 Comparac¸ ˜ao dos diferentes versionamentos de dados em relac¸ ˜ao ao im- pacto em uma mem ´oria PCM
Por fim para fazer a comparac¸ ˜ao dos diferentes versionamentos de dados, foram feitas execuc¸ ˜oes com o simulador, onde para cada conjunto de testes (benchmark- versionamento), foram feitas 30 execuc¸ ˜oes e calculada a m ´edia aritm ´etica dos resul- tados. Para analisar o desgaste em uma mem ´oria PCM, foi analisado o n ´umero de bits alterados na mem ´oria principal (mem ´oria PCM). Tamb ´em foi feito um c ´alculo do consumo de energia da mem ´oria PCM nos diferentes experimentos.
1.4 Estrutura do Texto
O trabalho que segue est ´a organizado da seguinte forma: o Cap´ıtulo 2 apresenta os conceitos e o funcionamento da PCM, das mem ´orias transacionais e da biblioteca de STM TinySTM. No Cap´ıtulo 3 ´e apresentado o ambiente de avaliac¸ ˜ao do trabalho.
O Cap´ıtulo 4 apresenta a caracterizac¸ ˜ao dos versionamento de dados. O Cap´ıtulo 5 discute os resultados da caracterizac¸ ˜ao dos acessos `a mem ´oria e o impacto na PCM.
E por fim, o Cap´ıtulo 6 apresenta as considerac¸ ˜oes finais e os trabalhos futuros.
2.1 Phase-Change Memory
APhase-Change Memory (PCM) ´e uma mem ´oria n ˜ao-vol ´atil que surgiu como uma alternativa para o consumo proibitivo de energia em mem ´orias tradicionais, para subs- tituir em grande parte as mem ´orias DRAM (FERREIRA et al., 2010). Isto se d ´a pelo seu custo-benef´ıcio e a sua efici ˆencia em relac¸ ˜ao ao consumo de energia. A PCM utiliza-se das fases de seu material para armazenar dados. A temperatura ´e a res- pons ´avel por induzir a mudanc¸a de fase do material.
2.1.1 Escritas
As escritas, na PCM, s ˜ao custosas, pois elas s ˜ao aproximadamente 5 a 10 vezes mais lentas e consomem 10 vezes mais energia que as leituras (RAOUX et al., 2008).
Elas s ˜ao feitas da seguinte forma: um pulso de corrente passa pelo material, fazendo com que ele fique em um estado amorfo ou em um estado cristalino (LEE et al., 2010).
Cada uma das estruturas tem resist ˆencias el ´etricas diferentes sendo poss´ıvel, assim, armazenar com precis ˜ao o valor de um bit. Segue a descric¸ ˜ao de como ocorre um Reset e umSet na mem ´oria PCM.
• Reset: para que ocorra oReset ´e induzido um alto e curto pulso de corrente, que
´e interrompido abruptamente, fazendo com que a resistividade do material au- mente. Ao extinguir rapidamente a gerac¸ ˜ao de calor, o material torna-se amorfo.
• Set: para que ocorra o Set, ´e induzido um pulso moderado e longo de corrente, o que faz com que a resistividade do material seja reduzida, assim fazendo com que o material esfrie gradualmente e mude para um estado cristalino.
2.1.2 Leituras
No in´ıcio de uma leitura, obitline ´e carregado com a voltagem correspondente. Se a c ´elula selecionada da PCM est ´a em um estado cristalino, o bitline ´e descarregado com a corrente fluindo atrav ´es do elemento de armazenamento e acessando o tran- sistor. Se a c ´elula est ´a em um estado amorfo, a corrente do bitline ´e impedida ou
limitada (QURESHI; SRINIVASAN; RIVERS, 2009). Com isso ´e poss´ıvel diferenciar os dois estados, e assim diferenciar o bit 0 do bit 1.
2.1.3 Limitac¸ ˜oes da PCM
O principal problema da PCM s ˜ao suas escritas que, al ´em de serem lentas, tamb ´em desgastam o material (LEE et al., 2010). Como a escrita desgasta o ma- terial, o tempo de vida da PCM ´e ordens de grandeza menor que outras alternativas de armazenamento. A Figura 1 compara oReset, oSet e a leitura (Read) em relac¸ ˜ao ao tempo e a corrente. Como pode ser visto o Reset requer um pulso de corrente mais alto, ent ˜ao ´e ele quem determina a pot ˆencia da escrita. J ´a o tempo de escrita ´e dado peloSet (WANG; WU, 2009), que tem uma corrente menor mas com um tempo mais prolongado. O tempo e a corrente das leituras s ˜ao muito menores que o tempo e a corrente doReset e doSet.
Figura 1: Comparac¸ ˜ao entre oReset, o Set e a leitura (Read). Fonte: (WANG; WU, 2009).
2.1.4 Sistemas de Mem ´oria com PCM
Segundo Xia et al. (2015), existem tr ˆes alternativas de sistema de mem ´oria onde a PCM ´e a mem ´oria principal. Essas alternativas podem ser vistas na Figura 2. A pri- meira alternativa ´e substituir a DRAM pela PCM, como mostra a Figura 2a. A segunda alternativa ´e utilizar a PCM e a DRAM em paralelo, em uma arquitetura h´ıbrida, como mostra a Figura 2b. E por fim a terceira alternativa tamb ´em ´e uma alternativa h´ıbrida, com PCM e DRAM em paralelo, mas nesse caso a DRAM ´e utilizada como cache ou buffer da PCM, como mostra a Figura 2c. As alternativas de mem ´oria principal h´ıbridas permitem que as aplicac¸ ˜oes explorem as vantagens tanto da PCM como da DRAM, sendo ent ˜ao as mais estudadas.
(a) (b) (c)
Figura 2: Alternativas de sistemas de mem ´oria com mem ´oria PCM. Fonte: (XIA et al., 2015)
2.2 Mem ´ orias Transacionais
Mem ´orias transacionais (HERLIHY; ELIOT; MOSS, 1993) s ˜ao uma alternativa para sincronizac¸ ˜ao de threads. TMs s ˜ao baseadas em transac¸ ˜oes de banco de dados e fornecem uma execuc¸ ˜ao at ˆomica e isolada de alterac¸ ˜oes em um conjunto de dados compartilhados. As vantagens das TMs s ˜ao em relac¸ ˜ao a simplicidade de escrita de c ´odigo e a inexist ˆencia dedeadlocks (MORESHET; BAHAR; HERLIHY, 2006).
Primeiramente, TMs foram pensadas para serem desenvolvidas em hard- ware (HTM), mas acabaram ganhando mais popularidade quando desenvolvidas em software (STM). Grandes empresas como Intel e IBM acabaram investindo em mem ´orias transacionais suportadas em hardware (HAMMARLUND et al., 2014;
SHUM; BUSABA; JACOBI, 2013; LE et al., 2015; CLICK, 2009; DICE et al., 2009).
TMs tamb ´em podem ser implementadas em uma vers ˜ao h´ıbrida. Este trabalho aborda implementac¸ ˜oes de TMs emsoftware.
Na programac¸ ˜ao utilizando STMs, todo o acesso `a mem ´oria compartilhada ´e rea- lizado dentro de transac¸ ˜oes e todas as transac¸ ˜oes s ˜ao executadas atomicamente em relac¸ ˜ao a transac¸ ˜oes concorrentes.
2.2.1 Propriedades
Transac¸ ˜ao ´e uma sequ ˆencia finita de escritas e leituras na mem ´oria, executada por umathread (HERLIHY; ELIOT; MOSS, 1993), e que deve satisfazer tr ˆes propriedades:
• Atomicidade: cada transac¸ ˜ao faz uma sequ ˆencia de mudanc¸as provis ´orias na mem ´oria compartilhada. Quando a transac¸ ˜ao ´e conclu´ıda, pode ocorrer umcom-
mit, tornando suas mudanc¸as vis´ıveis a outras threads instantaneamente, ou pode ocorrer umabort, fazendo com que suas alterac¸ ˜oes sejam descartadas.
• Consist ˆencia: transac¸ ˜oes devem garantir que um sistema que era consistente deve ser mantido consistente. Essa ´e a propriedade relacionada com o conceito de invari ˆancia.
• Isolamento: transac¸ ˜oes n ˜ao interferem na execuc¸ ˜ao de outras transac¸ ˜oes, as- sim parecendo que elas s ˜ao executadas serialmente. Uma transac¸ ˜ao n ˜ao ob- serva o estado intermedi ´ario de outra.
2.2.2 Versionamento de Dados
O versionamento de dados faz o gerenciamento das vers ˜oes dos dados. Ele ar- mazena tanto o valor do dado no in´ıcio de uma transac¸ ˜ao como tamb ´em o valor do dado modificado durante a transac¸ ˜ao, isso para garantir a propriedade de atomici- dade (BALDASSIN, 2009).
Figura 3: Exemplo de versionamento adiantado (a) e atrasado (b). Fonte: (BALDAS- SIN, 2009)
Existem dois tipos de versionamento de dados, s ˜ao eles:
• Versionamento Adiantado: como pode ser visto na Figura 3 (a), o valor modi- ficado durante a transac¸ ˜ao ´e armazenado direto na mem ´oria e o valor inicial ´e armazenado em um undo log, para que no caso de cancelamento na transac¸ ˜ao o valor inicial seja restaurado na mem ´oria.
• Versionamento Atrasado: como pode ser visto na Figura 3 (b) neste versiona- mento o valor modificado durante a transac¸ ˜ao ´e armazenado em um buffer e o valor inicial ´e mantido na mem ´oria at ´e que acontec¸a um commit na transac¸ ˜ao,
onde o valor armazenado no buffer ´e escrito na mem ´oria. Caso acontec¸a o cancelamento na transac¸ ˜ao, o valor dobuffer ´e descartado.
O versionamento de dados em mem ´orias transacionais desenvolvidas em software, que ´e o foco deste trabalho, necessitam de dois conceitos, a aquisic¸ ˜ao de escrita e o versionamento. A aquisic¸ ˜ao de escrita pode ser de dois tipos, bloqueante ou n ˜ao blo- queante (MARATHE; MOIR, 2007). A biblioteca utilizada neste trabalho, a TinySTM, implementa a aquisic¸ ˜ao de escrita bloqueante. No caso da TinySTM, o privil ´egio de escrita ´e a aquisic¸ ˜ao dolock referente ao enderec¸o que ser ´a escrito. Na aquisic¸ ˜ao de escrita bloqueante, a transac¸ ˜ao pode adquirir o privil ´egio de escrita em dois momen- tos: em seguida que ocorre uma escrita ou no final da transac¸ ˜ao. J ´a o versionamento descreve onde ser ´a feita esta escrita, diretamente na mem ´oria (versionamento adi- antado) ou primeiramente em um buffer (versionamento atrasado). Com isso, STM podem ter at ´e tr ˆes tipos de versionamentos:
• Com aquisic¸ ˜ao do privil ´egio no momento que ocorre uma escrita e versiona- mento adiantado;
• Com aquisic¸ ˜ao do privil ´egio no momento que ocorre uma escrita e versiona- mento atrasado; e
• Com aquisic¸ ˜ao do privil ´egio no final de uma transac¸ ˜ao e versionamento atrasado.
N ˜ao existe a possibilidade de ter a aquisic¸ ˜ao do privil ´egio no final de uma transac¸ ˜ao e versionamento adiantado, devido `as transac¸ ˜oes terem que manter o controle das escritas para garantir a consist ˆencia do sistema.
2.2.3 Detecc¸ ˜ao de Conflito
Mecanismos de detecc¸ ˜ao de conflitos verificam a exist ˆencia de operac¸ ˜oes con- flitantes durante uma transac¸ ˜ao. Um conflito ocorre quando duas transac¸ ˜oes est ˜ao acessando um mesmo dado na mem ´oria e pelo menos uma das transac¸ ˜oes est ´a fa- zendo uma operac¸ ˜ao de escrita (BALDASSIN, 2009).
Da mesma forma que o versionamento de dados, a detecc¸ ˜ao de conflito tamb ´em pode ser de dois tipos:
• Detecc¸ ˜ao de Conflitos Adiantada: este tipo de detecc¸ ˜ao ocorre no momento que duas transac¸ ˜oes acessam um mesmo dado e uma delas faz uma operac¸ ˜ao de escrita. Essa operac¸ ˜ao de escrita ´e detectada e ent ˜ao uma transac¸ ˜ao ´e abor- tada. Neste tipo de detecc¸ ˜ao pode ocorrer um problema chamado de livelock, quando duas transac¸ ˜oes ficam se cancelando. Desta forma, a execuc¸ ˜ao do pro- grama n ˜ao progride. A Figura 4 mostra como ´e feita a detecc¸ ˜ao de conflitos adiantada.
O Caso 1 mostra a execuc¸ ˜ao sem conflitos, no qual as duas transac¸ ˜oes s ˜ao exe- cutadas sem problemas. J ´a no Caso 2, mostra-se o que acontece quando ocorre um conflito, no caso T1 l ˆe A e logo depois T2 escreve em A, ent ˜ao o conflito ´e detectado e T1 ´e abortada. Logo depois de ser efetivada T2, a transac¸ ˜ao T1 consegue ler A sem problema de conflito. Por fim, o Caso 3 mostra a situac¸ ˜ao de livelock, onde as duas transac¸ ˜oes tentam ler e escrever em A mas ambas acabam sempre abortando.
Figura 4: Detecc¸ ˜ao de conflitos em modo adiantado. Fonte: (RIGO; CENTODUCATTE;
BALDASSIN, 2007)
• Detecc¸ ˜ao de Conflitos Atrasada: Este tipo de detecc¸ ˜ao de conflito ocorre no final da transac¸ ˜ao. Antes da transac¸ ˜ao ser completada, verifica-se se ocorreu um conflito. Caso tenha ocorrido, a transac¸ ˜ao ´e cancelada, sen ˜ao ´e efetivada. Para transac¸ ˜oes muito grandes n ˜ao ´e recomendado este tipo de detecc¸ ˜ao, pois uma transac¸ ˜ao grande pode ser abortada v ´arias vezes por transac¸ ˜oes pequenas, as- sim gastando tempo de processamento desnecess ´ario, este problema se chama starvation. A Figura 5 mostra como ´e feita a detecc¸ ˜ao de conflitos atrasada.
No Caso 1 mostra-se as transac¸ ˜oes acessando dados diferentes, n ˜ao ocasio- nando conflitos. No Caso 2, T2 l ˆe A que ´e escrita por T1. A T2 s ´o nota o conflito quando T1 ´e efetivado. Logo depois de notar o conflito T2 ´e abortada. No Caso 3 n ˜ao ocorre nenhum conflito, pois T1 l ˆe A antes de T2 escrever. O Caso 4 mostra a situac¸ ˜ao em que, ap ´os ser cancelada, T1 volta a executar.
Para solucionar o problema de qual transac¸ ˜ao continuar ´a executando, quando ocorre um conflito, ´e utilizado um gerenciador de contenc¸ ˜ao (HARRIS; LARUS;
RAJWAR, 2010). O gerenciador de contenc¸ ˜ao ´e o respons ´avel por decidir quando e qual transac¸ ˜ao vai ser abortada, isso para garantir que a execuc¸ ˜ao do programa prossiga sem problemas.
Figura 5: Detecc¸ ˜ao de conflitos em modo atrasado. Fonte: (RIGO; CENTODUCATTE;
BALDASSIN, 2007)
2.3 TinySTM
A TinySTM (FELBER; FETZER; RIEGEL, 2008) ´e uma implementac¸ ˜ao de STM para as linguagens C e C++. Seu algoritmo ´e baseado em outros algoritmos de STM como o TL2 (DICE; SHALEV; SHAVIT, 2006). Ela ´e uma biblioteca utilizada para escre- ver aplicativos que usam mem ´orias transacionais para sincronizac¸ ˜ao, em substituic¸ ˜ao aos tradicionaislocks.
2.3.1 Sincronizac¸ ˜ao e Versionamento
Na TinySTM a sincronizac¸ ˜ao ´e feita a partir de um array de locks compartilhado que gerencia o acesso concorrente `a mem ´oria. Cadalock bloqueia v ´arios enderec¸os de mem ´oria, como pode ser visto na Figura 6. O mapeamento ´e feito por meio de uma func¸ ˜aohash.
Figura 6: Como ´e feita a sincronizac¸ ˜ao natinySTM. Fonte: (FELBER; FETZER; RIE- GEL, 2008)
ATinySTM apresenta tr ˆes diferentes estrat ´egias de versionamento, s ˜ao elas:
• WRITE BACK ETL: esta estrat ´egia implementa o versionamento atra- sado (write-back) com encounter-time locking, onde o lock ´e adquirido quando ocorre uma operac¸ ˜ao de escrita. O valor somente ´e escrito na mem ´oria no mo- mento docommit da transac¸ ˜ao.
• WRITE BACK CTL: esta estrat ´egia implementa o versionamento atra- sado (write-back) comcommit-time locking, onde olock ´e adquirido no momento da efetivac¸ ˜ao da transac¸ ˜ao (commit). Assim como oWRITE BACK ETL, o valor somente ´e escrito na mem ´oria no momento do commit da transac¸ ˜ao.
• WRITE THROUGH: esta estrat ´egia implementa o versionamento adian- tado (write-through) comencounter-time locking. A atualizac¸ ˜ao ´e realizada dire- tamente na mem ´oria e umundo log ´e mantido para o caso deabortna transac¸ ˜ao.
A estrat ´egia de versionamento padr ˜ao utilizada pela TinySTM ´e a WRITE BACK ETL.
2.3.2 Escritas
Nos versionamentos com aquisic¸ ˜ao do lock no momento que ocorre uma es- crita (WRITE BACK ETLeWRITE THROUGH), a transac¸ ˜ao primeiro identifica olock correspondente ao enderec¸o de mem ´oria e atomicamente l ˆe o valor da mem ´oria.
Se o lock est ´a em uso a transac¸ ˜ao verifica se ´e a propriet ´aria do lock. Caso posi- tivo, ent ˜ao ela simplesmente escreve o novo valor, em um buffer (caso seja o ver- sionamento WRITE BACK ETL) ou direto na mem ´oria (caso seja o versionamento WRITE THROUGH), e retorna. Caso contr ´ario, a transac¸ ˜ao pode esperar por al- gum tempo ou abortar imediatamente. A TinySTM utiliza a ´ultima opc¸ ˜ao em sua implementac¸ ˜ao.
Se olock n ˜ao est ´a em uso, a transac¸ ˜ao tenta adquiri-lo para escrever o novo valor na entrada utilizando uma operac¸ ˜ao at ˆomica compare-and-swap. A falha indica que outra transac¸ ˜ao adquiriu olock nesse meio tempo, ent ˜ao a transac¸ ˜ao ´e reiniciada.
Para o versionamento com aquisic¸ ˜ao do lock no final da transac¸ ˜ao (WRITE BACK CTL), a transac¸ ˜ao primeiramente verifica se essa ´e a primeira escrita, que ela efetua, no enderec¸o. Caso positivo, ´e alocada uma posic¸ ˜ao no buffer para se efetivada a escrita. Caso contr ´ario, a posic¸ ˜ao do buffer correspondente ao enderec¸o da escrita ´e atualizada.
2.3.3 Leituras
Quando ocorre uma leitura na mem ´oria, a transac¸ ˜ao deve verificar se o lock est ´a em uso ou se o valor j ´a foi atualizado concorrentemente por outra transac¸ ˜ao. Para esse
fim, a transac¸ ˜ao l ˆe olockcorrespondente ao enderec¸o de mem ´oria. Se olock n ˜ao tem propriet ´ario e o valor (n ´umero de vers ˜ao) n ˜ao foi modificado entre duas leituras, ent ˜ao o valor ´e consistente.
2.3.4 Gerenciamento de Mem ´oria
ATinySTM utiliza um gerenciador de mem ´oria que possibilita qualquer c ´odigo tran- sacional utilizar mem ´oria din ˆamica. As transac¸ ˜oes mant ´em o enderec¸o da mem ´oria alocada ou liberada. A alocac¸ ˜ao de mem ´oria ´e automaticamente desfeita quando a transac¸ ˜ao ´e abortada. J ´a a liberac¸ ˜ao n ˜ao pode ser desfeita antes do commit. Con- tudo, uma transac¸ ˜ao pode somente liberar a mem ´oria depois de adquirir todos os locks. Umfree ´e semanticamente equivalente a uma atualizac¸ ˜ao.
2.3.5 Gerenciador de Contenc¸ ˜ao
A TinySTM implementa quatro estrat ´egias de gerenciamento de contenc¸ ˜ao, s ˜ao elas:
• CM SUICIDE: nesta estrat ´egia a transac¸ ˜ao que detecta o conflito ´e abortada imediatamente.
• CM DELAY: parecido com a estrat ´egia CM SUICIDE, mas espera at ´e a transac¸ ˜ao, que est ´a em posse do lock, tenha liberado olock antes de reiniciar a transac¸ ˜ao. Isso porque a transac¸ ˜ao que foi abortada ir ´a provavelmente tentar ad- quirir o mesmolock novamente e talvez falhe mais de uma vez caso olock n ˜ao tenha sido liberado. Al ´em disso, essa estrat ´egia aumenta as chances de que a transac¸ ˜ao tenha sucesso sem precisar abortar muitas vezes, o que melhora o tempo de execuc¸ ˜ao do processador.
• CM BACKOFF: tamb ´em parecida com a estrat ´egiaCM SUICIDE, por ´em espera por um tempo, rand ˆomico, para reiniciar a transac¸ ˜ao. A durac¸ ˜ao deste atraso
´e escolhido uniformemente ao acaso em um intervalo cujo tamanho aumenta exponencialmente a cada reinicializac¸ ˜ao.
• CM MODULAR: esta estrat ´egia implementa v ´arios gerenciadores de contenc¸ ˜ao, que s ˜ao alternados durante a execuc¸ ˜ao. Os gerenciadores utilizados s ˜ao:
– SUICIDE: a transac¸ ˜ao que descobriu o conflito ´e abortada.
– AGGRESSIVE: a transac¸ ˜ao que ´e abortada ´e a outra, e n ˜ao a que descobriu o conflito.
– DELAY: a mesma coisa que aSUICIDE mas espera pela resoluc¸ ˜ao do con- flito antes de reiniciar a transac¸ ˜ao.
– TIMESTAMP: a transac¸ ˜ao mais nova ´e abortada.
O gerenciador de contenc¸ ˜ao utilizado neste trabalho foiCM SUICIDE, que ´e a es- trat ´egia de gerenciamento de contenc¸ ˜ao padr ˜ao daTinySTM.
2.4 Trabalhos Relacionados
Esta Sec¸ ˜ao apresenta trabalhos que levam em considerac¸ ˜ao o aumento de tempo
´util de uma mem ´oria PCM e a diminuic¸ ˜ao do seu desgaste.
2.4.1 Analyzing the Impact of Useless Write-Backs on the Endurance and Energy Consumption of PCM Main Memory
Bock et al. (2011) abordam a t ´ecnica Useless Write-Backs que consiste em n ˜ao escrever na PCM dados que n ˜ao ser ˜ao mais utilizados na execuc¸ ˜ao do programa, assim evitando fazer escritas desnecess ´arias na PCM. Eles apresentam o impacto que os write-backs in ´uteis tem sobre a durabilidade e consumo de energia dos sistemas baseados em mem ´oria principal PCM e implementa t ´ecnicas que evitam estes write- backs.
O trabalho apresenta um framework que mede o n ´umero de write-backs in ´uteis na PCM para tr ˆes diferentes tipos de regi ˜oes de mem ´oria e apresenta um mo- delo energ ´etico para determinar o m ´aximo de economia de energia que poderia ser alcanc¸ados atrav ´es de um regime deste tipo. S ˜ao algoritmos diferentes para cada regi ˜ao da mem ´oria, pois para cada uma delas, analisar se uma posic¸ ˜ao de mem ´oria n ˜ao ser ´a mais usada ´e diferente.
Oframework implementado funciona da seguinte forma, primeiramente o programa passa por uma instrumentac¸ ˜ao que gera um arquivo de trac¸o com os enderec¸os e ti- pos de cada refer ˆencia de mem ´oria, assim como outras informac¸ ˜oes exigidas pelo tipo espec´ıfico de regi ˜ao de mem ´oria que est ´a sendo analisado, em seguida o arquivo de trac¸o passa por um analisador que consiste de um simulador de cache, rotinas de an ´alise e estruturas de dados que mant ˆem informac¸ ˜ao sobre zonas mortas de mem ´oria, por fim com a sa´ıda do analisador s ˜ao feitos c ´alculos que mostram a econo- mia de energia e o aumento da durabilidade da mem ´oria PCM.
Os testes feitos para este trabalho utilizaram o conjunto de benchmarks SPEC2006 (HENNING, 2006) e mostraram que, evitandowrite-backs in ´uteis se pode economizar at ´e 19,8% de energia e melhorar a durabilidade de uma mem ´oria PCM em at ´e 26,2%.
2.4.2 Bit Mapping for Balanced PCM Cell Programming
Du et al. (2013) prop ˜oem o double XOR mapping (D-XOR) para fazer uma distribuic¸ ˜ao dos bits modificados entre grupos de c ´elulas da mem ´oria PCM de forma balanceada.
Primeiramente, foram analisados padr ˜oes de ciclos e agrupamentos de bits mo- dificados nas escritas. Em seguida, os autores propuseram o D-XOR para fazer o balanceamento do desgaste das c ´elulas de PCM e diminuir o tempo de escrita.
Nos resultados os autores mostraram que o D-XOR pode diminuir em m ´edia at ´e 45% do tempo de escrita, isso fez com que othroughput fosse aumentado1,8×.
2.4.3 An ´alise de desgaste de t ´ecnicas de correc¸ ˜ao de erros em Phase-Change Memories
Hoffman (2013) analisa, com uma modelagem matem ´atica, como a probabilidade debit-flipest ´a relacionada com a durabilidade das mem ´orias PCM, para os principais c ´odigos de correc¸ ˜ao de erros (paridade, SECDED e BCH) e das principais t ´ecnicas de recuperac¸ ˜ao de falhas (ECP e SAFER).
Para desenvolver este trabalho o autor fez os experimentos de modelagem da probabilidade de bit-flip, para t ´ecnicas de correc¸ ˜ao de erros e, por fim, dos modelos anal´ıticos.
Nos resultados, o autor apresentou que ocorreu uma vis´ıvel degradac¸ ˜ao da dura- bilidade dos mecanismos de recuperac¸ ˜ao de falhas que usam c ´odigos de correc¸ ˜ao de erros. Um destaque dos resultados foi a t ´ecnica ECP que foi a ´unica que n ˜ao mostrou degradac¸ ˜ao da PCM. Tamb ´em foi feita uma an ´alise de efici ˆencia energ ´etica, relaci- onando a durabilidade da PCM e o consumo de energia onde novamente, a t ´ecnica ECP se destacou nos resultados, como tamb ´em a t ´ecnica SAFER. Por fim, o traba- lho apresenta modelos anal´ıticos probabil´ısticos das t ´ecnicas ECP, SECDED e uma an ´alise da t ´ecnica PAYG baseada no modelo anal´ıtico da ECP, que foram proposto pelo autor.
2.4.4 Curling-PCM: Application-Specific Wear Leveling for Phase Change Me- mory based Embedded Systems
Liu et al. (2013) centram-se na gest ˜ao da PCM em sistemas embarcados, e prop ˜oem uma t ´ecnica de nivelamento de desgaste simples, mas eficaz para esten- der o tempo de vida de sistemas embarcados baseados em PCM.
A ideia b ´asica deste trabalho ´e mover periodicamente ´areas que ocorreram muitas escritas, que s ˜ao identificados pelos padr ˜oes de aplicac¸ ˜ao de escrita em todo o chip PCM, e distribuir as escritas uniformemente de modo que o nivelamento de desgaste pode ser melhorado. O trabalho apresenta duas implementac¸ ˜oes a full curling e a partial curling.
Os experimentos destes trabalho focaram em analisar o n ´umero debit-flipsna PCM e o tempo de resposta das implementac¸ ˜oes. Os resultados mostraram que o n ´umero total debit-flipscom as implementac¸ ˜oes aumentou, mas o n ´umero m ´aximo debit-flips em uma c ´elula de PCM diminuiu. Em relac¸ ˜ao ao tempo de resposta opartial curling
reduziu em at ´e 77% em relac¸ ˜ao aofull curling.
2.4.5 A three-stage-write scheme with flip-bit for PCM main memory
Li et al. (2015) apresentam um esquema de escrita de tr ˆes fases, cujo o objetivo ´e reduzir o n ´umero de bits alterados e a lat ˆencia de gravac¸ ˜ao para a PCM.
Este trabalho combina as ideias do Flip-N-Write (CHO; LEE, 2009) e da pol´ıtica de dois est ´agios de escrita (YUE; ZHU, 2013). O esquema de tr ˆes fases compara os dados antigos e os novos e os novos dados s ˜ao reorganizados de forma que minimize o n ´umero de bits alterados. Em seguida, todos os bits alterados s ˜ao divididos em novos bits 0 e novos bits 1 e s ˜ao atualizados separadamente para evitar o desperd´ıcio de tempo de escritas mistas.
Os resultados dos experimentos mostraram que o esquema proposto diminui 43,5% as mudanc¸as de bit, 16,6% o tempo das escritas e 34,6% o consumo de energia das escritas em m ´edia.
2.4.6 Profiling Patterns of Bit Flipping for Software Transactional Memories No trabalho, Teixeiraet al (2014), ´e feita uma an ´alise dos padr ˜oes de escrita e de bits alterados do conjunto de benchmarks STAMP e seu impacto em uma mem ´oria PCM.
Para o trabalho o autor implementou uma instrumentac¸ ˜ao, com a ferramenta Pin- Tools, que conta cada escrita feita `a mem ´oria e tamb ´em faz uma avaliac¸ ˜ao de quantos bits foram modificados em cada escrita. A implementac¸ ˜ao foi feita da seguinte forma:
a cada escrita na mem ´oria ´e incrementado um contador, que contabiliza o n ´umero de escritas. Tamb ´em ´e armazenado o enderec¸o de mem ´oria que est ´a sendo escrita e o valor que ser ´a escrito nela. Com o enderec¸o de mem ´oria ´e obtido o valor atual que est ´a armazenado em um vetor e ´e feita uma comparac¸ ˜ao com o valor que ser ´a escrito naquele enderec¸o, de modo a verificar quantos bits foram modificados. Essa comparac¸ ˜ao ´e feita em tempo de execuc¸ ˜ao. Logo depois de fazer essa comparac¸ ˜ao, o vetor ´e atualizado com o valor escrito.
Os resultados do trabalho mostraram alguns padr ˜oes nas escritas das STMs. Um destes foi que na maioria dos benchmarks quanto maior era o n ´umero de threads maior era o n ´umero de escritas, o n ´umero de bits alterados e o n ´umero de posic¸ ˜oes que foram escritas. Mas algunsbenchmarksmostraram um comportamento diferente.
Conforme aumentava o n ´umero de threads o n ´umero de escritas, o n ´umero de bits alterados e o n ´umero de posic¸ ˜oes que foram escritas variavam, o que pode ser justifi- cado em parte por suas implementac¸ ˜oes, par ˆametros escolhidos entre outras raz ˜oes.
2.4.7 An ´alise de Consumo de Energia e Desempenho de Mem ´orias Transacio- nais em Software em Ambiente de Computac¸ ˜ao Real
Rico (2013) analisa as bibliotecas de STM TL2, TinySTM, SwissTM e AdaptSTM, e faz uma an ´alise do consumo de energia e desempenho das STMs em ambiente de computac¸ ˜ao real, utilizando-se obenchmark STAMP.
No trabalho, o autor analisa o consumo de energia por meio de um microcontrola- dor especializado embutido na placa-m ˜ae, presente na maioria dos servidores, deno- minadoBaseboard Management Controller (BMC). Com isso, ele coletou o consumo de energia nas execuc¸ ˜oes de cada biblioteca de STM. Para a an ´alise do desempenho, cadabenchmark apresentava em sua sa´ıda o tempo de execuc¸ ˜ao, e esse tempo, foi utilizado para a an ´alise do desempenho.
Os resultados obtidos no trabalho mostram que a biblioteca SwissTM foi a mais eficiente em termos de consumo de energia e desempenho, seguida pela AdaptSTM, TinySTM e TL2. O autor constatou que a escalabilidade das STMs utilizadas est ´a relacionada diretamente `a particularidade das estrat ´egias de detecc¸ ˜ao e resoluc¸ ˜ao de conflitos empregada por cada biblioteca.
2.4.8 Experimentos com Gerenciamento de Contenc¸ ˜ao em uma Mem ´oria Tran- sacional com Suporte em Software
Uma comparac¸ ˜ao do desempenho de diferentes implementac¸ ˜oes de gerenciador de contenc¸ ˜ao pode ser visto no trabalho de Kronbauer e Rigo (2009). Este apre- senta uma abordagem nova para gerenciar a contenc¸ ˜ao entre transac¸ ˜oes, que leva em considerac¸ ˜ao os padr ˜oes de acesso aos diferentes dados de um programa ao escolher o gerenciador de contenc¸ ˜ao usado para o acesso a estes dados. Como bibli- oteca de STM, a RSTM (MARATHE et al., 2006) foi utilizada.
Para implementar esta abordagem proposta, os autores testaram algumas t ´ecnicas. Primeiramente eles testaram inserir um campo adicional em cada objeto transacional para denotar o gerenciador de contenc¸ ˜ao a ele associado, e fazer com que a transac¸ ˜ao detectasse qual gerenciador de contenc¸ ˜ao estava associado ao pri- meiro objeto aberto pela transac¸ ˜ao para utilizar este gerenciador pelo restante de sua execuc¸ ˜ao, mas esta t ´ecnica se mostrou invi ´avel visto o trabalho adicional inserido nos m ´etodos clone e redo. Outra t ´ecnica testada foi utilizar heranc¸a para introduzir o campo citado apenas em objetos transacionais espec´ıficos, mas ent ˜ao foi preciso utilizar convers ˜ao de tipos din ˆamica ao consultar o objeto a respeito de qual gerenci- ador de contenc¸ ˜ao estava associado a ele, o que pareceu ser outra fonte significante de trabalho adicional. Por fim, a t ´ecnica utilizada por eles neste trabalho foi permitir que o programador associe uma estrat ´egia de gerenciamento de contenc¸ ˜ao a cada transac¸ ˜ao.
Com os resultados os autores chegaram `a conclus ˜ao que conhecer o padr ˜ao
de acesso `as estruturas de dados e tamb ´em as configurac¸ ˜oes do hardware n ˜ao foi o suficiente para determinar os melhores gerenciadores de contenc¸ ˜ao para uso na aplicac¸ ˜ao, uma vez que os resultados mostraram alta variac¸ ˜ao nos diferentes siste- mas de computac¸ ˜ao testados.
2.5 Considerac¸ ˜ oes Finais do Cap´ıtulo
Este cap´ıtulo apresentou obackground deste trabalho. As caracter´ısticas e os con- ceitos da mem ´oria PCM, das mem ´orias transacionais e da biblioteca TinySTM foram discutidos. A TinySTM ´e uma implementac¸ ˜ao de STM para as liguagens C e C++.
Ela faz parte do estado da arte de mem ´orias transacionais e ´e uma das bibliotecas de STM mais utilizada nas pesquisas. Um dos motivos de utilizar a TinySTM neste trabalho ´e que os tr ˆes versionamentos poss´ıveis s ˜ao implementados.
A mem ´oria PCM ´e uma mem ´oria n ˜ao-vol ´atil que surgiu como alternativa `as DRAMs como mem ´oria principal em uma hierarquia de mem ´oria.
A grande vantagem da PCM est ´a em relac¸ ˜ao ao seu consumo de energia, j ´a que para manter os dados na mem ´oria n ˜ao precisa realizarrefresh. Apesar das vantagens, a PCM t ˆem problemas em relac¸ ˜ao a suas escritas, que al ´em de serem lentas ainda desgastam o seu material, diminuindo assim sua vida ´util.
As TMs garantem maior abstrac¸ ˜ao na codificac¸ ˜ao de programas concorrentes, pois possibilita uma programac¸ ˜ao de mais alto n´ıvel, onde o programador n ˜ao se preocupa com o modo como as sincronizac¸ ˜oes ser ˜ao feitas.
TMs implementam versionamentos de dados para garantir a atomicidade. O versi- onamento de dados em STM, que ´e o foco deste trabalho, necessitam de dois concei- tos, a aquisic¸ ˜ao de escrita e o versionamento. A aquisic¸ ˜ao de escrita pode ser de dois tipos, bloqueante ou n ˜ao bloqueante. Na aquisic¸ ˜ao de escrita bloqueante, a transac¸ ˜ao pode adquirir o privil ´egio de escrita em seguida que ocorre uma escrita ou no final da transac¸ ˜ao. J ´a o versionamento descreve onde ser ´a feita esta escrita, diretamente na mem ´oria (versionamento adiantado) ou primeiramente em um buffer (versionamento atrasado).
Por fim, conseguir prolongar a vida ´util da PCM ´e o grande desafio das pesquisas sobre PCM. Evitar a mudanc¸a de bits, al ´em de diminuir o consumo de energia, evita a degradac¸ ˜ao do material da PCM. Desta forma, este trabalho ter ´a uma abordagem de apresentar a opc¸ ˜ao de versionamento de dados das mem ´orias transacionais que provoque o menor desgaste de uma mem ´oria PCM.
Neste Cap´ıtulo ser ´a abordado o simulador implementado para este trabalho, o PCM-MS, assim como as ferramentas e osbenchmarks utilizados.
3.1 Phase-Change Memory - Multicore Simulator (PCM-MS)
OPhase-Change Memory - Multicore Simulator (PCM-MS) ´e um simulador de hi- erarquia de mem ´oria onde a PCM ´e a mem ´oria principal, e pode simular arquitetura com m ´ultiplos n ´ucleos de processamento. Ele faz a simulac¸ ˜ao dos acessos `a mem ´oria e determina os bits alterados na PCM para estimar seu desgaste e seu consumo de energia da PCM. Ele foi desenvolvido devido aos simuladores dispon´ıveis n ˜ao apre- sentarem em sua maioria a possibilidade de an ´alise dos bits, e tamb ´em devido a n ˜ao simularem arquiteturas com m ´ultiplos n ´ucleos de processamento. O PCM-MS foi de- senvolvido originalmente para este trabalho.
O PCM-MS utiliza arquivos de trac¸o para fazer a simulac¸ ˜ao dos acessos `a mem ´oria.
Na Figura 7 pode ser visto com ´e feita a gerac¸ ˜ao destes arquivos. Para gerar os ar- quivos, ´e feita uma instrumentac¸ ˜ao com a ferramenta Pintools na execuc¸ ˜ao dosben- chmarks. Essa instrumentac¸ ˜ao armazena os dados de acesso `a mem ´oria para assim poder gerar os arquivos de trac¸o.
Figura 7: Gerac¸ ˜ao dos Arquivos de Trac¸o
Na Figura 8 pode ser visto que o simulador PCM-MS recebe de entrada os arquivos de trac¸o e gera como sa´ıda os resultados da simulac¸ ˜ao. Partindo de um arquivo de trac¸o, onde est ˜ao ordenados os acessos `a mem ´oria, o PCM-MS faz a simulac¸ ˜ao. Na
execuc¸ ˜ao com m ´ultiplos n ´ucleos de processamento, existir ´a um arquivo de trac¸o para cadathread.
Figura 8: Entrada e Sa´ıda da Simulac¸ ˜ao com o PCM-MS
3.1.1 Hierarquia de Mem ´oria
A hierarquia de cacheno PCM-MS pode ser simulada em at ´e tr ˆes n´ıveis, sendo o n´ıvel L1 o mais pr ´oximo do n ´ucleo de processamento e o L3 o mais pr ´oximo do con- trolador de mem ´oria. Na Figura 9 pode ser visto como os n´ıveis de cache s ˜ao com- partilhados. Ascaches de n´ıvel L1 n ˜ao s ˜ao compartilhadas por mais que um n ´ucleo de processamento, ou seja, elas s ˜ao ´unicas para cada n ´ucleo de processamento. As caches de n´ıvel L2 s ˜ao compartilhadas por duas caches de n´ıvel L1, ou seja, s ˜ao compartilhadas por at ´e dois n ´ucleos de processamento. J ´a a cache de n´ıvel L3 ´e compartilhada por at ´e quatrocachesde n´ıvel L2, sendo assim s ˜ao compartilhadas por at ´e oito n ´ucleos de processamento. Para manter a consist ˆencia ´e implementada uma pol´ıtica dewrite-back na hierarquia decache.
Figura 9: N´ıveis deCache
A comunicac¸ ˜ao entre o n´ıvel de cache e a mem ´oria principal ´e feita por meio do controlador de mem ´oria oumemory control (MC), como pode ser visto na Figura 10.
Na mem ´oria principal ´e feita a an ´alise dos bits alterados nas escritas. A cada escrita na mem ´oria principal s ˜ao analisados quantos bits foram alterados sendo poss´ıvel, assim, calcular o desgaste que a PCM sofreu e a energia que foi consumida.
3.1.2 Limitac¸ ˜oes
Uma limitac¸ ˜ao do PCM-MS ´e que as threads s ˜ao associadas a um determinado n ´ucleo de processamento e n ˜ao s ˜ao escalonadas em n ´ucleos diferentes. Com isso em
Figura 10: Comunicac¸ ˜ao entre a Hierarquia de Cache e a PCM
uma execuc¸ ˜aomultithread, as threads s ˜ao executadas somente em um ´unico n ´ucleo.
O escalonamento dasthreadsser ´a providenciado para trabalhos futuros.
Outra limitac¸ ˜ao ´e que devido ao simulador utilizar arquivos de trac¸o para fazer as simulac¸ ˜oes, n ˜ao ´e poss´ıvel calcular o tempo de execuc¸ ˜ao da arquitetura simulada, visto que o tempo de execuc¸ ˜ao ´e limitado ao acesso ao disco, para ler os arquivos de trac¸o.
3.2 Pintools
Pin (LUK et al., 2005) ´e uma ferramenta de instrumentac¸ ˜ao din ˆamica de programas.
Pin foi projetado para fornecer uma funcionalidade onde um c ´odigo escrito em C ou em C++, pode ser inserido em locais espec´ıficos de um execut ´avel. A vers ˜ao do Pin utilizada foi a 2.12.
Diferente de outras ferramentas semelhantes que inserem o c ´odigo de instrumentac¸ ˜ao estaticamente, modificando o execut ´avel antes da execuc¸ ˜ao, o Pin insere o c ´odigo dinamicamente, durante a execuc¸ ˜ao. Outra caracter´ıstica do Pin ´e que ele salva e restaura os registradores que s ˜ao substitu´ıdos pelo c ´odigo inserido para que o aplicativo continue a executar. Pin tamb ´em tem um acesso limitado aos s´ımbolos e informac¸ ˜oes de depurac¸ ˜ao.
Uma limitac¸ ˜ao do uso de instrumentac¸ ˜ao no c ´odigo ´e que esta pode alterar o com- portamento din ˆamico principalmente em termos de desempenho.
3.3 Eigenbench
Eigenbench (HONG et al., 2010) ´e um microbenchmark que faz uma avaliac¸ ˜ao ortogonal das caracter´ısticas de aplicac¸ ˜oes que formam a base para o comportamento transacional. Ele tamb ´em ´e ´util para compreender plenamente o desempenho de um sistema transacional. O Eigenbench n ˜ao possui, oficialmente em seu site, uma vers ˜ao compat´ıvel com a TinySTM. Para utiliz ´a-lo neste trabalho foi feita uma portabilidade que permitiu executar o Eigenbench com a TinySTM. As definic¸ ˜oes das caracter´ısticas ortogonais podem ser vistas na Tabela 1. A vers ˜ao utilizada foi a 0.8.0.
O Eigenbench faz uma simulac¸ ˜ao de cen ´arios que podem ocorrer em um sistema transacional. Para isso, ele utiliza tr ˆesarrays distintos:
Tabela 1: Definic¸ ˜oes das Caracter´ısticas Ortogonais do EigenBench (HONG et al., 2010)
Caracter´ısticas Definic¸ ˜ao
Scalability N ´umero dethreads
Contention Probabilidade de conflitos de uma transac¸ ˜ao
Density Proporc¸ ˜ao de leituras, em mem ´oria n ˜ao compartilhada, dentro e fora de transac¸ ˜oes
Pollution Proporc¸ ˜ao de escritas do total de acessos `a mem ´oria Predominance Proporc¸ ˜ao de acessos compartilhados do total de acessos
`a mem ´oria
Temporal Locality Probabilidade de repetic¸ ˜ao de um enderec¸o por mem ´oria compartilhada
Transaction Length Comprimento das Transac¸ ˜oes Working-set Size Tamanho da Mem ´oria Utilizada
• Array1: estearray ´e chamado de “hot array”, isso porque estearray ´e compar- tilhado por todas as threads;
• Array2: estearray ´e chamado de “mild array”, devido a estearray ser acessado por meio de transac¸ ˜oes. Cadathread acessa uma parte doArray2, dessa forma os acessos n ˜ao causam conflitos;
• Array3: estearray ´e chamado de “cold array”, isso porque este array ´e dividido como o Array2 mas n ˜ao utiliza transac¸ ˜oes para realizar o acesso. Ele pode ser acessado dentro ou fora de transac¸ ˜oes.
3.4 STAMP Benchmark
STAMP (CAO MINH et al., 2008) ´e um conjunto de benchmarks criado para pes- quisa de mem ´orias transacionais, composto por oitobenchmarks. Apesar de desen- volvido para a STM TL2, com algumas modificac¸ ˜oes dispon´ıveis, pode ser usado no TinySTM. A vers ˜ao do STAMP utilizada foi a 0.9.10. O conjunto de benchmarks STAMP foi escolhido devido ao fato de que implementa v ´arios benchmarks, assim atingindo uma maior ´area de aplicac¸ ˜oes das STM al ´em de ser o conjunto de bench- mark mais utilizado na pesquisa de STM.
Osbenchmarks implementados pelo STAMP ser ˜ao descritos a seguir (CAO MINH et al., 2008).
3.4.1 Bayes
Esta aplicac¸ ˜ao implementa um algoritmo de aprendizado de redes Bayesianas, que ´e uma parte importante do aprendizado de m ´aquina. Normalmente, nem as distribuic¸ ˜oes de probabilidades nem as depend ˆencias condicionais entre eles s ˜ao co- nhecidas ou podem ser resolvidas por um ser humano, assim redes Bayesianas s ˜ao frequentemente estudadas com os dados observados. O algoritmo espec´ıfico imple- menta uma estrat ´egia dehill-climbing, ou subida de encosta, que usa buscas locais e globais, semelhante `a t ´ecnica descrita em Chickeringet al (1997). Para eficientes es- timativas de distribuic¸ ˜ao de probabilidade, utiliza-se umaadtree, ou ´arvore de decis ˜ao, a partir de Mooreet al (1997).
3.4.2 Genome
Este benchmark implementa um programa de sequenciamento de genes que re- constr ´oi a sequ ˆencia de genes a partir de segmentos de um gene maior. O algoritmo usado para o sequenciamento de genes tem tr ˆes fases:
1. Remove os segmentos duplicados utilizando umahash;
2. Combina segmentos utilizando o algoritmo de pesquisa de sequ ˆencia Rabin- Karp (KARP; RABIN, 1987);
3. Constr ´oi a sequ ˆencia.
3.4.3 Intruder
Estebenchmark simula o Design 5 dos NIDS (Network Intrusion Detection System) descritos por Haagdorens et al (HAAGDORENS; VERMEIREN; GOOSSENS, 2005).
Pacotes de rede s ˜ao processados em paralelo e passam por tr ˆes fases: captac¸ ˜ao, remontagem e detecc¸ ˜ao. A estrutura de dados principal na fase de captura ´e uma simples fila, e a fase de remontagem utiliza um dicion ´ario (implementado por uma
´arvore autobalanceada), que cont ´em a lista de pacotes pertencentes `a mesma sess ˜ao.
Ao avaliar seus cinco designs para um NIDSmultithread.
3.4.4 Kmeans
Estebenchmark foi extra´ıdo doNU-MineBench 2.0 (PISHARATH et al., 2004). K- means ´e um m ´etodo baseado em partic¸ ˜ao (BEZDEK, 1981) e ´e sem d ´uvida a t ´ecnica de agrupamento mais utilizada. Este algoritmo ´e comumente usado para partic¸ ˜ao de itens de dados em subconjuntos relacionados. Cada thread processa uma partic¸ ˜ao dos objetos iterativamente. A vers ˜ao transacional adiciona uma transac¸ ˜ao para prote- ger oupdate do centro docluster que ocorre durante cada iterac¸ ˜ao.
3.4.5 Labyrinth
Dado um labirinto, estebenchmark encontra os caminhos de menor dist ˆancia entre os pares de pontos inicial e final. O algoritmo de roteamento utilizado ´e o algoritmo de Lee (LEE, 1961).
Nesse algoritmo, o labirinto ´e representado como uma grade, em que cada ponto da grade pode conter ligac¸ ˜oes adjacentes, para os pontos da grade que n ˜ao est ˜ao nas diagonais. O algoritmo busca um caminho mais curto entre os pontos de co- nex ˜ao, atrav ´es da realizac¸ ˜ao de uma busca em largura, e marca cada ponto da grade com a sua dist ˆancia para o in´ıcio. Esta fase de expans ˜ao acabar ´a por chegar ao ponto final, se a conex ˜ao for poss´ıvel. A segunda fase de rastreamento estabelece a ligac¸ ˜ao, seguindo todo o caminho, diminuindo a dist ˆancia. Este algoritmo assegura o encon- tro do caminho mais curto entre um ponto inicial e final, no entanto, quando v ´arios caminhos s ˜ao feitos, um caminho pode bloquear outro.
3.4.6 SSCA2
Scalable Synthetic Compact Applications 2 (SSCA2) (BADER; MADDURI, 2005) ´e composta por quatrokernels que operam em um grande, dirigido e ponderado grafo.
Estes quatrokernelss ˜ao comumente usados em aplicac¸ ˜oes que v ˜ao desde a biologia computacional at ´e a seguranc¸a. O SSCA2 incide sobre umKernel, que constr ´oi uma estrutura de dados eficiente utilizando matrizes de adjac ˆencia e matrizes auxiliares.
3.4.7 Vacation
Estebenchmark implementa um sistema de reserva de viagens alimentado por um banco de dados n ˜ao-distribu´ıdo. A carga de trabalho ´e composta por v ´arios segmentos dos clientes que interagem com o banco de dados via gerenciador de transac¸ ˜oes do sistema.
O banco de dados ´e composto por quatro tabelas: carros, quartos, voos e clientes.
Os tr ˆes primeiros t ˆem relac¸ ˜oes com os campos que representam um n ´umero ´unico de identificac¸ ˜ao, quantidade reservada, a quantidade total dispon´ıvel e o prec¸o. A tabela de clientes acompanha as reservas feitas por cliente e o prec¸o total das reservas que eles fizeram. As tabelas s ˜ao implementadas como ´arvores rubro-negras.
3.4.8 Yada
Este benchmark implementa o algoritmo de Ruppert para refinamento de ma- lha (RUPPERT, 1995). A vers ˜ao transacional ´e similar, em design, ao apresentado em Kulkarni et al. (2006). A estrutura de dados b ´asica utilizada ´e um grafo. Ele ar- mazena todos os tri ˆangulos de malha ( ´e um conjunto que cont ´em os segmentos de contorno de malha), e uma fila de tarefas que cont ´em os tri ˆangulos que precisam ser refinados. Em cada iterac¸ ˜ao do algoritmo, um pequeno tri ˆangulo ´e removido da fila e
uma retriangularizac¸ ˜ao ´e realizada na malha. Quaisquer novos tri ˆangulos finos que resultem da retriangularizac¸ ˜ao, s ˜ao adicionados `a fila.
3.5 Considerac¸ ˜ oes Finais do Cap´ıtulo
Este cap´ıtulo apresentou o simulador PCM-MS, que foi implementado para este trabalho, e as demais ferramentas ebenchmarksutilizados neste trabalho. O PCM-MS simula uma hierarquia de mem ´oria e faz a simulac¸ ˜ao dos acessos a essa hierarquia, onde a PCM ´e a mem ´oria principal. Uma caracter´ıstica importante dele ´e que ele faz simulac¸ ˜oes de arquiteturas com m ´ultiplos n ´ucleos de processamento. A ferramenta PinTools, auxilia o PCM-MS gerando arquivos de trac¸o com os acessos `a mem ´oria.
Os benchmarks utilizados est ˜ao entre os mais utilizados na pesquisa de STM. O Eigenbench devido ele simular diferentes aplicac¸ ˜oes e caracter´ısticas que permitem analisar sistemas transacionais. O STAMP ´e um conjunto de benchmarks, sendo o mais utilizado na pesquisa de STM devido ele ser robusto e abranger uma ampla ´area de aplicac¸ ˜oes das STM.
