Desenvolvimento de memórias scratchpad para arquiteturas multi-core

Detalhes bibliográficos
Autor(a) principal: Moreira, Francis Birck
Data de Publicação: 2011
Tipo de documento: Trabalho de conclusão de curso
Idioma: por
Título da fonte: Repositório Institucional da UFRGS
Texto Completo: http://hdl.handle.net/10183/31019
Resumo: Durante a execução de programas paralelos em arquiteturas com múltiplos núcleos, diversas vezes torna-se necessária a manipulação de uma quantidade razoável de dados compartilhados entre as múltiplas threads paralelas, as quais podem estar em diferentes núcleos de processamento. Portanto, dados os problemas de coerência de memória, torna-se interessante o uso de uma memória única para dados compartilhados entre os núcleos, especialmente se o programador puder controlar quais dados vão para essa memória. Para isso, é necessário o uso de uma memória não transparente, ou seja, uma memória da qual o processador tem conhecimento: o modelo clássico de uma memória scratchpad (SPM). Sendo o scratchpad um tipo de memória bastante usado em processadores embarcados, a ideia já foi atacada de várias formas. Geralmente, tais soluções implicam nos seguintes problemas: falta de retrocompatibilidade, o que leva à recompilação do código para tamanhos diferente de scratchpad; hardware adicional, além da interconexão entre a memória scratchpad e o processador; e complexidade para o programador, uma vez que a responsabilidade na escolha do conteúdo do scratchpad ficará a seu cargo. Este trabalho apresenta o desenvolvimento de uma implementação de uma memória scratchpad. Fora utilizado o simulador Simics, modelando uma arquitetura multi-core baseada em núcleos UltraSPARC II. O objetivo final do trabalho é alcançar ganhos de desempenho, demonstrando maneira diferente de implementação e uso de uma memória scratchpad, com seus benefícios e desvantagens, e avaliar o desempenho obtido. Durante a fase de avaliação foram editados dispositivos de hierarquia da memória presente no Simics, a fim de simular a presença da memória scratchpad na arquitetura, considerado restrições como latência e armazenamento da memória scratchpad. Para acessar a memória scratchpad no nível do programador, foi desenvolvida uma biblioteca que, juntamente com uma função callback do simulador, implementa funções para o programador manipular a scratchpad. Como resultados são mostrados ganhos de até 45% na execução da carga de trabalho avaliada. Sendo que para a maioria das aplicações obteve-se ganhos de desempenho de, na média, 26%, dado que a memória scratchpad foi bem utilizada. Tornou-se evidente durante os experimentos um dos principais problemas do uso do scratchpad, que é a escolha de seu conteúdo. Tal problema é solucionado através do uso de compiladores e ferramentas de profiling.
id UFRGS-2_68b61e7c8860a2df784ce3004244512b
oai_identifier_str oai:www.lume.ufrgs.br:10183/31019
network_acronym_str UFRGS-2
network_name_str Repositório Institucional da UFRGS
repository_id_str
spelling Moreira, Francis BirckNavaux, Philippe Olivier Alexandre2011-08-12T06:00:47Z2011http://hdl.handle.net/10183/31019000782083Durante a execução de programas paralelos em arquiteturas com múltiplos núcleos, diversas vezes torna-se necessária a manipulação de uma quantidade razoável de dados compartilhados entre as múltiplas threads paralelas, as quais podem estar em diferentes núcleos de processamento. Portanto, dados os problemas de coerência de memória, torna-se interessante o uso de uma memória única para dados compartilhados entre os núcleos, especialmente se o programador puder controlar quais dados vão para essa memória. Para isso, é necessário o uso de uma memória não transparente, ou seja, uma memória da qual o processador tem conhecimento: o modelo clássico de uma memória scratchpad (SPM). Sendo o scratchpad um tipo de memória bastante usado em processadores embarcados, a ideia já foi atacada de várias formas. Geralmente, tais soluções implicam nos seguintes problemas: falta de retrocompatibilidade, o que leva à recompilação do código para tamanhos diferente de scratchpad; hardware adicional, além da interconexão entre a memória scratchpad e o processador; e complexidade para o programador, uma vez que a responsabilidade na escolha do conteúdo do scratchpad ficará a seu cargo. Este trabalho apresenta o desenvolvimento de uma implementação de uma memória scratchpad. Fora utilizado o simulador Simics, modelando uma arquitetura multi-core baseada em núcleos UltraSPARC II. O objetivo final do trabalho é alcançar ganhos de desempenho, demonstrando maneira diferente de implementação e uso de uma memória scratchpad, com seus benefícios e desvantagens, e avaliar o desempenho obtido. Durante a fase de avaliação foram editados dispositivos de hierarquia da memória presente no Simics, a fim de simular a presença da memória scratchpad na arquitetura, considerado restrições como latência e armazenamento da memória scratchpad. Para acessar a memória scratchpad no nível do programador, foi desenvolvida uma biblioteca que, juntamente com uma função callback do simulador, implementa funções para o programador manipular a scratchpad. Como resultados são mostrados ganhos de até 45% na execução da carga de trabalho avaliada. Sendo que para a maioria das aplicações obteve-se ganhos de desempenho de, na média, 26%, dado que a memória scratchpad foi bem utilizada. Tornou-se evidente durante os experimentos um dos principais problemas do uso do scratchpad, que é a escolha de seu conteúdo. Tal problema é solucionado através do uso de compiladores e ferramentas de profiling.application/pdfporProcessamento paraleloProcessamento distribuídoDesenvolvimento de memórias scratchpad para arquiteturas multi-coreinfo:eu-repo/semantics/publishedVersioninfo:eu-repo/semantics/bachelorThesisUniversidade Federal do Rio Grande do SulInstituto de InformáticaPorto Alegre, BR-RS2011Ciência da Computação: Ênfase em Ciência da Computação: Bachareladograduaçãoinfo:eu-repo/semantics/openAccessreponame:Repositório Institucional da UFRGSinstname:Universidade Federal do Rio Grande do Sul (UFRGS)instacron:UFRGSTEXT000782083.pdf.txt000782083.pdf.txtExtracted Texttext/plain65179http://www.lume.ufrgs.br/bitstream/10183/31019/2/000782083.pdf.txtafdb4f1f927f32d07d307ea837dee43aMD52ORIGINAL000782083.pdf000782083.pdfTexto completoapplication/pdf1673009http://www.lume.ufrgs.br/bitstream/10183/31019/1/000782083.pdfa9bf6f4f37d607a22b69e5d60ae43286MD51THUMBNAIL000782083.pdf.jpg000782083.pdf.jpgGenerated Thumbnailimage/jpeg1149http://www.lume.ufrgs.br/bitstream/10183/31019/3/000782083.pdf.jpg8e79714bcba2802a0d2f2af9bff4d8a8MD5310183/310192022-02-22 05:12:43.975984oai:www.lume.ufrgs.br:10183/31019Repositório de PublicaçõesPUBhttps://lume.ufrgs.br/oai/requestopendoar:2022-02-22T08:12:43Repositório Institucional da UFRGS - Universidade Federal do Rio Grande do Sul (UFRGS)false
dc.title.pt_BR.fl_str_mv Desenvolvimento de memórias scratchpad para arquiteturas multi-core
title Desenvolvimento de memórias scratchpad para arquiteturas multi-core
spellingShingle Desenvolvimento de memórias scratchpad para arquiteturas multi-core
Moreira, Francis Birck
Processamento paralelo
Processamento distribuído
title_short Desenvolvimento de memórias scratchpad para arquiteturas multi-core
title_full Desenvolvimento de memórias scratchpad para arquiteturas multi-core
title_fullStr Desenvolvimento de memórias scratchpad para arquiteturas multi-core
title_full_unstemmed Desenvolvimento de memórias scratchpad para arquiteturas multi-core
title_sort Desenvolvimento de memórias scratchpad para arquiteturas multi-core
author Moreira, Francis Birck
author_facet Moreira, Francis Birck
author_role author
dc.contributor.author.fl_str_mv Moreira, Francis Birck
dc.contributor.advisor1.fl_str_mv Navaux, Philippe Olivier Alexandre
contributor_str_mv Navaux, Philippe Olivier Alexandre
dc.subject.por.fl_str_mv Processamento paralelo
Processamento distribuído
topic Processamento paralelo
Processamento distribuído
description Durante a execução de programas paralelos em arquiteturas com múltiplos núcleos, diversas vezes torna-se necessária a manipulação de uma quantidade razoável de dados compartilhados entre as múltiplas threads paralelas, as quais podem estar em diferentes núcleos de processamento. Portanto, dados os problemas de coerência de memória, torna-se interessante o uso de uma memória única para dados compartilhados entre os núcleos, especialmente se o programador puder controlar quais dados vão para essa memória. Para isso, é necessário o uso de uma memória não transparente, ou seja, uma memória da qual o processador tem conhecimento: o modelo clássico de uma memória scratchpad (SPM). Sendo o scratchpad um tipo de memória bastante usado em processadores embarcados, a ideia já foi atacada de várias formas. Geralmente, tais soluções implicam nos seguintes problemas: falta de retrocompatibilidade, o que leva à recompilação do código para tamanhos diferente de scratchpad; hardware adicional, além da interconexão entre a memória scratchpad e o processador; e complexidade para o programador, uma vez que a responsabilidade na escolha do conteúdo do scratchpad ficará a seu cargo. Este trabalho apresenta o desenvolvimento de uma implementação de uma memória scratchpad. Fora utilizado o simulador Simics, modelando uma arquitetura multi-core baseada em núcleos UltraSPARC II. O objetivo final do trabalho é alcançar ganhos de desempenho, demonstrando maneira diferente de implementação e uso de uma memória scratchpad, com seus benefícios e desvantagens, e avaliar o desempenho obtido. Durante a fase de avaliação foram editados dispositivos de hierarquia da memória presente no Simics, a fim de simular a presença da memória scratchpad na arquitetura, considerado restrições como latência e armazenamento da memória scratchpad. Para acessar a memória scratchpad no nível do programador, foi desenvolvida uma biblioteca que, juntamente com uma função callback do simulador, implementa funções para o programador manipular a scratchpad. Como resultados são mostrados ganhos de até 45% na execução da carga de trabalho avaliada. Sendo que para a maioria das aplicações obteve-se ganhos de desempenho de, na média, 26%, dado que a memória scratchpad foi bem utilizada. Tornou-se evidente durante os experimentos um dos principais problemas do uso do scratchpad, que é a escolha de seu conteúdo. Tal problema é solucionado através do uso de compiladores e ferramentas de profiling.
publishDate 2011
dc.date.accessioned.fl_str_mv 2011-08-12T06:00:47Z
dc.date.issued.fl_str_mv 2011
dc.type.status.fl_str_mv info:eu-repo/semantics/publishedVersion
dc.type.driver.fl_str_mv info:eu-repo/semantics/bachelorThesis
format bachelorThesis
status_str publishedVersion
dc.identifier.uri.fl_str_mv http://hdl.handle.net/10183/31019
dc.identifier.nrb.pt_BR.fl_str_mv 000782083
url http://hdl.handle.net/10183/31019
identifier_str_mv 000782083
dc.language.iso.fl_str_mv por
language por
dc.rights.driver.fl_str_mv info:eu-repo/semantics/openAccess
eu_rights_str_mv openAccess
dc.format.none.fl_str_mv application/pdf
dc.source.none.fl_str_mv reponame:Repositório Institucional da UFRGS
instname:Universidade Federal do Rio Grande do Sul (UFRGS)
instacron:UFRGS
instname_str Universidade Federal do Rio Grande do Sul (UFRGS)
instacron_str UFRGS
institution UFRGS
reponame_str Repositório Institucional da UFRGS
collection Repositório Institucional da UFRGS
bitstream.url.fl_str_mv http://www.lume.ufrgs.br/bitstream/10183/31019/2/000782083.pdf.txt
http://www.lume.ufrgs.br/bitstream/10183/31019/1/000782083.pdf
http://www.lume.ufrgs.br/bitstream/10183/31019/3/000782083.pdf.jpg
bitstream.checksum.fl_str_mv afdb4f1f927f32d07d307ea837dee43a
a9bf6f4f37d607a22b69e5d60ae43286
8e79714bcba2802a0d2f2af9bff4d8a8
bitstream.checksumAlgorithm.fl_str_mv MD5
MD5
MD5
repository.name.fl_str_mv Repositório Institucional da UFRGS - Universidade Federal do Rio Grande do Sul (UFRGS)
repository.mail.fl_str_mv
_version_ 1801224411783626752