At´e agora temos circunscrito todos os nossos passos `a execu¸c˜ao da aplica¸c˜ao SANDER no cluster em quest˜ao, antevendo que ser´a esta a arquitectura onde tipicamente a anterior exe- cutar´a. No entanto, a utiliza¸c˜ao de uma ´unica m´aquina multi-processador ´e inteiramente legitima; dadas as suas caracter´ısticas especiais, brevemente afloradas na sec¸c˜ao 3.2, a expe- rimenta¸c˜ao com uma m´aquina cc-NUMA torna-se atraente no ˆambito deste trabalho.
Assumidamente n˜ao consideramos explorar em profundidade todos os aspectos que ana- lis´amos at´e ent˜ao para o nosso cluster37
; em vez disso, estamos particularmente empenhados em averiguar de que forma as diferentes distancias entre processadores (hop count) afec- tam a performance da aplica¸c˜ao e, se adequado, sugerir ao utilizador uma forma de obter a melhor performance poss´ıvel38
. O factor escalabilidade, muito pertinente neste contexto, ser´a tamb´em observado. Para recordar as caracter´ısticas da m´aquina usada, o leitor dever´a revisitar a sec¸c˜ao 3.2.
Por conseguinte, come¸camos por realizar um conjunto de testes em paralelo colocando dois processos (NP = 2) em processadores com diferentes hops entre si (1,2,3), esperando observar o efeito inerente `a topologia.
Para nos ser poss´ıvel controlar quais os cores dispon´ıveis para executar a aplica¸c˜ao, bem como impor que em cada um desses apenas executasse um processo, recorremos `a aplica¸c˜ao tasksete passamos os argumentos apropriados ao mpirun. Sendo assim, para executar uma aplica¸c˜ao paralela MPI nos cores 1 e 2, far´ıamos:
mpirun -np 2 -bind-to-socket -bysocket taskset -c 1,2 ...
Sobre isto, e em rela¸c˜ao `a aplica¸c˜ao usada (e respectiva simula¸c˜ao), importa mencionar que observ´amos que o comando indicado faz com que os processos se mantenham em cores diferentes durante a execu¸c˜ao e com que a mem´oria des¸ca em ambos os n´os, como esperar´ıamos que acontecesse.
A tabela 5.25 mostra os tempos que regist´amos para os diferentes cen´arios.
Tabela 5.25: Tempos de execu¸c˜ao com a aplica¸c˜ao sander.MPI no SMP (2.8 GHz). AMBER compilado
com gcc-4.4.5, de acordo com a melhor configura¸c˜ao determinada.
CPUs Cores Hops Tempo (s) Speedup (×)
0,1 0,2 1 2102,83 ---
0,6 0,12 2 2117,04 0,993
0,7 0,14 3 2105,04 0,999
Da sua an´alise conclu´ımos que para NP = 2 o r´acio entre os tempos de comunica¸c˜ao e computa¸c˜ao ser´a reduzido, o que justificar´a as diferen¸cas marginais observadas para diferentes hops. Tal n˜ao nos surpreende grandemente; de facto, j´a t´ınhamos observado aquando da realiza¸c˜ao do estudo dos interconnects que o peso da comunica¸c˜ao, inferido pela utiliza¸c˜ao
37
Devido a restri¸c˜oes temporais. 38
Facilmente se percebe que tal s´o se aplica quando for utilizado um numero de processadores inferior ao n´umero de processadores dispon´ıveis.
do CPU em kernel mode, aumenta consideravelmente quando o n´umero de processos duplica. Simplesmente, dada a topologia seria imposs´ıvel realizar um ensaio com NP = 4 (ou maior) que apenas utilizasse uma das distancias existentes e em que todos os processos corressem num processador39
. Mesmo que arranj´assemos alguma configura¸c˜ao aceit´avel, ao aumentar o n´umero de processadores participantes correr´ıamos o risco de algum desses processadores estar a executar alguma aplica¸c˜ao ou servi¸co a correr no sistema, deturpando o resultado.
No fundo percebemos que ´e dif´ıcil obter valores totalmente cred´ıveis, a n˜ao ser que con- trol´assemos efectivamente todos os processos do sistema. Tal n˜ao ´e vi´avel, visto n˜ao dispormos de uso exclusivo do equipamento, situa¸c˜ao com que a maioria dos utilizadores se deparar´a.
Apresentamos agora os resultados dos testes de escalabilidade, correspondendo `a execu¸c˜ao para NP = 1,2,4,8 e 16. Note-se que para estes testes n˜ao se impˆos qualquer restri¸c˜ao sobre processadores a usar, ou `a distribui¸c˜ao dos processos pelos mesmos. Dada a varia¸c˜ao que pode ocorrer realiz´amos dois ensaios, admitindo que nos possam dar mais indica¸c˜oes relativamente `a quest˜ao anterior.
Tabela 5.26: Tempos de execu¸c˜ao com a aplica¸c˜ao sander.MPI no SMP (2.8 GHz). AMBER compilado
com gcc-4.4.5, de acordo com a melhor configura¸c˜ao determinada. Speedup em rela¸c˜ao a NP = 1,
utilizando o melhor ensaio.
NP Tempo (s) Varia¸c˜ao (%) Speedup (×)
ensaio 1 ensaio 2 1 4950,16 5157,55 +4,19 --- 2 2187,27 2192,28 +0,23 2,263 4 2143,13 1177,68 -45,05 4,203 8 890,68 1182,69 +32,79 5,558 16 538,31 440,17 -18,23 11,246 Cluster, NP = 16, IB 485,965 --- --- ---
De facto d˜ao. A tabela 5.26 mostra que o resultado apresenta grande variabilidade para NP > 2, que pela sua express˜ao ser´a atribu´ıvel `a comunica¸c˜ao entre cpus com diferentes hops. Percebemos ent˜ao que um utilizador pode ver o seu trabalho demorar at´e duas vezes mais do que o esperado se perante uma distribui¸c˜ao assumidamente infeliz. Todavia, a express˜ao do problema reduz-se `a medida que NP cresce; admitimos que a justifica¸c˜ao seja que, a partir de certo ponto, a probabilidade de n˜ao utilizar todas as distˆancias seja cada vez menor, o que implicar´a uma menor capacidade de alterar o resultado.
Atendendo ao caso aparentemente mais problem´atico, correspondendo a NP = 4, podemos afirmar que conseguimos melhorar o resultado, em mais de 17%, ao confinar os 4 processos a 2 processadores com um n´umero de hops igual a 1 entre si (CPUs 1 e 3). Admitimos que ao monopolizar um CPU, o escalonador do kernel ser´a inteligente o suficiente para n˜ao atribuir esse processador a outros processos, caso contr´ario provavelmente o desempenho seria pior.
Sendo assim, sugerimos ao leitor que tente encontrar um conjunto de cpus que minimizem as distˆancias entre si, observando a topologia da m´aquina. Alternativamente poder´a isolar um conjunto de cpus para executar a sua aplica¸c˜ao. Tal implica inicializar o kernel com a op¸c˜ao isolcpus= cpu number [, cpu number ,...] e posteriormente recorrer ao taskset para utilizar os cpus indicados anteriormente. Infelizmente tal requer acesso privilegiado ao sistema.
39
O intuito de correr todos os processos num CPU diferente ´e permitir a obten¸c˜ao de um extremo quando a pior distancia fosse utilizada, possibilitando a compara¸c˜ao entre o melhor e o pior caso.