Soma de Matrizes

O primeiro teste realizado sobre a arquitetura foi o cˆomputo da soma de duas matrizes quadradas de elementos do tipo inteiro (32 bits). A tarefa da soma ´e realizada por n proces- sadores, subdividindo cada matriz-operando em n submatrizes, sendo que cada processador calcula a soma de um par de submatrizes. Como as submatrizes encontram-se em regi˜oes de mem´oria distintas, a coerˆencia de cachˆe torna-se mais simples. Uma vez que os dados da matriz resultante s´o ser˜ao utilizados ap´os o fim do c´alculo de todas as somas, basta introduzir uma fun¸c˜ao de esvaziamento de cachˆe antes da verifica¸c˜ao dos dados.

Inicialmente, o algoritmo foi executado em um processador e, em seguida, em m´ultiplos processadores. Como havia pretens˜ao de executar o c´odigo em 1, 2, 3 e 4 processadores, foram escolhidas matrizes m´ultiplas de 12 por este ser o menor m´ultiplo comum entre os n´umeros de processadores que se deseja utilizar, permitindo o perfeito fracionamento da carga computacional entre as unidades envolvidas. Foram executadas opera¸c˜oes envolvendo pares de matrizes de ordem 12, 24, 48, 96, 192 e 384.

O c´odigo-fonte utilizado neste teste encontra-se na se¸c˜ao B.1 do apˆendice. A variˆancia dos dados coletados para as matrizes com ordem superior a 48 foi inferior a 2% em rela¸c˜ao ao valor m´edio de dez amostras, enquanto a dos dados obtidos nos testes com matrizes menores ´e de at´e 6%.

Por possuir fun¸c˜oes de escrita no console de modo texto, o c´odigo bin´ario deste algoritmo compilado para o processador P1 possui 70 KB, enquanto para os demais processadores possui apenas 59 KB. Os tamanhos de c´odigo bin´ario obtidos neste teste possuem um tamanho relativamente grande devido ao fato de estar-se desenvolvendo c´odigo em n´ıvel de API HAL. Para uma maior otimiza¸c˜ao poder-se-iam implementar os algoritmos utilizando diretamente drivers de dispositivo ou mesmo desenvolvimento em linguagem de montagem (Assembly). N´ıveis mais baixos de programa¸c˜ao oferecem maior custo no desenvolvimento e manuten¸c˜ao do software em detrimento de melhores marcas de desempenho.

A figura 4.8 mostra a distribui¸c˜ao percentual do tempo gasto na execu¸c˜ao das fra¸c˜oes paralela e serial do c´odigo. Ela foi obtida atrav´es da execu¸c˜ao do algoritmo em um ´unico processador e medindo-se os tempos de processamento total e da fra¸c˜ao paraleliz´avel. Nota-se que, para matrizes de ordem elevada, os tempos gastos em prepara¸c˜ao, sincronismo e overhead de comunica¸c˜ao tornam-se irrelevantes em rela¸c˜ao ao tempo de processamento paraleliz´avel. Um ´unico processador do sistema levou 11.102 ciclos (120 µs) para a execu¸c˜ao do al- goritmo da soma de duas matrizes de ordem 12. Deste total, apenas 3.040 ciclos (33 µs) foram gastos na se¸c˜ao serial do c´odigo, ou seja, γ=21,496%. Tomando como base o modelo de computa¸c˜ao paralela com se¸c˜oes seriais discutido na se¸c˜ao 3.3.1, o tempo de execu¸c˜ao do c´odigo sobre 4 processadores poderia ser calculado atrav´es da equa¸c˜ao 3.5 para a determina- ¸c˜ao do tempo de processamento para quatro processadores, obt´em-se T (4) = 50, 72 µs. Com base no tempo de execu¸c˜ao calculado, chega-se a um fator de speedup anal´ıtico relativo de S(4) = 2, 43.

