5.4
Rela¸c˜ao com o desempenho
A taxa de uso de barramento de mem´oria, apresentada na se¸c˜ao 4.4 para NPB, e a granularidade efetiva, apresentada na se¸c˜ao 5.3, s˜ao ambas m´etricas baseadas na contagem absoluta de acessos `a mem´oria, com a primeira relacionando-se com o tempo decorrido e a segunda com instru¸c˜oes de aritm´etica de ponto flutuante. Logo, ´e imediato que haja forte correspondˆencia entre as duas observa¸c˜oes, embora uma correla¸c˜ao perfeita e proporcional seja improv´avel, j´a que os programas realizam outras opera¸c˜oes al´em de c´alculos em ponto flutuante, e mesmo no conjunto destas h´a diferen¸cas de dura¸c˜ao entre instru¸c˜oes diversas. Ainda assim, programas com elevada taxa de uso de barramento nas figuras 4.7, 4.8 e 4.9 exibiram granularidade efetiva elevada nas figuras 5.2, 5.3 e 5.4, como CG, MG e SP, enquanto programas com uso mais ameno de barramento exibiram granularidade efetiva baixa, como EP e BT.
Uma vez que granularidade efetiva est´a relacionada com taxa de uso de barramento, ent˜ao tamb´em pode ser associada com a escalabilidade. As figuras 4.1, 4.3 e 4.5, que mostram as curvas de speedup de NPB em SGI nas classes A, B e C, respectivamente, manifestam caracter´ısticas semelhantes `as das curvas de γE, mostradas nas figuras 5.2,
5.3 e 5.4. Os maiores speedups s˜ao de, principalmente, EP, BT e FT, que apresentam baixa granularidade efetiva; os menores speedups s˜ao de, principalmente, MG e SP, que possuem granularidade efetiva elevada. Assim como em speedup, h´a mais invers˜oes de comportamento das curvas de granularidade efetiva com o aumento de threads nos pro- blemas menores. Os curtos tempos de execu¸c˜ao na classe A, em muitos casos inferiores a um minuto, sugerem maior sobrecarga da paraleliza¸c˜ao. Segue-se, ent˜ao, que granulari- dade de loop ´e associada `a escalabilidade, pois as aplica¸c˜oes com baixo valor de γL, EP e
BT, apresentaram speedups elevados em SGI, tipicamente acima de 4, conseguindo escalar at´e a quantidade de threads igual ao n´umero de cores. A aplica¸c˜ao FT, que possui valor intermedi´ario de γL, apresentou speedups intermedi´arios, por volta de 4. J´a as aplica¸c˜oes
com valor de γL elevado, MG e SP, apresentaram speedups inferiores a 4 em SGI e, nos
tamanhos de problema B e C, escalaram apenas at´e 4 threads, falhando em aproveitar todos os recursos computacionais dispon´ıveis. Mesmo nos casos de LU e UA, em que o loop paralelo escolhido para representar a aplica¸c˜ao ´e pouco significativo para o comporta- mento total (em rela¸c˜ao ao loop escolhido para as demais aplica¸c˜oes), h´a ind´ıcios de uma correspondˆencia entre granularidade de loop e escalabilidade, pois ambas as aplica¸c˜oes, com γLinferior `a de CG e SP, exceto LU.B, conseguem apresentar ganhos de desempenho
5.4 Rela¸c˜ao com o desempenho 79
compat´ıvel com seus maiores valores de speedup em rela¸c˜ao a UA. Os pequenos speedups de UA em SGI nas classes B e C, inferiores a 2,5, tamb´em s˜ao justificados pelo uso de locks OpenMP, que atuam essencialmente serializando os acessos por eles protegidos.
Similarmente ao que ocorre com NPB, os elevados valores de γL para STREAM cor-
respondem `a sua elevada taxa de uso de barramento em SGI, indicada na tabela 4.3, enquanto o baixo valor de γL de MultMat causa uma taxa de uso de barramento mais
moderada, como mostrado na tabela 4.4. Tamb´em nestes dois programas a granularidade de loop sugere uma associa¸c˜ao com a escalabilidade.
A compara¸c˜ao direta entre γL e βM ´e inadequada devido ao mecanismo de cache, que
possui diferentes n´ıveis, capacidades e graus de compartilhamento entre os sistemas com- putacionais; ainda assim, ´e esperado que βM mais elevado garanta melhor escalabilidade
para um mesmo valor de γL. De fato, a maior largura de banda de HP em compara¸c˜ao
a SGI, refletida em sua maior propor¸c˜ao βM, garantiu melhores escalabilidades para as
aplica¸c˜oes com granularidade γLmaior. As aplica¸c˜oes CG, MG e SP, que em SGI apresen-
tam limita¸c˜ao clara `a escalabilidade em 4 threads, conseguiram escalar em HP no m´ınimo at´e 6 threads, como observado na figura 4.19, com CG e MG diminuindo consideravelmen- te seu ritmo de crescimento de speedup somente em 8 threads. Esta melhoria, contudo, n˜ao foi proporcional ao incremento de 122,02% em βM; a escalabilidade de FT, por outro
lado, foi prejudicada na execu¸c˜ao em HP e apresentou estagna¸c˜ao a partir de 6 threads, o que pode estar associado a especificidades do algoritmo utilizado.
Desconsiderando as situa¸c˜oes em que h´a mais threads do que cores, j´a abordadas como n˜ao causando melhorias na execu¸c˜ao dos programas, na m´aquina AMD n˜ao se manifesta- ram na escalabilidade limita¸c˜oes severas o suficiente para impedir ganhos com o acr´escimo de threads, pois todas as aplica¸c˜oes testadas, incluindo STREAM, conseguiram obter diminui¸c˜oes no tempo de execu¸c˜ao com mais threads, mesmo que modestas. As aplica¸c˜oes com menor γL apresentaram menores speedups, e as com maiores γL, maiores speedups. O
comportamento inesperado do speedup de CG pode estar associado a potenciais diferen¸cas na localidade de seus acessos e `a diferente organiza¸c˜ao de cache entre as duas m´aquinas. A pequena quantidade de cores em AMD prejudica a aprecia¸c˜ao de potenciais benef´ıcios com seu maior βM em rela¸c˜ao a SGI, embora teriam valor de βM pr´oximos se possu´ıssem
a mesma quantidade de cores.
O sistema MTL, embora possua a segunda menor propor¸c˜ao βM, apresenta escalabili-
dade superior aos demais. Apesar do baixo valor de granularidade de loop de EP garantir a maior curva de speedup na figura 4.24 e os valores elevados de granularidade de MG, SP
5.4 Rela¸c˜ao com o desempenho 80
e STREAM induzirem as curvas de speedup mais baixas, n˜ao h´a uma separa¸c˜ao clara entre o comportamento de speedup de BT, CG, FT e LU, que apresentam γL variando de 0,856
at´e 1,800. Al´em de diferentes localidades de acesso entre as aplica¸c˜oes, a organiza¸c˜ao de mem´oria NUMA contribui para tal resultado; na pr´atica, impedindo-se que threads sejam executadas em cores diferentes de onde j´a executaram e assumindo que os dados s˜ao man- tidos pela biblioteca de threads e pelo sistema operacional no n´o NUMA mais pr´oximo ao core que os usam, a competi¸c˜ao pelos acessos `a mem´oria se d´a majoritariamente entre as threads que executam nos dez cores de cada n´o NUMA, e n˜ao simplesmente entre todos os 40 cores presentes. Uma estrat´egia de sugest˜ao autom´atica de quantidade de threads precisa considerar tais fatores.
Embora a granularidade de loop γL, tal como definida neste trabalho, tenha razo´avel
associa¸c˜ao com benef´ıcios da paraleliza¸c˜ao quando se considera apenas as aplica¸c˜oes de STREAM e MultMat, a associa¸c˜ao de comportamento entre NPB e STREAM com base em γL ´e falha. As grandes diferen¸cas na granularidade efetiva entre NPB e STREAM s˜ao
inconsistentes com as pequenas diferen¸cas em γL, especialmente entre TRIAD e FT. O
valor intermedi´ario de γL na tabela 5.2 para o loop TRIAD de STREAM, ligeiramente
inferior ao de FT, n˜ao garantiu que TRIAD tivesse escalabilidade melhor do que FT. Na verdade, nos sistemas AMD e SGI, tanto STREAM como um todo (mostrado na se¸c˜ao 4.5) quanto seus quatro componentes considerados separadamente apresentaram speedups pequenos, inferiores a 1,7, e cessaram de manifestar melhorias com a paraleliza¸c˜ao a partir de 4 threads. As diferen¸cas no c´odigo-fonte das aplica¸c˜oes apontam trˆes poss´ıveis motivos para esta discrepˆancia: processamento que n˜ao foi considerado em γL, o modo de acesso
aos dados e tamanho dos arrays manipulados. Enquanto cada um dos quatro componentes de STREAM ´e um loop simples, sem aninhamento, FT possui dois loops aninhados na fun¸c˜ao mais custosa, resultando em opera¸c˜oes de controle de itera¸c˜oes mais frequentes. Tamb´em h´a processamento no acesso aos arrays de FT para c´alculo de ´ındices, enquanto STREAM acessa seus arrays diretamente com a vari´avel de controle do loop. Os arrays de STREAM s˜ao acessados sequencialmente na mem´oria, resultando em localidade espacial m´axima, por´em nenhuma posi¸c˜ao ´e reusada dentro do loop, tornando nula a localidade temporal. O tamanho dos arrays, ajustado para exceder em no m´ınimo quatro vezes a capacidade de cache do processador, contribui para a ausˆencia dos dados no cache no in´ıcio de cada loop, provocando os frequentes acessos `a mem´oria observados na tabela 4.3. As menores taxas de uso de barramento de FT, mostradas nas figuras 4.7, 4.8 e 4.9, sugerem que este benchmark tem maior localidade de acessos a dados, indicando que a localidade tamb´em ´e relevante na determina¸c˜ao da quantidade de threads.