Resumidamente, o modelo P-DEVS funciona da seguinte forma: suponha que o bloco tarefa t2fica pronto para disparar (o contador interno de tokens associado à sua porta tin1passou
de zero para um). Neste momento, uma carga de trabalho é submetida ao bloco recurso PE1 ao qual o bloco tarefa t2está associado (ver portas jobout dos blocos tarefa, que são usadas para
enviar cargas de trabalho). O bloco tarefa t2então espera até que a carga de trabalho submetida
termine. A carga de trabalho entra na fila de prioridades do bloco recurso PE1, e quando PE1 termina de executá-la, o bloco tarefa t2 é notificado (ver portas jobin dos blocos tarefa, que
são usadas para receber notificações sobre a finalização de uma carga de trabalho). Depois da notificação, o bloco tarefa t2imediatamente dispara, isto é, ele decrementa cada contador interno
de tokens, e notifica cada um dos blocos tarefa/gerador conectado à sua porta tout que um token foi enviado. O bloco tarefa t3, que recebeu o token, por sua vez, irá incrementar o respectivo
contador interno de tokens. Caso o bloco tarefa t3 fique pronto para disparar (caso todos os
contadores internos de tokens associados à suas portas de entrada tin1e tin2sejam maiores que
zero), ele irá enviar uma carga de trabalho para PE2. Este processo continua até que o critério de parada da simulação seja atingido. A partir dessa descrição, é possível notar que os blocos tarefas/gerador modelam as dependências de dados existentes na aplicação, e os blocos recurso modelam os aspectos temporais resultantes das computações geradas pelos blocos tarefa.
5.2
Tempos de execução e comunicação
Nos modelos de simulação, o tempo de execução de uma carga de trabalho gerada por um bloco tarefa i para um bloco recurso j é dado pela variável aleatória Execi, j, que é igual ao
somatório dos tempos das fases de cópia de mensagens, execução, e escrita de mensagens da tarefa que o bloco tarefa i representa:
Execi, j =
∑
{z : (z,i) ∈ Cd, m((z,i)) 6= j}
E(COPYz,i, j,m((z,i)))
| {z }
fase de cópia de mensagens
+ ETi, j | {z } fase de execução +
∑
{z : (i,z) ∈ Cd, m((i,z)) 6= j}E(COPYi,z, j,m((z,i))) +
∑
{z : (i,z) ∈ Cd, m((i,z)) = j}
E(COPYi,z, j∗ )
| {z }
fase de escrita das mensagens
5.1 onde E(COPYi,z, j,w), E(COPYi,z, j∗ ) e ETi, j foram definidas na Subseção 4.3.2, Cd é o conjunto
de arcos que representam canais de comunicação do HSDG, e a função m : Cd→ V retorna onde
um dado canal está mapeado (V é o conjunto dos elementos do ATG).
Os termos correspondentes às fases de cópia de mensagens e escrita de mensagens na Equação 5.1 não consideram os atrasos devido à contenção dos elementos de comunicação. Embora isso seja válido para comunicações intraprocessador, pode não ser válido para comuni- cações interprocessador. Ou seja, caso mais de um elemento de processamento esteja acessando ao mesmo tempo um elemento de comunicação, então o tempo para leitura/escrita de uma mensagem pode ser maior que o tempo verificado, caso não existisse a disputa pelo recurso. A seguir, serão descritas as condições para que a Equação 5.1 , que considera que não há disputa por recursos, seja uma aproximação válida do comportamento real.
Como já mencionado, quando dois ou mais elementos acessam ao mesmo tempo um barramento, este trabalho assume que uma política round-robin é adotada. Resultados disponíveis
5.2. TEMPOS DE EXECUÇÃO E COMUNICAÇÃO 85
Figura 5.2: Atraso relativo no tempo de execução devido à contenção no barramento.
na literatura, obtidos por simulação de baixo nível (RUGGIERO et al.,2006,2004), indicam que o tempo de atraso causado pela contenção em barramentos AHB (Advanced High-performance Bus) (HOLDINGS,2006) é relativamente pequeno, caso uma política round-robin seja adotada e a largura de banda demandada pelas tarefas seja inferior a 50% da largura de banda máxima su- portada pelo barramento. A largura de banda demandada por uma tarefa é calculada como sendo a razão entre quantidade de dados transferida e o tempo de execução da etapa de transferência. Os resultados obtidos por simulação nos trabalhos da literatura foram confirmados nesta tese através de medições em uma arquitetura real com dois processadores e um barramento AHB conectando os dois processadores. A Figura 5.2 mostra o atraso relativo devido à contenção no barramento, considerando o tempo de execução de dois trechos de código. Cada trecho de código é executado em um processador diferente, e eles foram concebidos especificamente para gerar diferentes níveis de utilização no barramento. A seguinte expressão foi adotada para calcular o atraso relativo: (Ta01+ Ta02) − (Ta1+ Ta2) (Ta1+ Ta2) , onde Taie Ta 0
irepresentam, respectivamente, o tempo de execução do trecho de código i quando
ele é executado isoladamente, e quando ele é executado em paralelo ao outro trecho de código. Os resultados na Figura 5.2 mostram que, de fato, quando o nível de utilização do barramento é menor ou igual a 50%, o atraso devido à contenção é muito pequeno (atraso médio de 0,8% e atraso máximo de de 2,7%). Dessa forma, a Equação 5.1 representa uma boa aproximação caso a utilização dos barramentos sejam iguais ou menores que 50%. Os algoritmos de exploração propostos levam em consideração essa restrição durante a atividade de mapeamento dos canais de comunicação. A Equação 5.2 é usada pelos algoritmos para estimar qual a largura de banda demandada em um dado barramento b.
breqb=
∑
∀p ∈ P max( sizec1 tcopyc1,p , sizec2 tcopyc2,p , ... , sizecn tcopycn,p ) c1, c2, ... , cn∈ Map(b, p), 5.2onde P é o conjunto de processadores alocados, sizec é o tamanho das mensagens do canal de
comunicação c, tcopycé o tempo médio para o processador p copiar da memória compartilhada
para memória local as mensagens do canal de comunicação c, e c ∈ Map(b, p) indica que o canal c está mapeado no barramento b e a tarefa emissora ou receptora de c está mapeada no processador p.
Neste trabalho, consideramos apenas barramentos AHB (Advanced High-performance Bus). Caso o projetista utilize outro tipo de barramento, ele pode aumentar/diminuir o percentual