Para matrizes de ordem 384, um ´unico processador levou 11,2 milh˜oes de ciclos (132,4 ms) para a execu¸c˜ao de todo o c´odigo paralelo, dos quais aproximadamente trˆes mil ciclos devem-se `a fra¸c˜ao serial do c´odigo. Utilizando novamente a equa¸c˜ao 3.5 para a determina¸c˜ao do tempo de processamento para quatro processadores tem-se T (4) = 33, 12 ms e fator de speedup anal´ıtico relativo de S(4) = 3, 997.

No intuito de confrontar os valores anal´ıticos com os observados, foram tomadas as medi- das de tempo de execu¸c˜ao do programa paralelo. A figura 4.9 apresenta os resultados obtidos na medi¸c˜ao dos tempos de execu¸c˜ao das somas de matrizes utilizando de um a quatro pro- cessadores da arquitetura do SMM-4. Comparando os dois valores calculados anteriormente com os valores medidos ´e poss´ıvel concluir que o modelo de computa¸c˜ao paralela com se¸c˜oes

66 CAP´ITULO 4: DESCRI ¸C ˜AO E AN ´ALISE DO PROJETO O rd em d a m at ri z

Tempo de execu¸c˜ao da tarefa (ms)

(a) Matrizes de ordem 12, 24 e 48.

O rd em d a m at ri z

Tempo de execu¸c˜ao da tarefa (ms)

(b) Matrizes de ordem 96, 192 e 384.

Figura 4.9: Tempos de execu¸c˜ao do algoritmo de soma de matrizes de diversos tamanhos e por diferentes n´umeros de processadores.

Ordem da Matriz S(2) S(3) S(4) 12 0,7543 0,3890 0,2955 24 1,1990 0,8518 0,6388 48 1,3147 1,0768 0,8865 96 1,2495 1,1643 1,0055 192 1,2914 1,1949 1,0591 384 1,2953 1,2020 1,0551

Tabela 4.3: Fatores de speedup relativos observados para soma paralela de matrizes. seriais n˜ao ´e uma boa representa¸c˜ao para o sistema em quest˜ao. O “efeito multiprocessa- dor” tratado por Gunther (2002) mostra-se fortemente presente nesta arquitetura a ponto de tornar os resultados obtidos analiticamente muito distantes da realidade observada.

O fator de speedup relativo observado pode ent˜ao ser calculado a partir dos tempos medidos para cada um dos casos. Os valores s˜ao apresentados na tabela 4.3.

Dos resultados percebe-se que o multiprocessamento se torna vantajoso apenas a partir de uma certa carga computacional exigida. Al´em disso, ´e importante notar que n˜ao existe van- tagem na utiliza¸c˜ao de mais que dois processadores para este tipo de tarefa. Isto mostra que ´e importante conhecer-se a tarefa a ser realizada como um requisito para o desenvolvimento da melhor arquitetura. No caso do SMM-4 pode-se utilizar apenas dois processadores sem qualquer preju´ızo ao desempenho do sistema. Os outros dois processadores sobressalentes poderiam ser destinados, com uma pequena por¸c˜ao de mem´oria interna de instru¸c˜oes, para realiza¸c˜ao de tarefas secund´arias ou que exijam poucas instru¸c˜oes e n˜ao fa¸cam muito uso da SDRAM.

Devido o tempo de carregamento dos processadores n˜ao depender do SMM-4 unicamente mas tamb´em de diversos parˆametros do sistema anfitri˜ao (escalonamento do SO, banda dis- pon´ıvel na rede USB etc.), este foi exclu´ıdo das medi¸c˜oes as quais se iniciam imediatamente ap´os o carregamento de todos os processadores envolvidos no processamento.

Dificuldades foram encontradas durante a fase de testes na utiliza¸c˜ao da Mailbox, pois ao ser carregada a estrutura de dados deste perif´erico na mem´oria, um conte´udo indesej´avel inicial ´e notado, o que provoca inconsistˆencia e perda de sincronismo entre os processadores. Embora n˜ao haja qualquer tipo de documenta¸c˜ao sobre este problema nos manuais do Nios II, foi contornado atrav´es do esvaziamento pr´evio das Mailboxes antes da primeira utiliza¸c˜ao. ´

E necess´ario que o processador P1 seja carregado antes dos outros sob pena de perda de

sincronismo do sistema. Isto pode ser facilmente garantido uma vez que a ordem de carrega- mento dos processadores ´e dada pelo parˆametro de instˆancia (instance), que no caso do P1

68 CAP´ITULO 4: DESCRI ¸C ˜AO E AN ´ALISE DO PROJETO

e P4 foram configurados com instˆancia 2, 3 e 0, respectivamente, sendo esta a mesma ordem

de carregamento3_{. Com estas altera¸c˜oes no programa e no sistema, chegou-se a um c´odigo}

utiliz´avel para os fins almejados neste trabalho.

A integridade da mem´oria cachˆe de dados de cada um dos processadores foi garantida atrav´es da invalida¸c˜ao, conseq¨uentemente, o esvaziamento ao fim do processamento do c´odigo atrav´es da fun¸c˜ao alt_dcache_flush_all(). Ap´os a execu¸c˜ao desta fun¸c˜ao os processadores de 2, 3 e 4 enviam uma mensagem para o processador 1 indicando que conclu´ıram suas tarefas.

´

E importante notar que s´o se faz uso do sistema de comunica¸c˜ao por Mailbox em dois mo- mentos: no in´ıcio e ao fim do processamento. Desta forma, o impacto com comunica¸c˜ao n˜ao cresce com o aumento da carga computacional, permanecendo aproximadamente constante. Esta caracter´ıstica faz com que os efeitos de perda de desempenho observado atrav´es do uso de v´arias unidades processadoras possa seguramente ser atribu´ıda a fatores relacionados `a concorrˆencia pela mem´oria.