avaliaÇao experimntal do desempenho do sistema ... · os parametros de desempenho são baseados...
TRANSCRIPT
AVALIAÇAO EXPERImNTAL DO DESEMPENHO DO
SISTEMA MULTIPROCESSADOR ACP
Carla Osthoff Ferreira de Barros
TESE SUBMETIDA AO CORPO DOCENTE DA COORBENAÇRO DOS
PROGRAMAS DE POS-GRADUAÇAO DE ENGENHARIA DA UNIVERSIDADE
FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS
NECESSARIOS PARA A OBTENÇXO DO GRAU DE MESTRE EM CIENCIAS
EM ENGENHARIA DE SISTEMAS E COMF'UTAÇXO.
Aprovada por:
A
Prof. Valmir Carneiro ~ a m s a , Ph.D.
RIO DE JANEIRO, RJ-BRASIL ABRIL DE 1989
Barros,CAREA Osthoff Ferreira de
AvaliaçSo Experimental do Desempenho do Sistema
Multiprocessador ACP [Rio de Janeiro3l989
Xr173p.29, 7 cm (COPPE/UFRJ,M.Se,Engenharia de
Sistemas, 1989)
Tese - Universidade Federal da Rio de Janeiro, CQPPE
I. Arquitetura de Computadores, Estudo de Desempenho.
iii
Agradecimentos
A meus orientadores, Prof. Claudio Amorim e Prof.
Valmir Barbosa, que por toda a sua experiência,
questionamento e incentivo tornaram possivel a realização
deste trabalho.
A Alberto Santoro, que com sua garra e dedicação,
possibilitou ngo sb ao desenvolvimento do Sistema ACP em
colaboração com o CBPP, como tambkm ao nascimento de um
novo grupo de Fisica Experimental de Altas Energias.
A Tkiomas Nash, sem o qual o ADVANCED COMPUTER PROGRAM
seria apenas mais um projeto de papel, por toda a confiança
que me tem dado.
A Joe Biel, que me ajudou a formular os fundamentos
desta pesquisa, e por todo o apoio não sb a mim como a toda
a equipe do CBPF.
A Moacyr Souza, que com toda a sua experiência e
paciência, tanta me ajudou.
A Roberto Valois, pelas discussões que me levaram e
entender melhor as minhas questões.
A equipe do LaborBtoris de Fisica Experimental de
Altas Energias do CBPF; Ignacio, Arthur, Gilvan, Guilherme,
Henriette, Mario Vaz, Sandra, Vladimir e outros. Por seu
apoio e compreenstXo durante este perfodo.
A meus pais e meus irmãos que tanto amo.
Resumo da Tese apresentada A COPPE/UFRJ como parte dos
requisitos necessArios para a obtenção do grau de mestre em
Ciências (M.Sc).
AVALIAÇRO EXE'ERIMENTAL DO DESEMPENHO DO
SISTEMA MULTIPROCESSADOR ACP
Carla Osthoff Ferreira de Barros
Abri1,1989
Orientadar: Prof. Claudio Luis de Amorim
Orientador: Prof. Valmir Carneiro Barbosa
Programa: Engenharia de Sistemas e ComputaçiXo
Neste trabalho realizamos uma avaliação experimental do
desempenho do Sistema Multiprocassador ACP. Num dos
ambientes, tarefas são independentes e n2Xo se comunicam
entre si. Noutro ambiente, as tarefas simulam
inter-dependências atraves de transmissão de mensagens.
Os parametros de desempenho são baseados nas medidas de
"DEGRADBÇRO" e de ACELERAÇXO do sistema para variações do
tempo de processamento, do tempo de transmissão, e do
ntunero de processadores do Sistema ACP. Baseado neste
estudo são fornecidas sugestões para o desenvolvimento de
um modelo analítico para o Sistema ACP,
Abstract of Thesis presented to COPPE/UFRJ as partia1
fulfillment of the requirements for the degree of Master
Science (M.Sc).
A Experimental Performance Evaluation
of the ACP Multiprocessor System
Carla Osthoff Ferreira de Barros
Apri1,1989
Thesis Supervisor: Prof. Claudia Luis de Amorim
Thesis Supervisor: Prof. Valmir Carneiro Barbosa
Department:Systems and Computing Engineering
This work is a experimental performance evaluation of the
ACP Multiprocessor System. In an ambient tasks are
independent and there is no communication, in another
ambient messãges are sent to simulate dependente between
tasks. The performance parameters are based on the System
"OVERMEAD" and "SPEED-UP" which are evaluated by varying
processing time, communication time and number of
processors. Based on thiã study we give some suggestions
for a ACP Multiprocessor System analytical model.
AVALIAÇXO EXPERIMENTAL DO DESEMPENHO DO SISTEMA MULTIPROCESSADOR ACP
CAPITULO I
Introdução 1
CAPITWLO 11
Apresentação das arquiteturas paralelas existentes e de suas classificações
5
11.1 - Implementação do Paralelismo em Sistemas
Uniproeessadores.
11.1.1 - Multiplicidade de Unidades Funcionais
9
11.1.2 - Paralelismo e "Pipeline" dentro da Unidade Central de Processamento
11.1.3 - Alternancia entre as operaqtíes da Unidade Central de Processamento e as de Entrada e Saída.
9
11.1.4 - Utiliaaçgo de um Sistema de Membria HierBrquico.
11
11.1.5 - Multiprogramação 12
11.1.6 - Tempo Compartilhado 12
11.1.7 - Multiprocessamento 13
11.2 - Classificaçt3es das Estruturs de Computação
Paralela 13
11.2.1 - Classificação de K.Hwang/F.Briggs
15
vii
11.2.1.1 - Computadores "Pipeline" 15
11.2.1.2 - "Array Computers" 17
11.2.1.2.1 - Array Processor com Memória Local
22
11.2.1.2.2 - Array Proeessor com Membria Compartilhada
23
11.2.1.3 - Sistemas Multiprocessadores 23
11.2.1.3.1 - Arquiteturas de Multiprocessadores Fortemente Acoplados
26
11.2.1.3.2 - Arquiteturas de Multiprocessadores Fracamente Acoplados
11.2.1.4 - "Dataflow"
11.2.2 - Classificação de Flynn 31
11.2.2.1 - Single Instruction Strem Single Data Stream (SISD)
11.2.2.2 - Single Instruction Strem Multiple Data Stream (SIMD)
11.2.2.3 - Multiple Instruction Stream Single Data Stream (MISD)
33
11.2.2.4 - Multiple Instruction Stream Multiple Data Stream (MIMD)
35
11.2.3 - Classificação de HOCKNEY 35
11.2.3.1 - Sistemas Chaveados 37
viii
11.2.3.1.1 - Sistemas de Membria Compartilhada
39
11.2.3.1.2 Sistemas de Membria Distribufda
11.2.3.2 - Sistemas de Rede
11.3 - Avaliação de Desempenho
11.4 - Conclusão 46
CAPITULO I11
O Multiprocessador Paralelo ACP
111.1 - Arquitetura do Sistema ACP 48
111.1.1 - O Barramento VME 54
111.1.2 - O Microprocessador "MC68020"
111.1.3 - Classificação da Arquitetura do Sistema ACP
59
111.1-4 - Avaliaçgo do "Gargalo" do Sistema ACP
61
111.2 - "ACPSYS"
111.3 - Sistema em Tempo Real
CAPITULO IV
Avaliaçgo Experimental do Desempenho do Multiprocessador ACP
IV.l - Avaliação Experimental do Desempenho do Multiprocessador ACP em Problemas do tipo "Orientado para Eventos"
xix
IV.l.l - Desenvolvimento do Programa de Simula~Eio
78
IV.l.l.l - Algoritmo do Programa executado pelo Computador Hospedeiro
IV.1.1.2 - Algoritmo do Programa executado pelos Processadores do Sistema ACP
IV.1.2 - Estudo da "DEGRADACBO" do Sistema ACP
IV.1.2.1 - AnAllse dos resultados 89
IV.1.2.2 - Determinação do Tempo de Transmissão de um bloco de dados do uVAXII para um processador
94
IV.1.3 - Estudo da "ACELERACXO" do Sistema ACP
IV.1.3.1 - AnAlise dos resultados 97
IV.2 - Obtenção de um Modelo Analitico de Desempenho para o Sistema ACP
102
IV.2.1 - Comprovação do Modelo
IV.3 - Avaliação Experimental do Multiprocessador ACP em problema com comunicaçZo entre processadores.
071
IV.3.1 - Desenvolvimento do Programa de Simulação
107
IV.3.1.1 - Algoritmo do Programa executado pelo Computador Hospedeiro
IV.3.1.2 - Algoritmo do Programa executado pelos Processadores do Sistema ACP
115
IV.3.1.3 - Análise dos Resultados 116
IV.3.2 - Estudo da DEGRADAÇBO do Sistema ACP
119
IV.3.2.1 - AnBlise dos resultados 123
IV.3.3 - Estudo da ACELERAÇBO do Sistema ACP
125
IV.3.3.1 - AnBlise dos resultados 130
CAPITULO V
REFERENCIAS BIBLIOGRAFICAS 137
APENDICE A
APENDICE B
APENDICE C
ÃPENDICE D 153
APENDICE E 156
APENDICE F
CAPITULO I
INTROBUÇXO
Supercornputadores tem sido definidos como os
computadores mais potentes disponiveis em cada hpoca. Essa
potência computacional pode ser expressa
quantitativamente em termos de capacidade de realizaçgo de
operap3es aritmeticas por unidade de tempo, da capacidade
de memória e da precisão na realização dos cálculos.
Existem atualmente aplicaç8es que requerem máquinas
100 vezes mais rápidas que os atuais Supereomputadores.C277
Assim como em outras Areas de pesquisa, a necessidade
computacional em Fisica de Altas Energias tem crescido
tanto que computadores convencionais não são mais capazes
de satisfazê-la. Uma Cmica experiência & capaz de
produzir centenas de milhões de eventos, onde cada evento
composto em m&dia por um conjunto de 5Kbytes de dados e
necessita para o seu processamento de alguns segundos do
tempo de uma Unidade Central de Processamento(UCP). O
Fermi National Laboratory" criou o Advanced Computer
Program em colaboração com outras instituições de pesquisa
em Fisica de Altas Energias, entre elas o CBPF, para o
desenvolvimento de computadores capazes de suprir esta
necessidade.
Podemos dividir em duas, as linhas de pesquisa para se
aumentar o desempenho dos computadores:
O primeiro est8 em aumentar a velocidade com que uma
instrução pode ser executada atravks do uso de novas
tecnologias, tais como Arseneto de Galio, filmes
Supercondutores e optseletránica. Espera-se que, com as
novas tecnologias, se possa atingir um grande fator de
redução dos atuais ciclos de máquina, ou seja uma
minimização do atraso dos circuitos dos computadores, onde
um ciclo de máquina B definido como sendo o tempo
necessário para executar a menor fase de processaments de
uma instrução.
O segundo caminho está em aumentar o poder
computacional introduzindo elementos de multiprocessamento,
de forma a termos mhltiplos processadores com membria
compartilhada e perif6ricos sob o controle de um sistema
operacional integrado, isto 6, um Sistema Multiprocessador.
O ADVANCED COMPUTER PROGRAM segue a linha que pesquisa
o desenvolvimento de Sistemas Multiprocessadores. O
Multiprocessador ACP, primeiro projeto do grupo ADVANCED
COMPUTER PROGRAM teve como finalidade satisfazer problemas
do tipo "orientado para eventos". Neste tipo de problema,
um mesmo processo B executado em dados diferentes centenas
de milhaes de vezes, senda cada resultado de
processamento independente dos resultados anteriores. Este
tipo de processo & caracterizado por:
Necessitar de muito tempo de UCP (Unidade Central de
Frocessamento)
Realizar poucas opera~f3es de "entrada/saida "
Requerer pouca ou nenhuma interaçgo entre os
processadores C17
O objetivo desta tese 6 o estudo experimental do desempenho
do Sistema Multiprocessador Paralelo ACP.
Neste trabalho, apbs uma rApida descriçgo das
arquiteturas paralelas existentes e de suas classificaçf3es
(CAPITULO 11) 6 apresentado um estudo do SISTEMA
MULTIPROCESSADOR PARALELO ACP (CAPITULO 111).
Com base neste estudo t2 apresentado uma proposta de
avaliaçgo experimental do desempenho do SISTEMA ACP para o
processamento de problemas para os quais a mAquina foi
projetada, isto 6, para problemas do tipo "orientado para
eventos" (CAPITULO IV.1).
Em um segundo passo seis8 avaliado o desempenho da
máquina em aplicaçaes onde o processamento de cada
processador 6 uma tarefa que depende do processamento dos
processadores vizinhos, isto 6, em problemas onde existe
comunicação entre os processadores, e cada processador
processa uma s8rie de subtarefas que fazem parte de uma
dnica tarefa global (CAPITULO IV.3).
Com base nos resultados dos estudos realizados siXo
fornecidas sugesttjes para o desenvolvimento de um modelo
anãlitico para o Sistema ACP (CAPITULO IV.2)
Por fim, apresentaremos as csnclustles do estudo
realizado (CAPIWLO V 1.
CAPITULO I1
APRESENTAÇKO DAS ARQUITETURAS PARALELAS EXISTENTES E
DE SUAS CLASSIFICAÇBES
O termo confluência 8 muito empregado em Ciência de
Computação. Ele se refere a existência de diversas
atividades simultaneas ou paralelas que convergem para
uma soluçgo conjunta, tmicii. Podemos definir processamento
paralelo como sendo uma forma de processamento que procura
explorar nos processos a computação de eventos confluentes.
Podemos dividir a implementação do processamento paralelo
em 4 níveis C253:
Em um primeiro nivel, um maior grau de processamento
paralelo é implementado entre os m~ltiplos processos
atrav8s da multiprogramação (seçãoII.1.51, do tempo
compartilhado (seçãoII.1.6) e do multiprocessamento
(seçãoII.1.7).
O segundo nivel é o paralelismo conduzido entre
processos ou tarefas (segmentos de um programa) dentro
de um mesmo programa. Isto exige a decomposição de um
programa em mQltiplas tarefas.
3. O terceiro nivel o estabelecer o paralelismo entre
instruçBes, assim como quebrar sequências como em
"laços de instrução "(loop), para revelar o paralelismo
entre as instruçaes.
4. O quarto nivel & o da intrainstruçZio, que B
Implementado por meios de hardware. Como exemplo temos
o caso do processamento vetorial onde a Unidade Lógica
e Aritimetica (ULA),& composta por mhltiplas unidades
funcionais que possibilitam a execuçgo de operaçaes
simultAneas em todos os componentes do vetor.
Iremos definir "granularidade" como o nivel de
paralelismo de um programa. Podemos determinar que um
programa com granularidade fina e um programa cujo grau de
paralelismo estA entre os niveis 3 e 4; e um programa com
granularidade grossa 8 um programa cujo grau de paralelismo
estA entre os niveis 1 e 2.
11.1 - IMPLEMEWI'AÇIXO DO PARALELISMO EM SISTEMAS
UNIPROCESSADORES
Um sistema de computaçZio convencional , tambem
conhecido por mAquina de Von-Neuman, consiste de cinco
unidades : ENTRADA, MEMORIA, UNIDADE
LOGICO-ARITMETICA,CONTBOLE E SAIDA, relacionadas entre
si segundo a figura2.1C273.
As funçfies dessas unidades são:
1. ENTRADA; que transmite dados e instruçaes do
ambiente exterior para a membria.
2. MEMORIA; que armazena instruções, dados e
resultados intermedihrios e finais.
3. UNIDADE LOGICO-ARITMETICA; que executa as operaçaes
lbgico-aritméticas.
4. CONTROLE; que interpreta as instruções e
providencia sua execução.
5. SAIDA; que transmite os resultados finais para o
ambiente exterior.
Um processador que segue o paradigma de Von-Neumam
C273, executa instruçaes sequencialmente, de acordo com
o ciclo mostrado na figura 2.2.
O processamento paralelo pode ser implementado na
estrutura acima citada por diversas maneiras:
UNIDADE C E N T R A L DE P R O C E S S A M E N T O I /
CALCULO DO BUSCA DA ENDEREÇO EFETIVO INSTRUÇÃO DECODIFICAÇÃO DO OPERANDO
CALCULO PROXIMO DO
ENDEREÇO
EXECUÇÃO BUSCA DE OPERANDOS
FIG. 2.2 - CICLO DA EXECUÇÃO DE UMA INSTRUÇÃO DE UM PROCESSADOR VON-NEUMAN
11.1.1 - Multiplicidade de Unidades Funcionais
Os primeiros computadores possuiam apenas uma ULA
em sua cpu. Desta maneira a ULA podia executar
apenas uma instrução por vez. Na prática muitas
das funç6es da ULA podem ser distribuidas em
mtaltiplas unidades funcionais especializadas que
podem operar em paralelo.
11.1.2 - Paralelismo e "Pipeline" dentro da Unidade
Central de Processamento
Atualmente são construidos em quase todas as
Unidades Centrais de Processamento, ou UCPs
somadores paralelos utilizando a técnica de
somadores de alta velocidade, ("carry lookahead"),
tkcnicas de multiplicadores de alta velocidade e de
divisão de convergência para as funções de
multiplicaç$o e de divisão.
Várias fases da execuçCLo de uma instrução s3o
feitas em "pipeline" , incluindo busca de instruçso
, decodificaçgo, busca de operandos, execução na
unidade 16gica e aritmktica e armazenamento de
resultados.
11.1.3 - Alternância entre as Operações de
UNIDADE CENTRAL DE PROCESSAMENTO e as de Entrada e
de Saida
OperaqBes de entrada e de saída ( E / 3 ) , podem ser
realizadas simult&neamente com operações de UCP
com a utilização de controladores de E/S, de canais
e de processadores de E/S separados. Para
possibilitar a transferência direta de dados
entre a membria e componentes de E/S utilizando
mbdulos de " Direct Memory Access " (DMA) que
funciona na modo " roubo de ciclo de UCP ".
11.1.4 - Utilização de um Sistema de Membria
Hierárquico
A existencia de um caminho de dados entre o
processador e a membria, representado pelas fases
de busca de instru~ão e operandos na membria
constitui-se no aspecto mais restritivo do
desempenho de processadores convencionais. Essa
restrição adv8m do fato que o ciclo de acesso a
membria b muito mais lento que um ciclo do
processamento. Este aspecto dos processadores
convencionais tornou-se conhecido como o "gargalo
de Von-Neuman" , devido ao seu papel limitador no
desempenho computacional.
Uma maneira de se contornar este problema estd na
implementação de um sistema hierdrquico de
rnembria(fig. 2.31, onde o nivel mais alto 8 o dos
registros que s2Xo diretamente endereçados pela
Unidade Lbgica e Aritmbtica, ULA . A seguir uma
mem6ria mais rápida que a memória real, uma
"membria cache" pode ser utilizada para armazenar
dados mais usados pela UCP. Uma memória virtual
pode ser implementada no nivel mais baixo ao serem
utilizados membria de massa, discos e unidades de
fita.
$P ,P ,S = Multiprograma~ao
Em um computador podem existir dentro de um mesmo
intervalo de tempo mfiltiplos processos ativos
competindo pela membria, pelas unidades de E/S e
pelos recursos da UCP.
A execução simultanea de v8rios tipos de
programas no computador é possivel de ser realizada
pelo fato de alguns programas serem CPU-bound ( de
computação intensiva) e de outros processos serem
I/O- bound (E/S intensiva), ocorrendo execuç6es
simultaneas de operações ou de CPU ou de E/S para
programas diferentes.
11.1.6 - Tempo Compartilhado A multiprogramação em um sistema uniprocessador
centrada em torno da alternancia da alocação da
UCP entre vtirios programas. Para evitar que um
programa com maior prioridade ocupe a UCP por muito
tempo é implementado no sistema operacional o
conceito de tempo compartilhado. O conceito é uma
extensão da multi-programação onde são fornecidas
cotas fixas de tempo para mfiltiplos programas.
11.1.7 - Multiprocessamento
Na multiprogramação os processos compartilham o
bico processador da miiquina. Neste caso, a
simultaneidade sbmente ocorre quando vArias
operaçtks de E/S estão sendo executadas pelas
unidades de E/S, ao mesmo tempo que um outro tipo
de instrução esta sendo executado pela UCP.
Em multiprocessamento, os processos são executados
em paralelo por uma rede de processadores
fortemente acoplados, jii em processamento
distribuído os processos ficam associados a
processadores fracamente conectados por uma rede de
comunicação.
Convkm observar que as formas de concorrência não
sClo exclusivas, pois & possivel existir
multiprogramação nos processadores de mAquinas que
suportam multiprocessamento bem como e possivel
existir sistemas de processamento distribuido cujos
processadores são multiprocessadores e etc.
14
11.2 - CLASSIFICAÇCYES DAS ESTRUTURAS DE COMPUTACXO
PARALELA
Computadores paralelos são definidos como como
computadores que "enfatizam o processamento paralelo".
Baseada nesta definição foram implementadaã vkrias
classificações das arquiteturas dos computadores
paralelos existentes.
Apresentaremos três classificações:
A primeira a ser apresentada é a classificação feita
por K.Hwang e F. Briggs C251. Esta
classificaçgo divide os computadores paralelos em
quatro grupos de arquiteturas: Computadores Pipeline ,
Array Processor , Sistemas Multiprocessadores e
Dataf low .
A segunda a ser apresentada B a classificação de
Flynn C257. Esta classificação se baseia na
multiplicidade em sistemas computationais de
sequeficia de instruções ( instruction stream 1 e de
sequencias de dados ( data stream 1 .
A terceira classificação a ser apresentada 6 a
classificação de HockneyC317. Esta
classificação foi feita como consequência do
aparecimento de grande variedade de computadores
paralelos MIMD(c1assificação de FLYNN) durante a dkcada
de 80. De maneira que esta classificaç30 pode ser
considerada como uma complementação da classificação de
FLYNN .
Existem ainda outras classificações tais como a de Feng
C257 implementada em 1972 que 8 baseada na comparação
entre processamento paralelo e processamento serial, e
a classificaçSo de HandlerC253 implementada em 1977 e
que determina o grau de paralelismo e de pipeline em
varias niveis do sistema, mas que não stlo de interesse
para o nosso estudo.
Esta classificaçZo divide os computadores paralelos
em quatro grupos de arquiteturas:
11.2.1.1 - Computadores Pipeline
11.2.1.2 - Array Computer
11.2.1.3 - Sistemas de Multiprocessadores
11.2.1.4 - DATAFLOW
11.2.1.1 - Computadores Pipeline Pipelining tem sido a tecnica de paralelismo
mais utilizada para aumentar o desempenho dos
sistemas de computação C253. Pipeline é uma
estrutura que consiste de uma sequência de
estagios, através dos quais uma computação flui
com a propriedade de que a cada ciclo uma nova
computação possa ser iniciada no primeiro
estkigio de pipeline, enquanto outras operações
evoluem para os est8gios seguintes no pipeline.
Normalmente a execução de uma instrurpão em um
processador requer quatro passos principais:
1. Busca da instrução
2. Decodificação da instrução
3. Busca do operando
4. Execução da operarpão
Um computador sem pipeline necessita de quatro
ciclos de pipeline para executar uma instrução.
Em um computador com pipelining de instruções,
a execução de uma sequência de instruções
pode ser pipelined atravès da superposição
e . concorrência) das fases do ciclo de
execução de instruçgo. O pipeline funciona de
forma que enquanto uma instrução est8 no passo
um de execução, uma segunda instrução est8 no
passo dois, uma terceira no três e uma quarta
instrução no passo quatro. Isto 6, o
paralelismo existente no processamento das
instruções ocorre a nivel das fases do ciclo de
execurpão .
No computador pipeline apresentado na figura
2.4, uma vez inicializado o carregamento das
instruções nos estagios de pipeline um
resultado de saída & produzido a cada ciclo de
pipeline , reduzindo o ciclo original a um
quarto. Em um computador sem pipeline , estes
quatro passos devem ser completados antes da
operação da prbxima instrução.
Podemos ter tambkm pipelining de processadores,
onde uma sequência de dados k processada por
uma cascata de processadores i . . , vArios
processadores conectados em linha), na qual
cada processador executa uma tarefa especifica
sobre os dados.
Com o intuito de aumentar o desempenho,
sistemas de computação apresentam pipelining em
diversos niveis. No nivel mais alto, existe o
pipelining no processamento das instruções.
Depois, no segundo nivel, cada uma das fases do
processamento das instruçl5es é executada de
forma pipelined. Finalmente, num terceiro
nivel, encontra-se a execução pipelined das
operações aritmkticas C271.
11.2.1.2 - "Array Computers"
Um array processar & um computador paralelo
I f f f f f
DIAGRAMA DE ESPAÇO/ TEMPO DE UM PROCESSADOR 'IPIPELINE" DE 3 ESTAGIOS
T E M P O ( CICLOS DE "PIPELINE "1
DIAGRAMA DE ESPAÇO/ TEMPO DE UM PROCESSADOR SEM "PIPELINE"
E X - EXECUÇÃO DA OPERAÇÃO
B O - BUSCA DO OPERANDO
D i - DECODIFICAÇÃO DA INSTRUÇÃO
B I - BUSCA DA INSTRUÇÃO
TEMPO
sincrono com mtaltiplas unidades ldgicas
aritiméticas chamadas de elementos de
prscessamento (EP),que podem operar em paralelo
de uma maneira sincrona t253. Os EP são
sincronizados de maneira a executarem a mesma
instrução ao mesmo tempo. Um tipico array
processor é apresentado na fig 2.5 (a) onde uma
unidade de controle dirige as instruções de
controle e escalares. Os EPs são unidades
passivas sem capacidade de decodificaçEío da
instruçClo.
Um array processor 6 geralmente interfaceado a
um computador hospedeiro atrav6s da unidade de
controle. O computador hospedeiro & geralmente
um computador de uso geral que serve como
gerenciador de operação" do sistema.Dentre as
funções do computador hospedeiro consta a de
alocação de recursos e de supervisão de
perifkricos e de unidades de E/S. A unidade de
controle do array processor supervisiona
diretamente a execução dos programas, enquanto
que o hospedeiro executa as funções de E/S
entre o sistema e o mundo externo.
A motivação original para o desenvolvimento de
array procesor SIMD (apresentado na secçClo
11.2.2) foi a de realizar a computação paralela
E P - ELEMENTOS DE PROCESSAMENTO
PC - PROCESSADOR DE CONTROLE
CM- MEMÓRIA DE CONTROLE
P - PROCESSADOR
M - MEMÓRIA
9
FIG. 2.5.0 - DIAGRAMA DE UM "ARRAY PROCESSOR" COM REDE DE CONECÇÃO ENTRE OS ELEMENTOS DE PROCESSAMENTO
UNIDADE DE CONTROLE
m Ecl
BARRAMENTO : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DE DADOS
I r i i
E P - ELEMENTO DE PROCESSAMENTO
M - M E M O R I A
UC - UNIDADE DE CONTROLE
MUC - MEMORIA DA UNIDADE DE CONTROLE
FIG. 2.5.b - DIAGRAMA DE UM ARRAY PROCESSOR COM REDE DE CHAVEAMENTO ENTRE OS ELEMENTOS DE PROCESSAMENTO E OS MODULOS DE MEMORIA
22
em dados do tipo vetoriais e matriciais.
Algoritimos de processamento paralelo foram
desenvolvidos por muitos pesquisadores de
m8quinas SIMD. Tais algoritimos são
importantes na realizaçtio do cálculo de
multiplicação de matrizes, Fast Fourier
Transform (FFT), transposiç2ío de matrizes,
somatbrio de elementos vetoriais, inversão de
matrizes, recorrência linear, operações
booleanas de matrizes e equações diferenciais
parciais.
Geralmente um array processor assume uma das
duas configuraçaes apresentadas na fig 2.5
11.2.1.2.1 - Array Processor com Membria
Local
A figura 2.5 (a) apresenta uma configuração
contendo N EPs, sincronizados sob o
controle de uma unidade de controle. Cada
EF é essencialmente uma unidade lbgica
aritimktica conectada a registros
contendo uma membria local para
armazenamento dos dados distribuídos.
unidade de controle também possui
membria prbprla para o armazenamento
programas.
e
o
A
uma
dos
11.2.1.2.2 - Array Processar com Membria
Compartilhada
Uma outra configuração que difere da figura
2.5 (a) é apresentada na figura 2.5 (b) ;
as memórias locais acopladas a cada EPs são
substituidos por módulos paralelos de
memória compartilhados por todos os EPs
através de uma rede de alinhamento que
chaveia as conexBes entre os EPs e as
memórias.
11.2.1.3 - Sistemas Multiprocessadores
A diferença fundamental entre um sistema array
precessor e um sistema multiprocessador é que
em um array processor os elementos operam de
uma maneira sincrona enquanto que um sistema
multiprocessador opera de uma maneira
assincrona.
Uma organização básica de um sistema
multiprocessador é apresentada na fig 2.6. O
sistema contèm dois ou mais processadores de
aproximadamente mesma capacidade. Os
processadores compartilham o acesso a uma série
de mbdulos de memória, canais de E/S e unidades
MEMÓRIA I COMPART IL.
CANAIS DE E/S
REDE DE CONECÇÃO ENTREOSPROCGSSADORES
E AS MEMORIAS
REDE DE INTERRUPÇÃO
MM - MÓDULO DE MEMÓRIA
ML - MEMORIA LOCAL
P - PROCESSADOR
F I G . 2.6 - DIAGRAMA DE UM SISTEMA MULTIPROCESSADOR
periféricas. 0 mais importante é que o sistema
global deve ser controlado por um sistema
operacional anico integrado que possibilita a
interaçga entre os processos e seus programas
em vários niveis. Independentemente da memória
compartilhada e das unidades de E/S, cada
processador possui sua memória local e unidades
privadas. A comunícação entre os processos
pode ser feita atravès de uma memória
compartilhada ou por uma rede de interconexão.
A organização do hardware de sistemas
multiprocessadores d determinada primeiramente
pela interconeyão estrutural a ser utilizada
entre as memórias e os processadores ( e entre
memórias e canais de e/s caso necessdrio).
De uma maneira simplificada podemos
caracterizar multiprocessadores por dois
atributos: em primeiro lugar um
multiprocessador B um computador que inclui
mhltiplos processadores e em segundo lugar os
processadores podem se comunicar e cooperar em
diferentes níveis para solucionar um
determinado problema. A comunicação pode
ocorrer seja pelo envio de mensagens entre os
processadores, seja pelo compartilhamento de
uma memória comum.
Existem algumas similaridades entre sistemas
multiprocessadores e sistemas de
multicomputadores, j B que ambos são motivados
pela mesma finalidade que B a de dar suporte
para operaçf5es concorrentes no sistema.
Entretanto existem distinções importantes entre
um sistema de computação mUtipla e um sistema
multiprocessador baseado na implementaçtio do
compartilhamento de recursos e no grau de
cooperação para a solução de um problema.
Um sistema de computaçgo mUtiplo consiste em
v8rios computadores aut6nomos que podem ou
ngo se comunicar. Um sistema multiprocessador
& controlado por um sistema operacional que
permite uma interação entre os processadores e
seus processos a nivel dos dados e dos
conjuntos de dados,
Podemos classificar as arquiteturas de
multiprocessadores como sendo fortemente ou
fracamente acopladas.
11.2.1.3.1 - ARQUITETURAÇ DE
MULTIFROCESSADORES FORTEPENTE ACOFLADOS
Em uma arquitetura fortemente acoplada (fig
2.11) a ~o~unicaçgo 6 realizada por uma
memória compartilhada, de maneira que a
taxa com que um processador pode tranferir
um dado depende da taxa de transferência
da mem6ria. Neste tipo de arquitetura, os
processadores podem apresentar uma memória
local de rapido acesso.
Este tipo de conexgo pode ser implementado
atravks da inserção de uma rede de
interconexão entre os processadores e a
memória, ou atrav6s de uma membria
multiportas. Um dos fatores que limita a
expansão do nhmero de processadores nos
sistemas fortemente acoplados 6 a
degradaçso do desempenho devido a contençgo
de memória que ocorre quando dois ou mais
processadores tentam acessar a memória em
uma mesma unidade de tempo. O grau de
conflito pode ser reduzido com o aumento de
intercalagem de membria.
11.2.1.3.2 - ARQUITETURAS DE
MULTIPROCESSADORES FRACAMENTE ACOPLADOS
Sistemas fracamente acoplados (fig 2.12)
geralmente não apresentam o mesmo grau de
.REDE DE CONEXÃO ENTRE OS
PROCESSADORES E OS MODYLOS DE MEMORIA
FIG. 2.1 1 - ARQUITETURA DE UM SISTEMA MULTIPROCESSADOR FORTEMENTE ACOPLADO
29
conflito presente em sistemas fortemente
acoplados. Em tais sistemas cada
processador possui uma série de unidades de
E/S e a maior parte das instruçaes e dos
dados sZXo acessados em uma membria local.
Iremos chamar de um módulo de computador
por um sistema composto pelo processador
pela sua mem6ria local e pelas interfaces
de E/S.
Processos executados em mddulos de
computadores diferentes se comunicam
atrav8s de troca de mensagens. O grau de
acoplamento em tal sistema 6 muito fraco,
de maneira que 8 por vezes chamado de
sistema distribuido.
Sistemas fracamente acoplados são
normalmente eficientes quando as interaçGes
entre as tarefas sao curtas. Sistema
fortemente acoplados podem tolerar um alto
grau de interaçzo entre as tarefas sem uma
significativa deteriorização do desempenho.
11.2.1.4 - "Dataflow"
LOCAL
PROCESSA-
1 (p) 1 p&-, CHAVE DE
ARBITRAGEM I ( C C A ) I
(a 1 UM MÓDULO COMPUTADOR (b) MODULOS DE COMPUTADORES FORMANDO UM SISTEMA
MULTIPROCESSADOR FRANCAMENTE ACOPLADO
FIG. 2.12 - ARQUITETURA DE UM SISTEMA MULTIPROCESSADOR FRANCAMENTE ACOPLADO
31
Existe também o conceito de "dataflow" cujo
principio btisico é o de permitir a execução de
uma operação sempre que operandos se tornam
disponíveis de maneira que os "contadores de
programa" tornam-se denecessArios para
direcionar a computação. A iniciação de uma
instrução depende da disponibilidade dos dados
e & independente da localização física da
instrução no programa. Ou seja, as instruç6es
no programa não são ordenadas, e a execução
obedece o fluxo dos dados (figura 2.7).
Te6ricamente uma concorrência mtixima pode ser
explorada nesta estrutura sendo limitada apenas
pela disponibilidade dos recursos de hardware.
Implementaç6es de processamento paralelo em cada um
dos níveis citados n2Xo são mutuamente exclusivas.
De fato, a maior parte dos computadores atualmente
existentes são pipeline e alguns deles assumem
tambèm estruturas de array ou de
multiprocessadores.
11.2.2 - ClASSIFICAÇKO DE FLYNN
11.2.2.1 - "SINGLE INSTRUCTION STREAM SINGLE
DATA STREAM" (SISD)
Arquiteturas que se baseiam na execução de uma
sequencia de instruções para uma sequ&ncia
IMPL EMEMTAÇÁO DO "DATA FLOW"
E M TABELAS
PACOTE DE PACOTE DE RESULTADOS O P E R : A Ç ~ E S
MECANIÇMG BASICO DO "BATA F L O W "
CONECÇ~ES PARA T R A N S F E R ~ N C I A S DE MENSAGENS -* ACESSO a LEITURA/ESCRITA
,-c, ACESSO A LEITURCi
33
de dados. Esta classificação apresentada na
fig 2.8 (a) representa a maioria dos
computadores seriais atualmente existentes. As
instruções são executadas sequ@ncialmente
podendo ser sobrepostas no estagio de execução.
A maioria dos computadores SISD utilizam
pipeline . Um computador SISD pode ter mais de
uma unidade funcional sob o controle de uma
unidade de controle.
11.2.2.2 - "SINGLE INSTRUCTION STREAM MULTIPLE
DATA STREAM" (SIMD)
Arquiteturas que se baseiam na execução de uma
sequência de instruções para m6ltiplas
sequências de dados. Esta d a classe
correspondente aos array processors acima
citados ( fig 2.8 (b) onde mhltiplos
elementos processadores estgo sob a supervisso
de uma anica unidade de controle. Todos os EP
recebem a mesma instrução da unidade de
controle.
11.2.2.3 - "MULTIPLE INSTRUCTION STREAM SINGLE
DATA STREAM" (MISD)
Arquiteturas que se baseiam na execução de
maltiplas sequências de inãtruções para
apenas uma sequência de dados. Neste modo de
processamento cada um dos n processadores
recebe instruçtks distintas para operar sobre o
COMPUTADOR SISD
-- --
COMPUTADOR SIMD
COMPUTADOR MISD SI
SII * ""' 5.5 SI 1 * s D 2 * IMM,I . . . .
MC 0 .
SIN SD, ZN
COMPUTADOR MIMD
UC - UNIDADE DE CONTROLE
UP - UNIDADE DE PROCESSAMENTO
MM - MÓDULO DE MEMORIA
s I - SEQUÊNCIA DE INSTRUÇ~ES
S D - SEQUÊNCIA DE DADOS
MC - MEMÓRIA COMPARTILHADA
FIG. 2.8 - CLASSIFICAÇÃO DE FLYNN
35
mesmo data stream ( figura 2.8 (c) 1 . Este
tipo de estrutura tem recebido muito pouca
atenção, sendo considerada impraticável por
pesquisadores.
11.2.2.4 - "MULTIPLE INSTRUCTION STREAM
MULTIPLE DATA STREAM" (MIMD)
Arquiteturas que se baseiam na execuçSo de
multiplas sequências de instruçaes para
miiiltiplas sequências de dados. A maior parte
dos sistemas multiprocessadores podem ser
classificadas nesta categoria. Um computador
MIMD Pntrinseco apresenta interaçfies entre os n
processadores onde os dados SEXO obtidos da
mesma regiao de membria, compartilhada por
todos os N processadores, ( figura 2.8 (d) 1.
11.2.3 - CLASSIFICAÇEO DE HOCKNEY
Durante a decada de 80, surgiu uma grande
variedade de computadores paralelos MIMD. Para
analisd-la, Hockney C313 propos uma classificaçSo
estrutural da classe MIMD em três niveis básicos.
Em um primeiro nivel podemos dividir os sistemas
multiprocessadores em dois grupos : sistema-
chaveados e sistemas em rede (fig 2.9).
FIG. 2.9 - CLASSIFICAÇÃO DE HOCNEY
11.2.3.1 - SISTEMAS CHAVEADOS
Em sistemas chaveados existe uma unidade de
chaveamento que conecta os processadores aos
módulos de memdria. Computadores paralelos com
dezenas e centenas de processadores geralmente
utilizam redes de maltiplos est8gios.
Para sistemas chaveados a expansgo do sistema é
limitada apenas pelo tamanho da chave de
matriz; ela pode ser expandida modularmente
dentro das limitações do projeto. Para a
prevenção contra falhas da chave e do sistema,
pode ser implementada uma segmentação e/ou
redundancia da chave. A adiçgo de unidades
geralmente aumenta o desempenho, isto é, um
maior potencial para a eficiencia do sistema
sem reprogramaçao do sistema operacional.
Dentro desta
segundo nivel
os sistemas
compartilhada
(fig. 2.10).
mesma classe podemos ter um
de classificaçgo em que dividimos
em sistemas de membria
e sistemas de memória distribuida
CH
AV
EA
DO
S
ME
MÓ
RIA
C
OM
PA
RT
ILH
AD
A
S I
UL
TR
A
EL
XS
I 6
40
0
CE
DA
R
BA
LA
NC
E 8
00
0
TR
AC
A
LL
IAN
T F
X/3
B
BN
BU
TT
ER
FL
Y
-
I
MU
LT
I-
BA
RR
AM
EN
TO
ES
TAGI
OS
BA
RR
-AM
EN
TO
ES
TA
GIO
S
CR
UZ
AD
O
I P
AS
M
11.2.3.1.1 - SISTEMAS DE MEMORIA
COMPARTILHADA
Em sistemas de memória compartilhada,
processadores são conectados a módulos de
membria compartilhada via uma unidade de
chaveamento. Desta maneira a memória é
compartilhada por todos os processadores de
uma maneira equalitAria, normalmente
contendo um grande espaço de endereçamento.
Tal sistema 6 tambkm chamado de sistema de
memória comum. Nestes sistemas a memória k
global e seu espaço de endereçamento é
bico e comum a todos os processadores.
11.2.3.1.2- SISTEMAS DE MEMORIA DISTRIBUIDA
Em sistemas de membria distribuida, cada
processador tem sua própria memória e
utiliza a rede para se comunicar com os
outros processadores via troca de
mensagens. SfXo incluidos OS
multiprocessadores cu jos espaços de
endereçamento sao finicos (virtual), porem
distribuidos pelas membr ias dos
processadores. A rede é utilizada pelos
processadores para acesso remoto a memória.
Existem exemplos de puros sistemas de
membria compartilhada e de puros sistemas
de memória distribuida. Em grandes
sistemas chaveados podemos encontrar ao
mesmo tempo membria local (distribuida) e
membria global (compartilhada). Tais casos
são classificados como sistemas hibridos.
Ambos os sistemas de membria compartilhada
e de membria distribuida podem ser
subdivididos em : sistemas de "barramento
cruzado", sistemas multi-estkgios e de
barramento dnico.
11.2.3.2 - SISTEMAS DE REDE
Nos sistemas de rede , a membria é distribuida
e os processadores são interconectados atravès
de uma topologia definida. Em função da
topologia OS computadores podem ser
classificados em malha,ctabica, reconfigurtivel e
hierárquica (fig 2.9).
Tais sitemas são sistemas de membria
distribuida, jB que toda a membria &
distribuida pelo sistema como membria local.
Eles não podem ser definidos como sistemas
chaveados no sentido de que os elementos do
sistema ngo são ligados a uma unidade de
chaveamento. Elementos de processamento s6
podem se comunicar com elementos de
processamento que estão diretamente conectados
a eles. A comunicação entre EPs distantes
entre si s6 pode ser realizada através da
transferencia de dados por EPs intermediários
na rede.
Topologias das redes de elementos de
processamento :
1. REXIES EM MALHAS
Podemos encontrar malhas quadradas ,
hexagonais e outras. Em uma malha quadrada
de dimensão d, cada EP kconectado à 2 d EPs
vizinhos.
2. REDES CWBICAS
Encontramos nesta classe os cubos
multi-dimensgo ou hiperctabos binários. O
ntamero de EP não pode ser aumentado sem
antes aumentar o ntamero de conecçt3es para
cada EP.
3. REDES HIERARQUICAS
São redes com topologia recursiva, tais
como Arvores, piramidea, e cachos ( cluster).
4. REDES RECONFIGURAVEIS
Comportam todas as classes de redes nas
quais as interconexões podem ser trocadas,
seja por software a nivel de programação,
seja por hardware.
11.3 - AVALIAÇ#O DE DESEMPENHO
Uma das primeiras tentativas de se caracterizar o
desempenho de um computador foi realizada em 1960 por
J.C.Gibson da IBM C303, que realiza um programa com uma
série de instruções dinahAmicas e define tempo de
execução como sendo o tempo médio de execuçzo das
instruções. 8 inverso desta medida é entzo denominado
de MIPS que é a nt3mero médio de instruções realizados
por segundo.
O resultado da avaliação do ndmero de MIPS de uma
mAquina depende da escolha das sequências de
instruções escolhidas para a avaliaçgo.
Por exemplo, um computador "1" necessita para a
execução da instrução SENO A de 17 ciclos de máquina e
para a execução da operação MOV X de 3 ciclos de
mdquina. Um computador "2" necessita para a execução
da instruçgo SENO A de 10 ciclos de máquina e para a
execuçSo da operaçgo MOV X de 6 ciclos de maquina.
Caso a sequencia de instruções escolhidas contenha
100 operações MOV A e apenas uma operação SENO A o
computador 1 e o computador 2 necessitarão
respectivamente de 317 e de 610 ciclos de maquina para
executar a sequência .
Caso a sequehAncia de instruç6es escolhidas contenha
20 operações MOV A e 15 operaç6eâ SENO A o computador 1
e o computador 2 necessitarão respectivamente de 315 e
de 210 ciclos de maquina para executar a sequência .
Como demostrado pelo exemplo acima o resultado da
avaliação em MIPS de um computador & valido apenas para
comparações entre computadores de mesma familia, ou
seja que possuam a mesma arguitetura(esta & a razão
pela qual IBM assim como outras grandes companhias
apresentam suas novas m8quinas em comparaçSo as suas
antigas ) .
Extendendo o conceito da importancia da sequéncia
de instruções utilizadas para a avaliação do desempenho
de um computador, podemos concluir que a natureza da
aplicaçEio é um dos fatores fundamentais na avaliaçgo do
desempenho de um computador. (Por exemplo, o
desempenho de um supereomputador operando na modalidade
vetorial/paralela pode ser 100 vezes maior que o
mesmo sistema operando na modalidade
Foram entzo desenvolvidos benchmarks que
programas contendo sequências de instruções que
aproximam do comportamento das tipicas aplica~ões
linguagens de alto nível.
SEIO
se
das
Cada benchmark tem como finalidade avaliar o
desempenho de um computador para uma determinada
aplicação, podemos citar como exemplos de
benchmarksC303:
1. WHETSTONE
Desenvovido no final dos anos 60 por Curnow e
Wichman pelo U. K. National Physical Laboratory
in Whetstone, England. E baseado em estatisticas
coletadas originalmente em programas ALGOL mas é
mais popularmente implementado em FORTRAN. E em
geral utilizado para avaliar aplicações cientificas
e de engenharia. Os resultados são dados em
milhões de operações de Whetstone por segundo.
DHRY STONE
Desenvolvido por R.P.Weicker. Sua primeira
avaliação foi para programas em ADA. Ele enfatisa
os dados e operações encontradas no sistema ao
invés de programação nhmerica. Contèm 100 passos
com 15 procedures e function calls. Possui tambem
versão para C e Pascal. Os resultados s%o
fornecidos em milhões de Dhrystones por segundo.
3. Linpack
Desenvolvido por J. Bongarrara em 1979. E uma
coletanea de subrotinas Fortran para resolver
problemas de equações em algebra linear. O
Benchmarck consiste na resolução de 100 equações de
dupla precição. Os resultados são fornecidos em
termos de Linpack MFLOPS(mi1hões de operações de
ponto flutuante por segundo).
OBS :
Ao contrArio do que se imagina, não existe nenhum
padrão de medida de desempenho para computadores.
Mesmo para padrões existentes tais como
Whetstonee,Dhrystones e Linpack não é possivel de
se certificar da validade das medidas de desempenho
avaliadas. (Jack Dongarrara do Departamento de
Energia do Laboratorio Argonne em Illinois
respons8vel pela publicaç30 dos resultados do
Benchmarks Linpack não garante a autencidade de
seus dados)
11.4 - Conclusão
Demonstramos no inicio deste capitulo que o
processamento paralelo pode ser implementado em quatro
níveis:
Ao nivel do programa,ao nivel da tarefa, ao nivel da
inter-instrução e ao nivel da intra-instrução.
Fizemos então um estudo da implementação do
paralelismo em sistema uniprocessadores(se~o 11.1).
Extentendo este estudo realizamos um estudo das
estruturas de computadores paralelos e de suas
classificaçt5es. Verificamos que para uma determinada
classificação as implementações do processamento
paralelo em cada um dos niveis citados não são
mutuamente exclusivas. (Como exemplo segundo a -
classificaçao de K.HWANG, a maioria dos computadores
atualmente existentes s3o pipeline e alguns deles
assumem tambem estruturas de array ou de
multiprocessadores( seção 11.2.1))
Para entendermos a influencia da arquitetura do
computador paralelo na avaliação do seu desempenho
definimos o conceito de granularidade.
Definimos um programa de granularidade fina como um
programa cujo grau de paralelismo est8 ao nivel da
intraintrução, e um programa de granularidade grossa,
como um programa cujo grau de paralelismo est8 ao nivel
do processo.
A seguir, fizemos um estudo das avaliaçues de
desempenho existentes (seção 11.3) e concluimos que o
estudo do desempenho de computadores 6 uma função
complexa de muitos aspectos interrelacionados, tais
como arquitetura da mAquina, natureza da aplicação,
nivel de vetorização , paralelismo do programa e outros
mais.
Podemos então concluir que a determinação do
desempenho do sistema computacional ACP dever8 ser
feita baseada em fatores que levarão em consideração a
arquitetura do sistema e a finalidade de sua aplicação.
CAPITULO I11
O MULTIPROCESSADOR PARALELO ACP
Neste capitulo faremos uma descrição do Sistema ACP, de
sua arquitetura, do software desenvolvido para a sua
implementação ( ACPSYS 1 e de sua aplicação em sistemas
OFF-LINE e em sistemas de tempo real.
111.1 - ARQUITETURA DO SISTEMA ACP
Os "elementos de processamento" do Sistema ACP , OU simplesmente proeessadores do Sistema ACP . sao conectados em bastidores de padrão VMF, C173 para 20
mádulos, formando assim os "galhos" da Arvore.
Os bastidores VME são por sua vez interligados via
um barramento padrão RS485 , chamado BRANCH C47,
formando a raiz do sistema. O barramento BRANCH um
barramento de alta velocidade de transmissão de dados,
ZOMbytes/segundo, ele possui 32-bits de dados e pode
comportar ate 31 bastidores de padrão VME .
Barramentos Branch podem tambkm ser interligados a
um barramento chaveado, BUS SMITCH (figura 3.21C147 que
consiste de um bastidor capaz de interligar
bi-direcionalmente 16 BRAMCH BUS .
COMPUTADOR MESTRE MICROVAX I1 I
BARRAMENTO "Q - 22 ' L
UNIDADE DE FITA MAGNÉTICA
BARRAMENTO VME
BARRAMENTO VM E
BBC - INTERFACE CONTROLADORA DO BARRAMENTO."BRANCH"
BVI - INTERFACE DO BARRAMENTO TRONCO VME
DRVII- UNIDADE DE DMA
CPU - NÓ DE PROCESSAMENTO
B B T - TERMINAL DO BARRAMENTO TRONCO
YRM - ARBITRO DO BARRAMENTO VME
O L: a a m
O m
C VME z W I a a a
BVI CPU a I
VME I m
I O z a a m
VME O C Z
51
Um sistema possuindo 16 BRÃNCH BUS interligadas
pelo BUS SWITCH 6 capaz de realizar transferências
paralelas entre 8 pares de "Branch Bus", ou seja,
transferências de dados em ate 160 Mbytes/seg. Na
figura 3.3 apresentamos o exemplo da implementação de
um Sistema ACP com uma alta capacidade de
transferência de dados (até 240Mbytes/seg.)
Os elementos de processamento C57, (figura 3.4)
sgo compostos por:
1. um microprocessador comercial de 32 bits/lGMHZ,
MC68020 ou AT&T32100 , e seu respectivo
coprocessador de ponto flutuante,
2. 2Mbytes de membria real RAM, Random Access Memory ,
podendo ser expandida em at6 8 Mbytes. A membria
possui tempo de acesso para a leitura de 240ns e
para a escrita de 120 ns (O wait states).
3. saida para a implementação de 64k de membria não
vol8til PROM , Programable Read Only Memory . Esta
saida permite também a implementação de uma
interface seria1 para padrão RS232 e de outras
necessidades.
PROCESSAMENTO
BRANCH BUS --C
ELEMENTO DE
PROCESSADOR 6 8 0 2 0
ERRO NO BARRAMENTO
COPROCESSADOR 6 8 8 8 1 - I --, DETEÇÃO DE ERRO DE PARIDADE
I MB A 8 MB DE MEMÓRIA RAM I
BARRAMENTO DE DADOS DE END. E DE CONTROLE
INTERFACE MESTRE PARA VME
FIG. 3.4 - ESTADOS ASSUMIDOS PELOS ELEMENTOS DE PROCESSAMENTO DO SISTEMA ACP
4. interface para o barramento VME do tipo
"mestre/escravo". Esta interface permite que no
modo escravo a sua memória possa ser acessada por
qualquer mbdulo no barramento VME, e permite que no
modo mestre o processador tenha acesso direto às
memórias locais dos processadores do sistema. Cada
processador v@ as membrias locais dos
processadores do sistema como fazendo parte de uma
membria remota de 4 Gigabytes (figura 3.5).
111.1.1 - O BARRBMENTO VME
O barramento VME(VERSA MODULE EURBCARD) é um
barramento que satisfaz a sistemas de 8,16,e 32 bits.
E um barramento multi-processador, que permite o
compartilhamento de recursos de memória e de
entrada/saida entre vários cortaes mestres segundo uma
prioridade de acesso paralela ou alternada. A
estrutura do barramento VMF, possui quatro niveis de
prioridade de acesso. Ele B construido no conceito
"mestre/escravo" onde o mestre detem o controle do
barramento e o escravo depois de decodificar o endereço
e de obter o resultado de que B ele quem esta sendo
acessado, responde ao comando enviado pelo mestre.
BIT
S M
AIS
E
ND
ER
EÇ
O
BIT
S M
EN
OS
S
IGN
IFIC
ATI
VO
S
SIG
NIE
ICA
TIV
OS
NN
N N
NN
N O
XX
XX
X
XX
X
XX
XX
X
XX
X
XX
XX
X
XX
X
N N
NN
N N
N O
XX
XX
X
XX
X
XX
XX
X
XX
X
XX
XX
X
XX
X
NN
NN
N N
N O
XX
XX
X
XX
X
XX
XX
X
XX
X
XX
XX
X
XX
X
XX
XX
XX
X
o xx
xx x
xxx
xxxx
xxx
x xx
xx x
xxx
NN
NN
NN
N
I X
XX
X
XX
XX
X
XX
X
XX
XX
X
XX
O O
OX
X
NN
NN
NN
N I
XX
XX
X
XX
X
XX
XX
X
XX
X
XX
XO
O I X
X
NN
NN
NN
N I
XX
XX
X
XX
X
XX
XX
X
XX
X
XX
XO
IO
XX
NN
NN
NN
N I
XX
XX
X
XX
X
XX
XX
X
XX
X
XX
XO
I
I XX
NN
NN
N N
N I
XX
XX
X
XX
X
XX
XX
X
XX
X
XX
X I
X
XX
X
" A
DD
R E
SS
M
OD
IFIE
R"
00
1X
IO
00
1x0
I
00
1X
l 1
01
01
11
00
1X
OI
00
1X
OI
O0
1x0
I
O0
1x0
I
O0
1x0
I
RA
M - TR
AN
SFE
RÊ
NC
IA
UN
ITA
RIA
RA
M - T
RA
NS
FE
R~
NC
IA UN
ITA
RIA
RA
M - T
RA
NS
FE
RÊ
NC
IA
DE
BLO
CO
S
TR
AN
SF
ER
ÊN
CI A
DE
"B
RO
AD
CA
ST
'I
AT
IVA
E M
AN
TÉM
I'RE
SE
T"
NO
PR
OC
ES
SA
DO
R
DE
SA
TIV
A "
RE
SE
T"
PE
RM
ITE
'I B
RO
AD
CA
ST
"
IMP
ED
E "
BR
OA
DC
AS
T"
NÍV
EL
I DE
INTE
RR
UP
ÇÃ
O N
O P
RO
CE
SS
AD
OR
A natureza assincrona do barramento permite a
cohabitaçgo de processadores, de membrias, e de
periféricos apresentando caracteristicas e velocidades
diferentes.
O barramento tambkm possui recursos para a
implementação de um ciclo indivisivel de
"leitura/modificaç~o/escrita", que permite a
implernentaçtXo de sem8foros para o compartilhamento de
recursos. Sete niveis de interrupção podem ser
centralizados ou repartidos entre os processadores do
barramento.
Assim como o barramento Multibus 6 adaptado aos
microprocessadores da Pntel, o barramento VME foi
concebido especialmente para o microprocesador MC68000
C197. Podemos considerar o barramento VME como sendo
um ãub-conjunto do Versabus possuindo 96 das 120 linhas
deste barramento, o barramento VME foi concebido para
permitir a implementação dos formatos simples e dupla
Europa, de maneira que todos os sinais necess8rios para
um sistema de 16 bits s2io localizados em apenas um dos
dois conectores de 96 pinos.
111.1.2 - O MICROPROCESSADOR Me68020
O MC68020 6 a primeira implementação de 32-bit da
familia de microprocessadores MC68000 da MOTOROLA.Ele
utiliza a tecnologia de VLSI, possui registros de
32-bit, barramento de dados de 32-bit, 32-bit de
barramento de endereçamento, possui 18 modos de
endereçamento e um rico conjunto de instruções que
fornecem suporte para linguagens estruturada de alto
nivel e para sistemas operacionais sofisticados Cl83.
A estrutura do barramento do MC68020 & assincrona, e
utiliza um barramento não-multiplexado de 32-bits de
dadas. O proceãsador suporta um mecanismo que permite
a transferência de operandos para unidades externas
que possuem tamanhos de barramento dinamicos,~
tamanho da porta da unidade & determinado
automaticamente, baseado no metodo de cycle-by-cycle.
A interface de barramento dinâmica permite ao
processador uma transferência simples e um acesso
eficiente para unidades de diferentes tamanhas de
barramento de dados.
Um diagrama em blocos do MC68020 B apresentado na
figura 3.6. Os maiores blocos operam de maneira
independente para maximizar a concorrência das
operações enquanto se gerencia a sincronização entre
a execução da instrução e a operação do barramento. O
controlador de barramento carrega instruçaes do
barramento de dados na unidade de decodificaçao e na
BARRAMENTO 3EENDEREÇO
FIG. 3.6
- SEQUENCIADOR
UNIDADE DE "PREFETCH" DE CONTROLE . INSTRUÇAO E
DECODIFICADOR
f CONTROLADOR DE
BARRAMENTO
UNIDADE DE MEMORIA ''C-ACHE DE
INSTRUÇÃO
BARRAMENTO DECONTROLE
BARRAMENTO DE DADOS
SEQUENCIADOR
UNIDADE DE CONTROLE
FIG. 3.7
memória cache. As unidades de sequência e de
controle permitem controle do microprocessador,
gerenciando o barramento interno, registros, e funções
da unidade de execueão.
O MC68020 suporta três estágios de instruções em
pipe, seção 11.2. O pipeline ocorre internamente no
microprocessador e permite a operação concorrente de
até três palavras de uma dnica operação ou de at&
três operações de apenas uma palavra.
111.1.3 - CLASSIFICAÇRO DA ARQZJITETURA DO SISTEMA ACP
Segundo a classificação de FLYNN (seção 11.2.2) o
Sistema ACP, (figura 3.1) pode ser classificado dentro
da classe de processadores MIMD, MULTIPLE INSTRUCTION
MULTIPLE DATA por ser capaz de processar mdltiplas
sequências de instruções com maltiplas sequências
de dados.
Segundo a classificação de HOKNEY (seção 11.2.3)
dentro da classe MIMD, em um segundo nivel, ele pode
ser classificado como pertencente A classe de Sistemas
Multiprocessadores MIMD em Redes, pelo fato de a
ligação entre os elementos de processamento do Sistema
60
ACP não ser efetuada por chaveamento, e sim por
barramentos. Dentro da classe de Sistemas em Rede ele
pode ser incluido dentro de um terceiro nivel de
classificaçZo como fazendo parte da classe HierArquica,
por possuir os elementos de processamento ligados a um
barramento VME que por sua vez são ligados a um
barramenta BRANCH BUS , que sao ligados ao computador
hospedeiro. E por final, dentro desta classe, ele pode
ser incluído em um quarto nivel de classifica~ão, sendo
classificado como pertencente à classe de Sistemas de
Arquitetura Arvore, devido topologia da ligação.
Segundo a classificação de K.Hwangg/F.Briggs, ele
pode ser classificado no grupo de sistemas
Multiprocessadores com Arquitetura Fracamente Acoplada
(seção 11.2.1.3.2) por possuir "mbdulss de computaçzo
interligados por barramentos. Entretanto, os "m6dulos
de computação" não executam operaeões de E/S, e têm
acesso as membrias locais de todos os m6dulos de
computação do sistema, não existe troca de mensagem, e
o sistema funciona como se possuisee uma mem6ria
compartilhada de 4Gbytes distribuida entre os "módulos
de computaç8Xo". Logo o sistema pode tambem ser
classificado na classe de Sistemas Multiprocessadores
com Arquiteturas Fortemente Acopladas ( secão
11.2.1.3.1).
111.1.4 - AVALIAÇRO DO "GARGALO" DO SISTEMA ACP
Iremos identificar o caminho percorrido por um
dado ao ser transferido de uma fita para um processador
do Sistema ACP de acordo com a figura 3.13, e iremos
determinar a taxa de transferência a cada etapa do
caminho percorrido. Definiremos "gargalo" como sendo a
etapa do caminho que possui a menor taxa de
transferência e que consequentemente limita a taxa de
transferência de dados do sistema.
1. Leitora de fitas:
O uVAX I1 do CBPP possui um leitora de fitas TS05
capaz de ler fitas com densidade de 1Q00bpiU (bytes
por inch) e de transmitir a uma taxa de 25inM/seg
ou seja a uma taxa de 40kbytes/segundoC317 e um
disco rigido de 160Mbytes com uma taxa de
transferência de 625Kbytes/seg 6327.
2. DRV11-NA:
A taxa de transferência do mbdulo de "DMA" do
uVAXII, o DRV11-MA & de 500kbyteslseg no modo
single cycle e de 800Kbytes/seg no modo burst cycle
6333.
3. BBC:
O mbdulo Controlador de Baramento Branch , o BBC
t223, converte os dados vindos do DMA para o padrão
Branch na mesma taxa que o DMA
hrramento "Brmch":
O barramerito Branch tem capacidade de transferir a
uma taxa de ZBPfbyterslseg f 3 4 3 ,
BVI :
mbàulo de I n t e r f a c e entre o barramento Branch e o
barramento W E E153. O BVI, 6 capaz de tran~ferir
dsdos na mesma t axa em que o Barramento "Branch".
CW :
Um m6dulo con t r s l ador de b a r r m e n t o W, o W
E 2 1 3 , e capaz de dar a posse do barramento em 35ns,
para o mbdulo BVI e para o mbdulo de procêsstknento
l o c a l i z a d o no primeiro s l o t , e pode demorar a t e
1,2us para dar a posse para o processador
l s cah izado no viy6simo slot.
Barraniento "W":
O r e l 6 g i o padrtio das linhas p a r a l e l a s do b a r r a ~ e n t s
VKE e de 1 6 b 2 , logo o barramerito 6 czpaz de
t r a n s m i t i r d \arna t axa de 64Mhytes/seg CE63,
Processador:
O tempo de acesso para a Leitura de m a mewbria 6
de 24011s (4OHbytes/uegundo) e o de acesso
para uma escrita de 1ZOns (8Mbytes/segmdo),
O programa de simulãc%o trabalhou com transferencias
de dados entre s disco rigido e o Sistema ACP para
eliminar o "gargalo" causado p e l a leitora de fitas.
O "gargalo" do sistema ser$ causado pelo disco do
uVAX que limita o sistema a uma taxa de transferência
de 625 Kbytes/seg.
111.2 - ACPSYS
O Sistema ACP 6 um sistema multiprocessador
escravo. Ele foi configurado para a implementação de
um microcomputador uVaxII ou um minicomputador VAX
11/780 como computador hospedeiro.
O computador hospedeiro tem a função de gerenciar
todo o acesso de "entrada/saidaM dos elementos de
processamento do Sistema ACP , assim como outras
necessidades do sistema.
Cabe a cada elemento de processamento do Sistema
ACP apenas a tarefa de processar.
O pacote de software desenvolvido para o
funcionamento do Sistema ACP se chama ACPSYS . Este
software sb pode ser istalado em um sistema operacional
de ambiente VMS .
Dentro deste pacote consta o sistema operacional
que 6 carregado nos processadores do Sistema ACP , o
LUNI , ou LITTEE UNIX C247. O computador hospedeiro
carrega o LUNI e o programa a ser executado pelo
processador na
fase de inicialização do sistema. O LUNI coloca o
processador no estado READY esperando o carregamento do
evento a ser processado, ver figura 3.9. Ao receber o
evento o processador passa para o estado RUNNING e
executa o programa que foi carregado pelo hospedeiro.
Ao tkrmino da execução do programa o processador passa
para o estado DONE e fica esperando a coleta dos
resultados para só então passar para o estado READY,
reinicializando o ciclo. Caso ocorra uma exceção, o
LUNI coloca o processador no estado DEAD esperando uma
reinicializa~ão pelo hospedeiro.
O processo que é executado no hospedeiro inicializa
um segundo processo, o RMIMOM, cuja funçgo & a de
monitorar o estado dos processadores e de executar
todos os pedidos de entrada e de saida entre o processo
executável do hospedeiro e os processos executados nos
processadores do Sistema ACP.
Para a utilização do ACPSYS, o usuário deve gerar um
arquivo, o User Parameter File(UPF)C113, contendo as
informações sobre o programa que deve ser processado no
computador hospedeiro, sobre o programa a ser
processado nos elementos de processamento do Sistema
ACP, sobre o ntamero de processadores que deseja
utilizar , e outras informações, ver figura 3.10. A
documentação pode ser encontrada no manual ACP User's
Guide for UtilitiesC113. Foi desenvolvido um programa
PROGRAMAS FONTES DO
COMPUTADOR HOSPEDEIRO
PROGRAMAS FONTES DO
PROGRAMA DOS PROCESSADORES DO SISTEMA ACP
ARQUIVO DE PARAMETROS DO
PARAMETER F I L E
FIG.3.10- CONVERSAO DE UM PROGRAMA PARA SER EXECUTADO NO SISTEMA ACP
utilitkirio, o MULTICOMP, que ao ser executado utiliza
os dados fornecidos no arquivo UPP para fazer a
compilação dos programas FORTRAN em seus respectivos
processadores e para criar os dados necessários para a
execução do processo RMIMOM.
O usuário fornece o nhmero de processadores que serão
utilizados e quais os processos que serão processados
porém não cabe ao usu8rio a decisão sobre qual o
processador que receber8 o evento, esta função cabe ao
processo RMIMOM. Existem subrotinas de transmissão que
possibilitam ao usuArio especificar os processadores a
serem acessados, caso desejado C121.
O ACPSYS contém uma skrie de subrotinas FORTRANC123,
fdceis de serem implementadas, e que foram
desenvolvidas para realizar toda a transmissão de
eventos entre o computador hospedeiro e os
processadores do sistema ACP.
O software desenvolvido para o Sistema ACP comporta
toda a classe de problemas que requer pouca ou nenhuma
intercomunicação entre processadores. Nesta classe
podemos incluir muitas aplicaçdes de cAlculo em redes,
cAlculo de integrais de muitas dimensdes reconstrução
da trajetória de partículas, bem como para problemas
fora da física tais como c8lculo de matrizes,
processamento de sinais, etc C23.
Na figura 3.11 B apresentado um fluxograma de um
programa do tipo orientado para eventos onde o programa
B dividido em dois programas. O primeiro programa é
aquele onde é realizada toda a transmissão e coleta dos
eventos para os processadores bem como cálculos
estatisticos, etc. O segundo programa & aquele a ser
carregado nos processadores onde ser8 realizado o
c8lculo propriamente dito. Existem três niveis de
subrotinas de transmissão entre o computador hospedeiro
e o Sistema ACP. O grau de flexibilidade e de
complexidade das subrotinas de transmissão aumenta a
cada nivel. A documentação pode ser encontrada no
manual Software User's GuideC123.
Foi desenvolvido tambBm um simulador do Sistema ACP,
o qual pode ser implementado em máquinas de ambiente do
sistema operacional VMS.
111.3 - SISTEMA EM TEMPO REAL
Existem tambbm várias possibilidades de se
implementar o Sistema ACP em sistemas de tempo real.
FLUXOGRAMA DE UM PROGRAMADO
TIPO EVENTO ORIENTADO ROTINAS DE TRANSMISSÁO
INICIAR AS CONSTANTES BROADCAST
- - -
-o LEITURA DE UM EVENTO SENDEVENT
PROCESSAMENTODOEVENTONO NIJMERODEPROCESSAMENTO PROGRAMA NO PROCESSADOR ATUALIZ ANDO AS ESTATISTICAS (99 DO TEMPO T O T A L DE E OS HISTOGRAMAS PROCESSAMENTO DO PROGRAMA)
ESCREVER O RESULTADO NA FITA GETEVENT
DETERMINAR SE CHEGOU AO FIM ALLDONE
GERAR AS ESTAT~STICAS OS HISTOGRAMAS E SUMNODE
TERMINAR O PROGRAMA
Um exemplo de implementação & apresentado na
figura 3.12, onde um uVaxII exerce funç6es de
gerenciador de recursos. O gerenciador de recursos
comunica ao sistema de aquisiçgo de dados o endereço do
prbximo elemento de processamento livre.
Em um sistema mais complexo a decisão é
determinada pelo sistema de aquisição de dados, e o
uVaxII & dedicado A monitoração do processamento dos
eventos e dos possiveis erros que possam vir a ocorrer
no sistemaC21.
A fig.9 apresenta o sistema de aquisição de dados
da experiência E-769 C327 na qual o CBPF & uma das
instituiçaes colaboradorasC67. Dois mbdulos foram
desenvolvidos para a implementação deste sistema: um
contrslador de bastidor CAMAC , o SMART CRATE CONTROLER
(SCC) e o Read Buffer (RBUFF) . O SCC realiza a coleta
dos eventos que chegam no bastidor CAMAC segundo um
programa pre-carregado pelo minicomputador VAX 11/780 . O SCC ir8 transmitir os eventos para o RBUFF via uma
interface paralela. Os RBUFFS são mbdulos de padrão
VME e apresentam caracteristicas de buffer de leitura.
Os eventos sSo coletados dos RBUFFS pelos elementos de
processamento. Apbs o processamento,os eventos sgo
enviados para gravação em fita utilizando para isto um
mbdulo padrgo VME controlador de fita, o CIPRICO . O
gerenciamento da coleta dos eventos e o processamento
A A A A C .V C C C P P P P 0 . 0 c . . M D E E
E
O H H R E S S
FIG. 3.12 - DIAGRAMA DO SISTEMA DE ,AQUISIÇÃO DE DADOS DA E - 7 6 9 (OS EVENTOS SÁOCOLETADOS PELOSMODULOSSCC DOS BASTIDORES CAMAC,ENVI- ADOS PARA OS MODULOS RBUF DOS BASTIDORES VME,OS PROCESSA - DORES ACP COLETAM OS EVENTOS,"FILTRAM", "EMPACOTAM" E ARMA - ZENAM E M FITA MAGNETICA)
7 3
sao realizados par um dos processadores do Sistema ACP.
A monitoração do sistema & realizada pelo VAX 11/780
obs :
Tal sistema coletou uma media de 400 eventos por
segundo de aproximadamente 4kbytes cada, produzindo em
8 meses de coleta de dados mais de 10.000 fitas. A
analise dos eventos desta experiencia necessitaria de
12 anos de processamento no sistema atual do FERMILAB
COMPUTER CENTER , mas ser8 realizada em aproximadamente
12 meses em um Sistema ACP OFFLINE de aproximadamente
100 processadores.
CAPITULO LV
AVAL IAÇXO EXPERIMENTAL DO DESEMPENHO DO
MULTIPROCESSADOR ACP
Para se fazer a avaliação do desempenho iremos
desenvolver programas para a simulação dos problemas a
serem estudados, isto , de problemas "orientado para
eventos" (seçãoIV.1) e de problemas com comunicação entre
os processadores(seção IV.3). Baseado nos resultados
obtidos na seçgo IV.l iremos desenvolver um modelo para o
Sistema ACP (seç2ioIV.2).
O estudo do desempenho ser8 baseado nos resultados
obtidos na avaliação da DEGRADAÇBO e na avaliaeão da
ACELERAÇKO do Sistema ACP (secão IV.1)
Sabemos que em um sistema paralelo ideal uma tarefa sendo
processada em (P) processadores dever8 ser (P) vezes mais
r8pida que no mesmo sistema com apenas processador.
A diferença entre o tempo de processamento real e o tempo
de processamento ideal que o sistema paralelo é capaz de
prover ser8 chamada de DEGRADAÇBO introduzida pelo sistema
paralelo.
A relação entre o tempo de processamento em um Sistema
ACP com 1 processador e o tempo de processamento em um
sistema com (P) processadores ser8 chamada de ACELERAÇRO do
sistema com ( P ) processadores.
IV.l - AVALIAÇXO EXPERIMFJITAL DO DESEMPENHO DO
MULTIPROCESSADOR ACP EM PROBLEMAS DO TIPO "ORIENTADO PARA
m o s "
Ma figura 3.11 8 apresentado um fluxograma tipico de um
problema "orientado para eventos". Neste tipo de problema
aproximadamente 99% do tempo de cpu 8 gasto no
processamento do evento e aproximadamente 1% & gasto em
transfêrencia de dados C253.
Um algoritmo tipico para um problema do tipo "orientado
para eventos " é descrito a seguir:
Ler um evento gravado em fita para ser processado.
Processar o evento.
Colocar o resultado em um histograma.
Verificar o término do processamento de todos os
eventos, para então realizar os c8lculos estatisticos,
etc.
Voltar ao passo 1 para a leitura do prbximo evento,
caso ngo tenha terminado o processamento de todos as
eventos.
Como o processamento de cada evento independente do
pracessamento de eventos anteriores, este tipo de problema
é ideal para uma arquitetura como a do ACP, onde os
processadores executam paralelamente o processamento dos
eventos ao mesmo tempo em que o uVAXII realiza a
transmissgo dos eventos, de maneira que um Sistema ACP
ideal com (P) processadores ser8 equivalente a ( P ) sistemas
uniprocessadores (figura 4.2).
A presença de um computador hospedeiro faz com que o
sistema multiprocessadar seja bastante simples de ser
implementado, mas por outro lado, o fato de o hospedeiro
ser o gerenciador e o executor das operações de EIS do
sistema faz com que o sistema multiprocessador seja
dependente do desempenho do hospedeiro e de sua capacidade
de implementar as operações de E/S.
Dois casos extremos podem ocorrer:
Ao aumentar muito as operações de EIS o uVAXII passará
a não mais ser capaz de atender os pedidos na taxa
desejada.
Ao aumentar muito as operações de processamento dos
processadores, a taxa com que os processadores irao
solicitar as operações de EIS ir8 diminuir. Logo o
uVAXII ficar8 ocioso podendo o sistema desta maneira
receber mais processadores no sistema.
Podemos entao observar que o desempenho do sistema B
diretamente dependente da relação entre a taxa de
processamento dos processadores e da taxa de comunicação
entre os processadores do Sistema ACP e o uVAXII.
I EVENTO PROC. HISTOGRAMA
2 K B Y T E S
N PROCESSADORES RESULTADO
N VEZES MAIS RÁPIDO
FIG. 4.2 - SISTEMA ACP IDEAL DE N PROCESSADORES EQUIVALE A N SISTEMAS UNIPROCESSADORES
IV.l.l - DESENVOLVIMENTO DO PROGRAMA DE SIMULAÇXO
Iremos desenvolver um programa de simulação do
processamento de eventos de acordo com o algoritmo de um
problema do tipo "orientado para eventos" descrito na seção
anterior.
Como visto na seção anterior, os parametros que alteram
o tempo total de processamento , ou melhor o desempenho do
Sistema ACP em um problema do tipo "orientado para eventos"
, são:
- (P1) o tamanho do evento sendo transmitido
- (P2) o ntmero de processadores do sistema.
- (P3) o tempo de processamento do evento
- (P4) tamanho do resultado coletado do processador
Iremos nos basear nestes parametros para O
desenvolvimento de um programa de simulação. Como visto no
capítulo 111, o Sistema ACP 6 um sistema escravo de um
computador hospedeiro. Cabe ao computador hospedeiro
realizar todas as operaçaes de E/S do Sistema ACP , e cabe
aos computadores do Sistema ACP a tarefa de "processar".
De maneira que para a implementação do programa de
simula~2lo ser8 necessArio gerar um programa de simulação de
transmissao de eventos para ser executado pelo computador
hospedeiro, e um programa de simulação de processamento de
eventos para ser executado pelos processadores do Sistema
ACP .
O Sistema ACP do CBPF , possui no momento apenas 21
processadores. Decidimos realizar a simulaç2is para
sistemas ACP de um a 16 processadores (1 < F2 < 16 1,
devido ao fato de 16 ser um namero bastante utilizado em
sistemas multiprocessadores em particular em sistema de
arquitetura hipercabica (seção 1 . 3 o que possibitarA
futuras comparações.
Um tipico programa do tipo "evento orientado" analisa
dezenas de milhões de eventos indendentes entre si, o
programa 6 portando executado dezenas de milhões de vezes.
Iremos considerar que 100 eventos ser8 um n~mero
suficientemente grande para simularmos esta an8lise em um
Sistema ACP com um ntamero mAximo de 16 processadores.
A simulação será. feita para eventos com tamanhos médios
(P1) entre 5000 palavras e 50000 palavras que são tamanho
de eventos tipicos de tais problemas e (P4) entre 400 e
4000 palavras que são tambkm tamanhos tipicos de resultados
deste problemas.
Um tempo de processamento tipico de um evento é de 20
segundos, para realizarmos o programa de simulação para 100
eventos de 5000 a 50000 palavras necessitariarnos de
aproximadamente 20000 segundos de processamento de
processadores ACP.
Como o objetivo da tese est8 em desenvolver um método
experimental da avaliação do desempenho do Sistema ACP
aplicável a quaisquer conjuntos de parametros
(Pl,PZ,P3,P4) decidimos trabalhar com um tempo de
processamento mkdio de um evento (P3) de 3 segundos que foi
pequeno o suficiente para podermos avaliar o desempenho
para o processamento de um problema do tipo evento
orientado sem termos que alocar o Sistema ACP por muito
tempo.
E importante ressaltar que os resultados a serem obtidos
para a análise com um tempo de processamento menor nso
sergo proporcionais aos resultados obtidos para um tempo de
processamento tipico (seção IV.21, de maneira que para
obtermos o comportamento do sistema para problemas com
outros parametros, como por exemplo de (P3)=20 segundos
será necessário aplicar o m6todo a ser apresentado.
IV.1.1.1 - ALGORITMO DO PROGRAMA EXECUTADO PELO
COMPUTADOR HOSPEDEIRO
A finalidade deste programa (programa EV.FOR/ APENDICE
C)& a de implementar as funçaes do computador hospedeiro,
isto B a de realizar todas as operaçt5es de EIS do Sistema
ACP. Em primeiro lugar, este programa irá executar o
carregamento do sistema operacional dos processadores (o
LUNI) e do programa de simulação do processamento dos
eventos a ser executado pelos processadores no Sistema ACP,
a seguir o programa executará um ciclo de instruções de
envio e de coleta dos eventos para o Sistema ACP até que
todos os eventos tenham sido processados.
ALGORITMO
1. Carregar o LUNI e o programa executado pelos
processadores, e inicializar o programa RMIMOM.
2. Dar "Broadcast" da variAvel (P3) em todos os
processadores do Sistema ACP.
3. Inicializar a contagem do tempo total de processamento
dos eventos a serem processados
4. Verificar se todos os eventos j foram processados.
Caso negativo continue, caso positivo passe para o
item(9).
5. Ler um evento em disco.
6. Carregar um evento em um processador do Sistema ACP que
esteja pronto para receber um eventoristo 8 , que não
esteja processando.
7. Verificar a disponibilidade de um resultado a ser
coletado, caso positivo, armazenar o resultado em fita.
8. Voltar ao passo 4.
9. Avaliação do tempo total de processamento.
10. Geração de histogramas estatisticos com os resultados
coletados.
IV.1.1.2 - ALGORITMO DO PROGRAMA EXECUTADO PELOS
PROCESSADORES DO SISTEMA ACP
A finalidade deste programa (programa
NODEEV.FOR/APENDICE C ) 8 a de simular o processamento de
um evento , Para a simulação do processamento de um evento
& executada uma instruçgo de "retardo".
A determinação da duração do retardo é feita utilizando o
valor da vari8vel (P3) fornecida pelo computador
hospedeiro. O computador hospedeiro utiliza uma funeão
randbmica para gerar uma varidvel entre os valores O e
IP3) para cada evento a ser enviado. De maneira que o
processamento de cada um dos 100 eventos ter8 um tempo
mkdio de valor (P3), e estaremos simulando uma sítuaçgo
mais prbxima da realidade.
O programa de simulaçgo & carregado pelo computador
hospedeiro em conjunto com o LUNI . OLUNI espera0
recebimento do evento para dar inicio à execuçzo do
programa, apbs o término da execução do programa o LUNI
avisa ao computador hospedeiro que o resultado est8 pronto
para ser coletado. Apds o evento ser coletado o LUNI volta
ao estado de espera de um evento.
ALGORITMO
1. Determinação do tempo de dura~ão da instrução de
retardo.
2. Execução da instrução de retardo
3. Fim (colocar o processador no estado DONE , a ser lido
pelo hospedeiro)
A simulação foi feita para a análise de 100 eventos
assumindo tamanhos m&dios (P1) entre 5000 palavras e 50000
palavras, tamanhos medios de (P4) entre 400 e 4000
palavras, tempo de processarnento medi0 ( P 3 ) de 3 segundos e
para Sistemas ACPs de 1 a 16 processadores (P2). Os
resultados são armazenados na TABELA 1, descrita a seguir.
TABELA 1:
Um gráfico ilustrativo desta tabela encontra-se na figura
4 . 3 . Nesta tabela são armazenados os resultados do tempo
de processamento do programa de simula~ão para tempo de
processamento mkdio de um evento ( P 3 ) de 3 segundos. As
linhas da tabela assumem os valores do nomero de
processadores no Sistema ACP (P2), assumindo valores de 1 a
16. As colunas da tabela correspondem ao tamanho do bloco
de palavras do evento sendo transmitido (P1) assumindo
valores entre 5000 palavras e 50000 palavras e tamanho do
resultado coletado (P4) assumindo valores entre 400 e 4000
palavras.
'RO
CE
SS
AD
OR
E:
O S
ISTE
MA
AC
P
(P2
TA
BE
LA
I
TA
BE
LA
DO
TE
MP
O T
OT
AL
DE
PR
OC
ES
SA
ME
NT
O D
E 1
00
EV
EN
TO
S E
M U
M S
IST
EM
A
AC
P E
M F
UN
ÇÃ
O D
AV
AR
IAÇ
,~~
~
DO
NOM
ERO
DE
PR
OC
ES
SA
DO
RE
S
DO
SIS
TE
MA
( L
INH
A )
E D
O T
AM
AN
HO
ME
DIO
DO
EV
EN
TO
(K
BY
TE
S)
SE
ND
O T
RA
NS
FER
IDO
(CO
LUN
A)O
T
EM
PO
ME
DIO
DE
PR
OC
ES
SA
ME
NT
O D
E U
M
EV
EN
TO
E 3
SE
G (
P3
) P
4=
10
°/0
D
E (
PI)
Y = NÚMERO DE PROCESSADORES DO SISTEMA APC
Z = TEMPO TOTAL DE PROCESSAMENTO PARA 100 EVENTOS
IV.1.2 - ESTUDO DA DEGRADACXO DO SISTEMA ACP
Iremos definir tempo de processamento real de 100
eventos, TABELAl(Fl,P2,P3,P41, como sendo o tempo de
processamento gerado pelo programa de simulaçgo e
armazenado na TABELA 1, e tempo de processamento ideal de
100 eventos, Tl00ideal(Pl,P2,P3,P4), como sendo o tempo que
se espera obter do Sistema ACP caso ele se comportasse como
um sistema multiprocessador ideal.
De posse dos "tempos totais de processamento"
correspondentes a cada um dos paritmetros: tempo de
processamento mkdào (P3), de tamanho mkdio de um evento
(Pl), do tamanho m&dio do resultado coletado (P41, e do
nhmero de processadores do Sistema ACP (P21, faremos um
estudo de quanto o desempenho do Sistema ACP real se
distancia do desempenho do Sistema ACP ideal A medida em
que se alteram estes parâmetros, ou seja da DEGRADAÇXO do
Sistema ACP segundo cada parametro.
Para calcularmos a diferença entre o tempo de
processamento real e o tempo de processamento ideal
necessitamos determinar o tempo de processamento ideal. O
programa de simulação simula o processamento de 100
eventos, logo necessitaremos determinar o tempo de
processamento ideal de 100 eventos. O programa de
simula&fo fixa o valor do tempo de processamento mkdio de
um evento (P3) em 3 segundos.
Iremos chamar TlOOideal(Pl,PZ,P3,P4) o tempo médio para
um sistema multiprocessador ideal de (P2) processadores
processarem 100 eventos de tamanho (Pl), de tempo médio de
de processamento (P3) = 3 segundos, e de resultado coletado
com tamanho médio (P4), isto 8:
onde :
P1 : Tamanho mbdio de um evento, ou seja nhmero de
palavras médio de um evento
P2: Ndmero de processadores do Sistema ACP
P3: Tempo mkdio de processamento de cada evento
utilizado pelos processadores para simularem um tempo
medi0 de processamento de cada evento. Fixado em 3
segundos.
TC(Pl+P4) : Baseados em testes que verificaram que o
tempo de transmisszXo de um evento de tamanho P1 é
aproximadamente igual ao tempo de coleta de um
resultado de tamanho P1 (comparar tabela 4 com tabela
51, iremos considerar que o tempo de transmissEio de um
evento de tamanho P1 é igual ao tempo de coleta de um
resultado de tamanho P1. Logo TC(Pl+P4) ser&
aproximadamente igual ao tempo de transmissao m8dio de
um evento com um tamanho de P1 palavras somado ao tempo
de coleta do seu resultado, de tamanho P4 (seção
IV.1.2.2)
5. Tlideal(Plf1,P3,P4): Tempo mkdio ideal para um sistema
uniprocessador processar um evento de tamanho P1
palavras, tempo de processamento P3 segundos e tamanho
do resultado coletado P4 palavras. isto 6:
6. TlOOideal(Pl,l,P3,P4): Tempo médio para um sistema
uniprocessador processar 100 eventos de tamanho (Pl),
de tamanho do resultado (P4) palavras e de tempo de
processamneto (P3) segundos.
7. TABELA l(Pl,P2,B3,P4): Resultados obtidos da TABELA 1.
Estes resultados correspondem ao tempo total de
processamento de 100 eventos de tamanho mkdio (P1)
palavras, de tempo de processamento mkdio (P3)
segundos, de tamanho do resultado coletado medi0 (P4)
palavras e de processadores do sistema (PZ), gerado
pelo programa de simulação da seçEío IV.l.
A DEGRADAÇXO do sistema será entgo a diferença entre o
tempo de processamento real, ou seja TABELA 1(PlfP2,P3,P4),
e o tempo de processamento ideal, ou seja
TlOOideal(Pl,P2,P3,P4).
Os resultados destas diferenças são armazenados na TABELA
3 descrita a seguir.
TABELA 3
Nesta tabela são armazenados os valores dos resultados de
DEGRADAÇXO do Sistema ACP. As colunas da tabela
correspondem aos valores do n6mero de processadores no
Sistema ACP (P2), variando de 1 a 10. A s linhas da tabela
correspondem ao tamanho mbdio do bloco de palavras do
evento sendo transmitido para cada processador(Pl),
variando entre 5000 palavras e 50000 palavras e ao tamanho
mBdio do evento sendo eoletado de cada porcessador (P41,
variando entre 400 e 4000 palavras. O tempo de
processamento mBdio de cada evento (P3) b de 3 segundos.
Um gr8fico ilustrativo desta tabela encontra-se na figura
4.4.
ANALISE DOS RESULTADOS
Observamos da figura 4.4, ilustrativa da TABELA 3 que B a
tabela de DEGRADAÇXO que ao fixarmos um dos parametros e
variarmos o segundo obteremos resultados cuja análise B
válida para quaisquer outros parametros da tabela:
1)Ao fixarmos (P1) em 5000 palavras, (P4) em 400 palavras
e variarmos (P2) entre 1 e 16 processadores:
2OC
ES
SA
OO
RE
I O
SIS
TE
MA
AC
P
TA
BE
LA
3
TA
BE
LA
DO
S R
ES
ULT
AD
OS
DA
AV
ALI
AÇ
ÃO
"D
EG
RA
DA
ÇÃ
O"
DO
ÇIS
TE
MA
AC
P P
AR
A O
PR
OC
ES
SA
ME
NT
O D
E 1
00 E
VE
NT
OS
EM
FU
NÇ
ÃO
DO
NÚ
ME
RO
DE
P
RO
CE
SS
AD
OR
ES
DO
SIS
TE
MA
(L
INH
AS
) E
DO
TA
MA
NH
O M
ED
I0 D
E U
M E
VE
NT
O K P
AL
AV
RA
S (
CO
LU
NA
)
x = TAMANHO MEDIO DE UM EVENTO SENDO TRANSMITIDO
Y = NÚMERO DE PROCESSADORES DO SISTEMA ACP
Z = DEGRADAÇÃO PARA 100 EVENTOS
FIG. 4.4 - GRAFICO REPRESENTANTE DA TABELA 3
1.1)Para um sistema com apenas um processador (P2=1), a
DEGRADAÇXO é grande:
Para a execução de um programa no Sistema ACP é
gerado um processo, o RMIMOM, suja finalidade principal
6 a de realizar pooling nos registros de estados dos
processadores para gerar uma tabela de estados.
O programa executado pelo computador hospedeiro cuja
finalidade B a de realizar as operações de E/S do
Sistema ACP solicita os processadores ao processo
RMIMOM e transfere os eventos para BUPFERs alocados
pelo RMIMOM para que este realize a transferência dos
eventos.
O tempo gasto para a comunicação entre o processo
executado pelo processador hospedeiro e o processo
RMIMOM pode ser considerado independente do nbmero de
processadores do sistema o que torna um Sistema ACP com
apenas 1 processador bastante ineficaz como podemos ver
pela ffgura 4.4.
1.2) Ao aumentarmos o n6mero de processadores (P21,a
DEGRADAÇRO diminui. O tempo gasto com a comunicaçEio do
processo RMIMOM passa a ser proporcionalmente menor que
o tempo total de processamento.
1.3) A DEGRADAÇAO se estabiliza por volta de 3
processadores. Neste caso o tempo gasto com a
cominicaçao do processo RMIMOM passa a ser desprezivel
em comparação com o tempo total de processamento e os
sistemas de 3 e 7 processadores irão apresentar
proporcionalmente a mesma DEGRADAÇXO.
1.4) A partir de 7 processadores a DEGRADACXO volta a
aumentar. Isto se deve ao fato de o computador ngo
estar mais sendo capaz de atender todos os pedidos de
E/S no tempo desejado, isto gera tempo de espera no
sistema e consequentemente um aumento na DEGRADAÇXO.
2) Ao fixarmos (P2) em 8 processadores e variarmos (P1)
de 5000 a 50000 palavras , e (P4) de 400 a 4000 palavras:
2.1) A DEGRADAÇXO se manter& constante até (P1)=15000 e
(P4)=1200. Podemos concluir que para eventos menores
que 15000 palavras o uVAXII gasta o mesmo tempo de
carregamento. Ou melhor, os procesãadores demoram mais
tempo processando o evento do que o uVAXII carregando
os eventos, de maneira que ele fica parte do seu tempo
ocioso.
2.2) A medida em que aumentamos o tamanho do evento
sendo transmitido (P1) e do resultado sendo coletado
(P4), a DEGRADAÇXO aumenta. Isto se deve ao fato de
que medida em que se aumenta o tempo de comunicação de
cada evento transmitido o uVAXII começa a não mais ser
capaz de atender os processadores no tempo desejado.
2.3) Podemos observar também que o efeito se torna
desprezivel para sistemas com poucos processadores
(P2<3), porque nesta situaçgo os processadores estão
solicitando atendimento do uVAXII abaixo da sua
capacidade.
IV.1.2.2 - Determinação do tempo de transmissão de blocos
de dados entre o uVAXII e um processador
Determinação de Tc(Pl+P4)
Para a determinaçgo do tempo ideal de processamento
tivemos que avaliar o tempo mkdio de transmissão de um
evento da computador hospedeiro para o Sistema ACP , ou
seja TC(Pl+P4).
Desenvolvemos um programa de simulação (PROGRAMA
TC.POR/APENDICE D) , que avalia o tempo total de
processamento da transferência de um grande nbmero de
eventos, ou seja de 100 eventos para apenas um processador.
O processador simula um processamento de tempo zero para o
evento recebido (PROGRAMA NODETC.FOR/AFE'INDICE D). O valor
obtido do tempo total de transmiss80 dos 100 eventos 6
então dividido por 100, fornecendo assim o valor de TC(P1)
e armazenado na tabela 4.
Implementamos o mesmo programa de simulaq?Xo, para avaliar
a tempo total de processamento da coleta de um evento,
TC(P41, e armazenamos o resultado na TABELA 5.
Verificamos que os resultados das tabelas 4 e 5 são
aproximadamente iguais, logo temos que:
T A B E L A 4 I T A B E L A 5
T A B E L A 4 - PARÂMETRO(PI) VARIANDO DE 5 0 0 0 A 70000 PALAVRAS
T A B E L A 5 - PARAMETRO (P4) VARIANDO DE 400 Â 5 6 0 0 PALAVRAS
T A B E L A 6 - SOMATÓRIO DO PARÂMETRO(PI) COM O PARÂMETRO(P~) (VARIAÇÃO DE 5 4 0 0 PALAVRAS 'A 7 5 6 0 0 PALAVRAS)
T A B E L A 6
Implementamos o programa de simulacão para avaliar o tempo
total de processamento da transferência de 100 eventos de
tamanho (P1) e da coleta de 100 resultados de tamanho (P4)
para apenas um processador. O parametro P1 assume
valores de 5000 a 50000 palavras e o parametro P4 valores
de 400 a 4000 palavras. O valor obtido do tempo total de
transmissão fornece o valor de TC(Pl+P4) e e armazenado na
tabela 6.
IV.1.3 - ESTUDO DA "ACELERAÇXO" DO SISTEMA ACP
Podemos realizar o estudo do desempenho do Sistema ACP por
um segundo mktodo. Neste segundo metodo iremos determinar
quantas vezes o Sistema ACP de (P2) processadores 8 mais
rápido que um Sistema ACP com apenas 1 processador ao
alterarmos o parametro de tamanho mBdio de um evento
(Pl), o parametro do tamanho medi0 do resultado coletado
(P4) e fixarmos o parametro de tempo m8dio de
processamento de um evento (P3).
Definimos anteriormente que a rela~so entre o tempo de
processamento em um Sistema ACP com 1 processador e o tempo
de processamento em um sistema com (P2) processadores B
chamada de ACELERAÇRO do sistema com (P2) processadores.
Utilizaremos os valores fornecidos pela TABELA 1,
dividiremos o tempo total de processamento em um sistema de
P2 processadores, TABELAl(Pl,PZ,P3,P4), pelo tempo total de
processamento no sistema de um processador,
97
TABELAl(Pl,l,P3,P4), para cada um dos valores assumidos
pelo nomero de processadores do Sistema ACP (P21, pelo
tamanho m8dio de um evento(Pl), pelo tamanho m8dio do
resultado coletado, e armazenaremos o resultado na TABELA
2.
TABELA 2
Um gr8fico ilustrativo desta tabela encontra-se na figura
4.5. Nesta tabela s3o armazenados os valores dos
resultados de ACELERAÇAO do Sistema ACP . Os valores dos
parâmetros (Pl), (PZ), (P3) e (P4) sgo os mesmos
assumidas para a geraçso da TABELA 1 pelas mesmas razões
apresentadas na seção IV.l.l. As colunas da tabela
correspondem aos valores do nomero de processadores no
Sistema ACP (PZ), variando de 1 a 16. As linhas da tabela
correspondem ao tamanho m8dio da bloco de palavras do
evento sendo transmitido para cada processador (Pl),
variando entre 5000 palavras e 50000 palavras, e do tamanho
m8dio do resultado sendo coletado (P4), variando de 400 a
4000 palavras e o tempo de processamento m8dio de um evento
(P3) 8 de 3 segundos.
IV.1.3.1 - ANALISE DOS RESULTADOS
Observamos da figura 4.5, ilustrativa da TABELA 2 , tabela
dos valores da ACELERAÇAO do Sistema ACP para o
processamento de 100 eventos, que ao fixarmos um dos
parâmetros e variarmos o segundo obteremos resultados
cuja anhlise 8 v8lida para quaisquer outros parametros da
tabela :
RO
CE
SS
AD
OR
EI
O S
IST
EM
A A
CF
TA
BE
LA
2
TA
BE
LA
DO
S R
ES
ULT
AD
OS
DA
AV
ALI
AÇ
ÃO
DA
,"AC
ELER
AÇAO
D
O S
IST
EM
A A
CP
PA
RA
O P
RO
CE
SS
AM
EN
TO
DE
100
EV
EN
TO
S E
M F
UN
ÇÁ
O D
O N
ÚM
ER
O D
E
PR
OC
ES
SA
DO
RE
S (
LIN
HA
S)
E D
O T
AM
AN
HO
ME
DI0
DE
UM
EV
EN
TO
SE
ND
O T
RA
NS
MIT
IDO
EM
K P
ALA
VR
AS
(C
OLU
NA
)
z
/
Y
x = TAMANHO MÉDIO DE UM EVENTO EM K PALAVRAS
Y = NÚMERO DE PROCESSADORES DO SISTEMA ACP
Z = ACELERAÇ%O DO SISTEMA ACP PARA 100 EVENTOS
FIG. 4.5 - GRÁFICO REPRESENTANTE DA TABELA 2
1.1)Um sistema com 2 processadores (P2=2) 6
aproximadamente duas vezes mais rApido que um
sistema com 1 processador (P2=1), ou seja possui
ACELERACXO de 1.9.
1.2) Um sistema com 3 processadores (P2=3) & tamb6m
aproximadamente igual a 3 vezes mais rapido que
um sistema com 1 processador (P2=1), ACELERAÇKO de
2.8. Esta relação se mantkm constante at6 sistemas
com 5 processadores.
1.3) A partir de 8 processadores a relação acima
começa a diminuir. Isto é, um Sistema ACP dede 8
processadores (P2=8) é 6,35 maior que um sistema
com (P2=1). Isto se deve ao fato de o computador
hospedeiro não atender os pedidos de E / S com a taxa
necess8ria para evitar que os processadores fiquem
ociosos.
1.4) A ACELERAÇPLO atinge a saturação para 9
processadores (P2=9). Não adianta aumentarmos o
nhmero de processadores. O uVAXII atingiu o seu
limite na capacidade de atender as solicitaçt5es de
E/S do sistema.
101
2. Ao fixarmos (P2) em 8 e variarmos (P1) de 5000 a 50000
palavras e (P4) de 400 a 4000 palavras:
2.110 valor da ACELERAÇXO se manterd constante ate
o ponto em que P1 for igual a 15000 palavras
Podemos concluir que para eventos menores que 15000
palavras o uVAXII gasta o mesmo tempo de
carregamento. Ou melhor, os processadores demoram
mais tempo processando o evento do que o uVAXII
carregando os eventos, de maneira que ele fica
parte do seu tempo ocioso.
2.2) A medida em que aumentamos o tamanho do evento
sendo transmitido (P1 > 20000) a ACELERAÇXO
diminui. Isto se deve ao fato de que a medida em
que se aumenta o tempo de comunicação de cada
evento transmitido o uVAXII começa a n3o mais ser
capaz de atender os processadores no tempo
desejado. Este efeito se torna bastante acentuado
a partir de (P1 > 40000) palavras, que deve ser o ponto em que o uVAXII atinge a saturação para este
ndmero de processadores.
2.3) Podemos observar que a medida em que se
diminui o n~mero de processadores do sistema (P2),
a queda brusca da ACELERAÇXO caracterizada como
ponto de saturação do sistema diminui, isto se deve
ao fato de o uVAXII ter menos procesãadores para
atender e consequentemente ser capaz de transferir
eventos maiores sem saturar a sua capacidade de
2.4) Podemos observar tambem que o efeito se torna
desprezivel para sistemas com poucos processadores
(P2(3), porque nesta situação os processadores
estão solicitando atendimento do uVAXII abaixo da
sua capacidade.
Ao compararmos a anellise realizada para o estuda de
DEGRADAÇRO (seção IV.1.2.1) e o estudo de ACELERAÇKO (seção
IV.1.3.1) iremos verificar, como era de se esperar, que são
inversamente proporcionais, isto B, que a medida em que
aumentamos a DEGRADAÇAO a ACELFJtAÇXO diminui e vice-versa.
IV.2 - OBTENÇÃO DE UM MODELO ANALITICO DE DESEMPENHO PARA
O SISTEMA ACP
Para podermos explicar os resultados acima temos primeiro
que entender a influencia da arquitetura do Sistema ACP
no seu desempenho.
Como descrito detalhadamente no capitulo 111, no Sistema
ACP grupos de processadores ficam ligados a um barramento
comum obedecendo a uma estrutura "árvore", onde os
barramentos que csntkm os processadores sãs ligados a um
barramento "tronco" que por sua vez são ligados a um
processador hospedeiro (figura 3.4). Toda operação de E/S
B realizada pelo computador hospedeiro, o uVAXII , cabe aos
processadores apenas a tarefa de "processar". O
hospedeiro carrega o programa de processamento do evento
nos processadores do sistema, a seguir carrega um evento em
103
cada processador para ser processado e entra em um ciclo
para verificar se tem algum processador no estado para ser
coletado o resultado ( "ready" ) . A seguir verifica se tem
algum processador no estado pronto para receber um novo
evento ( " done" ) , e a seguir volta para verificar se tem
algum processador no estado "ready" , reinicializando o
ciclo. Este ciclo se mantém ate que os resultados de todos
os eventos sejam coletados.
O sistema estará sendo utilizado 100% quando todos os
processadores estiverem sempre processando e o computador
hospedeiro estiver sempre executando as opera~aes de E/S.
Dois casos extremos podem surgir para que isto nao
aconteqa:
Tempo de processamento (P3) muito menor que tempo de
transmissão onde o tempo de transmissgo (TC) está em funqgo
do tamanho do evento sendo transmitido (P1) e do tamanho do
resultado sendo coletado (P4). Alguns processadores
terminam de processar muito antes do computador hospedeiro
ter terminado de carregar eventos nos processadores no
estado READY e coletar os resultados dos processadores no
estado DONE . Os processadores que terminam de processar
ficam disponiveis para novos eventos e ficarao ociosos at6
que o hospedeiro tenha carregado os eventos em todos os
processadores do sistema. Tal sistema está sendo
sub-utilizado pois os processadores passam parte do seu
tempo ociosos.
Tempo de processamento muito maior do que o tempo de
transmissão. O processador termina de processar muito
tempo depois que o hospedeiro tenha terminado de transmitir
os eventos para os processadores no estado READY e coletar
os resultados dos processadores no estado DONE. Neste caso
o hospedeiro ficou ocioso, logo o sistema tem a capacidade
de suportar mais prscessadores.
Podemos então deduzir que o sistema estar8 fornecendo o
seu desempenho 6timo quando o tempo de processamento de um
evento (P3) for igual ao n~mero de processadores do sistema
(P2) vezes o tempo de transmissgo de cada evento
(TC(Pl+P4)). Ou seja:
COMPROVAÇRO MODELO
Para comprovar a validade do modelo, iremos aplicar o
modelo nos resultados da tabela 3 que sãs os resultados
obtidos da an&lise DEGRADAÇRO do sistema (seção IV.1.2).
obs: podemos fazer a mesma comprovaç~o de maneira
an8loga com os resultados da tabela 2 que são os resultados
obtidos pela análise da ACELERAÇRO do sistema (seçzo
IV.l.3).
Tomaremos como primeiro exemplo o caso em que (P3) = 3
segundos, (Pl)= 5000 palavras e (P4)=400 palavras. A
tabela 3 apresenta aproximadamente o mesmo resultado a
partir de (P2)= 9 processadores, consideramos então
como sendo o nhmero de processadores em que o sistema
atinge a saturação (seção IV.1.2.1)
Isto implica que o tempo medi0 de transmissão de
um evento de tamanho medi0 de (P1)=5000 palavras
(TC(5000)), resultado de processamento de (P4)=400
palavras, e de tempo de processamento mkdio de (P3)=3
segundos no qual o sistema satura (segundo o modelo da
equação 4.1) serti TC(5k5) = 0.3 segundos.
A tabela 4 contem os resultados obtidos do
programa de avaliação do tempo de transmissão de um
evento em funçao do tamanho do evento (P1) e do tamanho
do resultado (P4), segundo esta tabela
TC(5000,400)=0,15 segundos.
Ao compararmos o resultado fornecido pelo modelo
da equação 4.1 com o resultado fornecido pela tabela 4
iremos concluir que o modelo fornece um tempo de
transmissão duas vezes maior que o tempo de transmissão
da tabela 4.
Tomemos como segundo exemplo os resultados da tabela 3
para os parâmetros: (P1)=20000 palavras, (P4)=1600
palavras e (P3)=3 segundos. Neste caso os resultados
passam a ter aproximadamente o mesmo valor a partir de
(P2)=9 processadores. Iremos então considerar como
106
parametros onde o sistema
aplicar o modelo da
TC(21k6)=Of3segundos.
Segundo o resultado
Tc(20000,1600)=0,36segundos,
atinge a saturação e
equaeão 4.1 obtendo
da tabela 4, teremos
que B um resultado
bastante prdximo do resultado fornecido pelo modelo.
Ao comparar os dois exemplos iremos verificar que o modelo
fornece o mesmo tempo de comunicação de para TC(5k5) e para
Podemos então concluir que o modelo n&Xo é
satisfatbrio, e por estar fora dos objetfvos desta tese,
deixaremos como sugestão para futuros estudos o
desenvolvimento de um novo modelo analítico de desempenho
do Sistema ACP.
OBS :
O sistema analisado B um Sistema ACP não multi-usudrio,
utilizando o "device driver" do uVAXII para o mbdulo de
interface " DMA " , o DRV11 , utilizando a interface entre
DRV11 e o Barramento Branch , o " Branch Bus Controler " e
realizando a leitura de dados em disco.
IV.3 - AVALIAÇXO EXPERIMENTAL DO MULTIPROCESSADOR ACP EM
PROBLEMAS CONTENDO COMUNICAÇKO ENTRE OS PROCESSADORES
A segunda parte deste capitulo tem como finalidade
avaliar o desempenho do Sistema ACP em aplicaçt5es onde
existe comunicaçEio entre os processadoreâ, isto é onde cada
processador processa uma série de sub-tarefas que fazem
parte de uma hnica tarefa global.
Para fazer a simulação de tais problemas, iremos dividir
uma tarefa em (N) sub-tarefas para serem distribuidas entre
(M) processadores. Iremos supor que para o processamento
de cada sub-tarefa será necessário a leitura de um bloco de
dados em um processador vizinho, o que corresponde a um
acesso ao barramento VME.
IV.3.1 - DESENVOLVIMENTO DO PROGRAMA DE SIMULAÇXO
Iremos considerar tr8s partlmetros como funda.mentais
para a determinaçso do desempenho do sistema: o tempo de
comunicação, ou tamanho do bloco de transmissão de cada
sub-tarefa (Pl), o namero de processadores do Sistema ACP
(P2) e o tempo de processamento de cada sub-tarefa (P3).
O programa de simulaçSo desenvolvido ir8 avaliar o tempo
total de proeessamento de um determinado namero de
sub-tarefas, dado o tempo de processamento (P31, o tamanho
do bloco de transmissão de cada sub-tarefa (Pl), e o nhmero
de processadores do Sistema ACP (P2).
A configuração atual do Sistema ACP do CBPF permite
apenas a comunicaç~o entre processadores pertencentes ao
mesmo barramento VME, de maneira que o estudo só pode ser
realizado com um ntxnero maximo de 18 processadores, e
devido a este mesmo motivo o sistema atual oferece maior
capacidade de comunicaç3o quando configurado com poucos
processadores. Iremos realizar o estudo em um sistema com
4 processadores (P2=4) para obter resultados mais prdximos
de um Sistema ACP atualizado.
A execução de uma sub-tarefa, corresponde a fazer com que
o processador alterne entre dois estados: acesso a uma
membria remota via o barramento VME, e procesãamento (com
acesso a memória local). Necessitamos fazer com que os
processadores alternem entre os dois estados um grande
ntarnero de vezes para que possamos avaliar como o sistema se
comporta dada relação entre estes dois estados. Iremos
considerar a execuçSo de 1.000 sub-tarefas por pracessador,
um namero grande o suficiente para determinarmos o
comportamento do sistema. Consequentemente, a tarefa a ser
processada pelos processadores irá conter 4.000 sub-tarefas
para serem processadas em um Sistema ACP de 4
processadores.
Ap6s um s8rie de testes para determinar quais os valares
dos parametros a serem adotados para o programa de
simulaçtXo decidimos variar (P1) entre os valores: (51,
(5.0051, (10.0051, (15.005) e (20.005) palavras, e (P3)
entre os valores: (0,32), (21 , (3,6), (0,52) e (6,8)
segundos por fornecerem melhores resultados para. análise.
Como visto no CAPITULO 111, para a implementação do
programa de simulação no
um programa de simulação
hospedeiro e um programa
processadores do Sistema
IV.3.1.1 - ALGORITMO
COMPUTADOR HOSPEDEIRO
Sistema ACP, será necessário gerar
a ser executado pelo computador
de simulação a ser executado pelos
ACP .
DO PROGRAMA EXECUTADO PELO
A finalidade deste programa (PROGRAMA M4,FORlAPENDICE
E) & a de implementar as fun~aes do computador hospedeiro,
isto &, a de executar as operaçaes de EIS do Sistema ACP.
Em primeiro lugar este programa irá executar o carregamento
do sistema operacional(o LUNI) e do programa de simulaçi%o
do processamento da tarefa a ser executada pelos
processadores do Sistema ACP. A seguir i determinar o
valor dos parhetros de tempo de processamento de cada
sub-tarefa (P3)e do tamanho do bloco a ser lido por cada
sub-tarefa (P1) para enviar aos processadores, inicialiaar
o processamento das sub-tarefas pelos processadores do
Sistema ACP, esperar o término do processamento dos
processadores do sistema e voltar a determinar os novos
valores dos parametros (Pl) e (P3).
Para isto iremos fixar o tempo de processamento médio de
cada sub-tarefa (P3), e variar o tamanho médio do bloco de
comunicação de cada sub-tarefa (P1) entre os valores: (51,
(2551, (505), (755) e (1055) palavras e a seguir fixar o
valor de (P1) e variar (P3) entre os valores: (0,0321,
(0,0391, (0,045), (0,052) e (0,059) segundos
ALGORITMO
1. Inicializar o programa executado pelos processadores do
Sistema ACP.
2. Carregar nos processadores do Sistema ACP o valor da
varidvel do tamanho do bloco médio de cada sub-tarefa
(P1) e da varicivel do tempo de processamento médio de
cada sub-tarefa (P3).
3. Inicializar a contagem de tempo de processamento
4. Inicializar a execução das sub-tarefas nos
processadores
5. Esperar que todos os processadores terminem de
processar.
6. Determinar o tempo total de processamento.
7. Armazenar os resultados dos tempos de processamento na
TABELA 7:
8. Gerar um novo valor para a vari8vel de tempo m8dio de
processamento (P3) e voltar para o item(1) caso
(P3(6,8segundos) ou seguir para o item(9) caso
contr8rio.
9. Gerar um novo valor para a variável de tamanho mkdio de
bloco de comunicação (P1) e retomar ao item(1) caso
(Pl(20.005 palavras) ou seguir para o item(l0) caso
contrário.
18. Fim
TABELA 7
Um grdfico representante desta tabela encontra-se na
figura 4 6 . Nesta tabela são armazenados os resultados do
programa de simulação de 4,000 sub-tarefas. As linhas
esttio em função do ntmero de palavras lidas por sub-tarefa
(Pl), assumindo os valores: (51, (255), (5051, (755) e
(1055) palavras e as colunas o tempo de processamento de
cada sub-tarefa (P3), assumindo os valores : (0,032),
(0,0391, (0,0451, (0,052) e (0,059) segundos
FIGURA 4.6 Esta é a figura dos resultados do tempo total
de processamento das 4.000 sub-tarefas em função do namero
de palavras lidas no vizinho por sub-tarefa, (P1) e do
tempo de processamento por sub-tarefa,(P3), onde:
x = (Pl)= nfimero médio de
vizinho por sub-tarefa
assume os valores: (51,
palavras
palavras lidas no processador
y=(P3)= tempo de processamento por sub-tarefa
assume os valores: (0,032), (0,039), (0,0451, (0,052)
e (0,059) segundos
I TE
MP
O D
E
I N
ÚM
ERO
MÉD
IO D
E P
AL
AV
RA
S
LID
AS
N
O P
RO
CE
SS
AD
OR
.PR
OC
ES
SA
ME
NT
O
VIZ
INH
O P
OR
S
UE
- T
AR
EF
A
1 P
OR
SU
B-T
AR
EF
A
5 2
55
5
05
7
95
1
05
0
0.0
59
6
3.
52
6
7.3
1 6
8.9
74
7 1
.88
7 6
.05
5
TA
BE
LA
7 -
TA
BE
LA
DO
S R
ES
UL
TA
DO
S D
O T
EM
PO
TO
TA
L D
E P
RO
CE
SS
AM
EN
TO
PE
UM
A T
AR
EF
A C
OM
PO
ST
A P
OR
40
00
SU
B-T
AR
EF
AS
PO
R
UM
SIS
TE
MA
AC
P D
E 4
PR
OC
ES
SA
DO
RE
S E
M F
UN
ÇÃ
O D
O N
ÚM
ER
O M
ED
IO D
E P
AL
AV
RA
S L
IDA
S N
O P
RO
CE
SS
AD
OR
VIZ
INH
O P
OR
S
UB
-TA
RE
FA
(C
OL
UN
AS
) E
DO
TE
MP
O D
E P
RO
CE
SS
AM
EN
TO
ME
DI0
PO
R S
UB
-TA
RE
FA
(L
INH
AS
)
x = NÚMERO MÉDIO DE PALAVRAS LIDAS NO PROCESSADOR VIZINHO POR SUB-TAREFA
Y = TEMPO MÉDIO DE PROCESSAMENTO DE UMA SUB-TAREFA
Z - TEMPO TOTAL DE PROCESSAMENTO DE 4 0 0 0 SUB-TAREFAS E M UM SISTEMA ACP DE 4 PROCESSADORES
FIG. 4.6 - GRÁFICO REPRESENTANTE DA TABELA 5
3. z = tempo total de processamento de 4.000 sub-tarefa
para um sistema ACP de (P2=4) processadores em funçso
de x e y.
4. Nhmero de sub-tarefas por processador = 1.000
IV.3.1.2- ALGORITMO DO PROGRAMA EXECUTADO PELOS
PROCESSADORES DO SISTEMA ACP
A finalidade deste programa (PROGRAMA NODEM4.FOR/APENDICE
E) & a de simular o processamento de uma tarefa composta
por 1.000 sub-tarefas a serem processadas em um processador
do Sistema ACP. Cada sub-tarefa possui um tempo de
processamento e um bloco de palavras para ser lido no
processador vizinho.
Para cada sub-tarefa serão gerados os valores do tempo de
processamento e do n~mero de palavras a serem lidas na
membria remota.
Os valores são gerados por uma funçào randbmica. A
funçgs gera um valor entre os limites zero e (P), onde (P)
é um dos parametros fornecido pelo computador hospedeiro.
De maneira que no final da execuego das 1000 sub-tarefas
cada processadar ter8 processado em media um
um tempo de (1000* P3) segundos e ter8 lido na memdria remota uma m&dia de
(1000 * Pl)palavras, que sgo situações mais prbximas de
problemas reais.
ALGORITMO
1. Gerar a vari8vel de tempo de processamento.
2. Gerar a vari8vel de n~mero de palavras lidas na membria
remota.
3. Gerar um "loop" de processamento com o valor da
vari8vel fornecida pelo item (1).
4. Realizar uma leitura de um bloco de dados do
processador vizinho cujo tamanho do bloco & fornecido
pelo variAvel gerada pelo item (2).
5. Voltar ao item (1) ate completar 1.000 voltas. .
6. Fim
IV.3.1.3 - ANALISE DOS RESULTADOS
Observe que cada processador ir8 processar 1.000
sub-tarefas de maneira que ao tomarmos como exemplo os
primeiros valores dos "loops" teremos cada processador
realizando uma transferência m&dia de 5.000 palavras em
320 seg, ou seja em uma taxa de transferência de 156,25
palavras por segundo, e um sistema de 4 processadores
estará realizando uma taxa de transferencia de 625
palavras por segundo.
Dentre os testes realizados com outros parametros para
(P1) e (P3), obtivemos dois casos extremos:
1)Caso em que o valor medi0 do tamanho do bloco assume o
valor 5 palavras e o valor médio do tempo de processamento
assume o valor 6,8seg. Cada processador transfere em media
0,7 palavras por segundo. E a taxa de transferência
mkdia de um sistema com 4 processadores será de de 2,9
palavras por segundo.
2)Caso em que o valor mkdio do tamanho do bloco assume o
valor 102.000 e o valor medi0 do tempo de processamento
assume o valor 0,032seg. Cada processador tranfere em
media 3.138.462 palavras por segundo, ou 12,55
Mbytes/segundo.
Para avaliarmos esses resultados precisamos conhecer
melhor a velocidade de comunicação no Sistema ACP através
do barramento VME:
A frequência do relbgio do barramento VME(SYSCLK) & de
no máximo 16Mhz para as linhas paralelas e de no máximo
32Mhz para as linhas seriais (SERCLK). Caso seja feita uma
transferência de dados a cada ciclo do relogio, ela
poderá atingir a uma taxa de ate 64Mbytes por segundo.
Os processadores do Sistema ACP foram configurados para
serem capazes de realizar a escrita de uma palavra em sua
memória local em 180ns, ou seja a uma taxa de 5M
palavras/segundo ou SOMbytes/seg. Para realizar o acesso à
memória remota localizada em um proceasador vizinho o
processador tem que passar por circuitos de arbitragem e de
interface ao barramento VME, estes circuitos geram um
acrkscimo no tempo de transmissSo. Se considerarmos o
acréscimo como sendo de mais um ciclo de relógio teremos um
tempo de acesso minimo de 240ns para a leitura e de 300ns
para a escrita, ou seja de 16Mbytes para a escrita e de
13Mbytes para a leitura na membria remota.
E importante tambkm ressaltar que para a execução de uma
instruçEío o microprocessador MC68020 necessita de vArios
ciclos de reldgio. Por exemplo, para a execu@ío uma
instruçEío (MOV D4,(Al)) ele necessita, no melhor caso, de 4
ciclos de relbgio 7 de maneira que a taxa de
transmissão deve ser menor que 16Nbytes/segundo.
Obtivemos uma taxa mAxima de lZMbyte/seg por processador
em um sistema de 4 processadores, Estes resultados szo
bastantes satisfatdrios se levarmos em consideração que a
taxa mkxima de leitura por processador é de 16Mbytes/seg se
tomarmos como referência apenas a capacidade de
transmissão com que os processadores podem transmitir no
barramento VME.
Na realidade os processadores irão transmitir a uma taxa
muito menor porque para a execução de uma leitura ou
escrita na membria de um processsador vizinho & necessário
executar varias instruç6es (tais como a chamada a subrotina
"acpsup" para que o processador entre no modo supervisor e
a subrotina "acpusr" para que o processador volte ao modo
usuário depois de efetuar o acesso a membria vizinha) e
para a execução de uma instrução de leitura ou de escrita
sEio necessários varios ciclos de relbgio.
IV.3.2 - ESTUDO DA "DEGRADAÇXO" DO SISTEMA AÇP
A diferença entre um tempo de procesaamento da TABELA 7 e
o tempo de proceãsamento ideal de uma tarefa, dados o valor
médio do tempo de processamento e o valor medi0 do tamanho
do bloco de transmissão, 6 armazenada na TABELA 8:
TABELA 8
Um gráfico representante desta tabela encontra-se na
figura4.7 Nesta tabela sâo armazenados os valores da
BEGRADAÇRO do Sistema ACP em funçtio do nhmero de palavras
lidas por sub-tarefa (linhas) e do tempo de processamento
de cada sub-tarefa (colunas), para um Sistema ACP com 4
processadores.
FIGURA 4.7
Esta a figura da diferença entre o tempo de
processamento real das 4.000 sub-tarefas e o tempo de
processamento ideal em um Sistema ACP de 4 processadores em
funçgo de (P1) e de (P3) onde :
1. x=(Pl) = ntamero medi0 de palavras lidas no processador
vizinho por sub-tarefas.
assume os valores: (51, (255), (505), (755) e (1055)
palavras
2. y=(P3) = tempo de processamento por sub-tarefas
assume os valores: (0,0321, (0,0391, (0,0455), (0,052)
e (0,059) segundos
3. z =temp(x,y)-tp-tc
ou seja, DEGRADAÇXO do Sistema ACP de 4 processadores
para processar 4.000 sub-tarefass em função de x e y.
onde :
- temp(Pl,P3)=tempo total de processamento obtido da
TABELA 7
- tp= ( P 3 ) * 1.000 (tempo de processamento mkdio ideal de 1.000
sub-tarefas)
NÚ
ME
RO
MED
IO D
E P
AL
AV
RA
S L
IDA
S N
O P
RO
CE
SS
AD
OR
V
IZIN
HO
PO
R
SU
B -
TA
RE
FA
TA
BE
L A
8 -
TA
BE
LA
D
OS
RE
SU
LT
AD
OS
DA
AV
ALI
AÇ
ÃO
D
A D
EG
RA
DA
Ç~
O DO
SIS
TE
MA
AC
P D
E 4
PR
OC
ES
SA
DO
RE
S P
AR
A P
RO
CE
SS
AR
40
00
S
UB
-TA
RE
FA
S E
M F
UNÇA
O D
O N
ÚM
ER
O D
E P
AL
AV
RA
S L
IDA
S N
O P
RO
CE
SS
AD
OR
VIZ
INH
O P
OR
SU
B-T
AR
EF
A (
CO
LU
NA
S) E
DO
T
EM
PO
ME
DI0
DE
PR
OC
ES
SA
ME
NT
O P
OR
SU
B- T
AR
EF
A
Z = "DEGRADAÇÃO" DE UM SISTEMA ACP DE 4 PROCESSADORES PARA O PROCESSAMENTO DE 4000 SUB-TAREFAS
FIG. 4.7 - GRÁFICO REPRESENTANTE DA TABELA 6
(tempo de transmissão mkdio ideal de 1.000 tarefas,
onde
0,000004 seg= Tempo mkdio de transmissão de uma
palavra (avaliado pelos programas T.FOR e
NODET.FOR/ APENDICE G)
4. Nhmero de sub-tarefas por processador = 1.000
5. Nhmero de processadores=4
OBS :
Os sulcos observados na figura são causados pelo fato de
a fator erro utilizada para o c8lculo do tempo ideal de
processamento não ser uniforme.(APENDICE E)
IV.3.2.1 - ANALISE DOS RESULTADOS
Podemos observar que:
1. Ao fixarmos o tempo de processamento e aumentarmos o
tempo de comunicação a DEGRADAÇRO aumenta.
2. Se fixarmos o tempo de comunicação e aumentarmos o
tempo de processamento a DEGRADAÇRO diminui.
Para explicarmos a causa da influência dos parametros
de tempo de processamento de cada sub-tarefa e do tamanho
bloco lido de cada sub-tarefa no resultado da DEGRADAÇBO do
Sistema ACP, temos que entender o mecanismo de comunicação
entre os processadores do sistema:
8 barramento de comunicação entre os processadores é tal
que apenas um processador pode ter acesso por vez. Desta
maneira parte do tempo de comunicaçã.~ é gasto na espera da
obtenção do barramento, e parte do tempo é gasto na
transferência do bloco. Duas situaçaes extremas podem
ocorrer para alterar o desempenho do sistema:
Na primeira situação extrema o tamanho dos bloco lido
pelos processadores em cada sub-tarefa 8 muito grande, de
maneira que eles gastam a maior parte do seu tempo de
processamento esperando a obtençgo do barramento, isto é,
eles ficam ociosos durante parte do tempo de processamento
da sub-tarefa; isto aumenta a DEGRADAÇBO do sistema.
Na segunda situaçgo, o tamanho dos blocos lidos nã.0 é
suficientemente grande para que ocorra uma disputa pelo
barramento entre os processadores, e ao contrdrio, é t2io
pequeno que o barramento fica parte do seu tempo ocioso,
logo o sistema esta sendo utilizado com um menor nhmero de
processadores que a sua capacidade máxima de atendimento.
Neste caso ao sistema pode ser acrescentado mais
Na segunda situação, o tamanho dos blocos lidos não B
suficientemente grande para que ocorra uma disputa pelo
barramento entre os processadores, e ao contrArio, B tão
pequeno que o barramento fica parte.do seu tempo ocioso,
logo o sistema est8 sendo utilizado com um menor nhmero de
processadores que a sua capacidade m8xima de atendimento.
Neste caso ao sistema pode ser acrescentado mais
processadores, podendo ter uma diminuição na DEGRADAÇZXO.
Este t2 o mesmo efeito gerado com o aumento o tempo de
procesãamento de cada sub-tarefas, pois cada processador
passa a solicitar o barramento com uma menor frequência e
o barramento fica parte do seu tempo ocioso.
O sistema & utilizado no melhor do seu desempenho quando
os processadores recebem o barramento prontamente ao
solicitarem, isto 6, em um sistema no qual os processadores
processam 100% do seu tempo. Por outro lado o sistema
tambkm 8 utilizado no melhor do seu desempenho quando o seu
barramento utilizado com um nhmero de processadores igual
a sua capacidade m8xima de atendimento.
I V . 3 . 3 - ESTUDO DA "ACELERAÇRO" DO SISTEMA ACP
Assim como na seção IV.l, podemos avaliar o desempenho do
sistema por um segundo método, determinando a a ACELERAÇRO
do sistema segundo os parametros (Pl,PZ,P3):
processadores do sistema (PZ), e iremos armazenar o
resultado na TABELA 9 (PROGRAMA M.FOR/ APEIBDICE F).
Devido Bs mesmas razões fornecidas na seção IV.l iremos
realizar o estudo para sistemas de at& 16 processadores.
Para fornecermos 1.000 subtarefas para um sistema de 16
processadores teremos que implementar uma tarefa composta
por 16.000 sub-tarefas.
Iremos variar o parametro (P1) de acordo com os valores
da seção IV.3.1.
Como iremos variar os parametros (Pl,P2) para termos
uma figura tri-dimensional, fixaremos o valor do
parâmetro (P3). Iremos adotar o valor P3=O.O2segundos
por se tratar de um tempo de processamento por sub-tarefa
suficientemente pequeno para observarmos alterações em um
sistema de 16 processadores.
TABELA 9
Um grdfico que representa esta tabela encontra-se na
figura 4.9. Nesta tabela sgo armazenados os valores de um
Sistema ACP com y processadores (coluna) para processar
16.000 sub-tarefas em função do ndmero de palavras lidas
por sub-tarefa (linhas).
FIGURA 4.9
Esta 6 a figura dos valores da divisão entre o tempo de
processamento de 16.000 sub-tarefas em um Sistema ACP com
(P2) processadsres, ndmero de palavras transmitidas por
sub-tarefa igual a (P1) palavras e tempo de processamento
por sub-tarefa igual a (P3=0,02) segundos em um Sistema ACP
com 1 proceãsador, onde:
x= (P1) = nhmero medi0 de palavras lidas no processador
vizinho por sub-tarefa.
assume os valores: (11, (10), (20) palavras
y=(P2)= ndmero de processadores
(P2) assume valores entre 1 e 16
z = ACELERAÇRO do Sistema ACP de y processadores para o
processamento de 16.000 sub-tarefas em função de x.
Nomero total de sub-tarefas = 16.000
(P3)= Tempo de processamento por sub-tarefa = 0,02
segundos
Tempo mkdio de transmissão de uma palavra=0,000004seg
(apêndice A)
NÚMERO DI PROCESSA
DORES
16
15
14
13
1 2
I I
1 o 9
8
7
6
5
4
3
2
I
NÚMERO DE PALAVRAS LIDAS NO PROCESSADOR VIZINHO POR SUB -TAREFA
T A B E L A 9 - ACELERAÇÃO DE UM SISTEMA ACP PARA O PROCESSAMENTO DE 1 6 0 0 SUB-TAREFAS DE TEMPO DE PROCESSAMENTO MEDI0 DE 0.02 SEG. POR SUB-TAREFA EM FUNÇAO DO NOMERO DE PROCESSADORES (LINHAS) E DO NUMERO DE PALAVRAS LIDAS NO PROCESSADOR VIZINHO (COLUNAS)
LIDAS NO PROCESSADOR VIZINHO POR SUB-TAREFA
Y = NÚMERO DE PROCESSADORES DO SISTEMA APC
Z = ACELERAÇÃO, DO SISTEMA ACP PARA O PROCESSAMENTO DE I 6 000 SUB-TAREFAS DE TEMPO MEDI0 DE PROCESSAMENTO 0 . 0 2 SEG
IV.3.3.1 - ANALISE DOS RESULTADOS
As causas da influência dos parametros: tempo de
processamento por sub-tarefa, tamanho do bloco de leitura
por sub-tarefa e nhmero de processadores do sistema no
resultado da ACELERACXO do Sistema ACP foram apresentadas
na seç3o IV.3.2.1.
Baseados na an8lise da influência do sistema de
comunicação entre os processadores do Sistema ACP, podemos
observar pelo gr8fico da ACELERAÇXO, figura4.9 que ao
fixarmos o tempo de processamento e o tempo de comunicação
e aumentarmos o nomero de processadores, a ACELERAÇXO do
sistema ir8 aumentar atk atingir um patamar, que
corresponde a saturação do barramento segundo o tempo de
processamento isto 8, o ponto em que o barramento est8
sendo utilizado 100% e que os processadores estão
processando 100%.
A partir deste ponto ao aumentarmos o nttmero de
processadores a velocidade do sistema não ir$ aumentar pois
o barramento ntXo poder& atender os processadores com a taxa
solicitada e os processadores passarão a ficar ociosos a
espera do barramento. O barramento continuar& sendo
utilizado 100% mas os processadores serão subutilizados a
medida em que se aumentar o nQmero de processadores.
131
Podemos observar pela tabela da ACELERAÇKO, tabela 9 que:
1 processador processa 16.000 sub-tarefas em 21
segundos, isto &,a uma taxa de 0,0013segundos por
tarefa.
16 processadores processam as 16000 sub-tarefas em 2,17
segundos. Atribuindo 1000 sub-tarefas para cada um
temos que cada processador processa uma sub-tarefa em
0,00217segundos
Podemos então observar que uma sub-tarefa em um sistema
com 16 processadores demora o dobro do tempo de
processamento se comparado a um sistema com apenas 1
processador. Por outro Lado, o sistema torna-se
aproximadamente 10 vezes mais rdpido.
CAPITULO V
CONCLUSBES
Iremos apresentar as conclust5es do "Estudo
Experimental do Multiprocessador ACP" na avaliação do seu
desempenho para problemas para os quais ele foi projetado,
ou seja, para problemas do tipo "orientado para eventos" e
para a avaliação do seu desempenho para problemas com
comunicação entre os processadores. Iremos comparar e
explicar os resultados obtidos e a seguir apresentar outras
conclusf3es obtidas ao longo do estudo desenvolvido.
I. Problemas do tipo "orientado para eventos"
Implementamos um programa de simulaçZo de um
problema do tipo "orientado para eventos" e obtivemos
uma taxa de transferência mBxirna de
7Qkbytes/segundos, ou seja aproximadamente 9% da
capacidade limite que é de 800kbytes/seg.
Avaliamos do estudo de "gargalos" do Sistema ACP ,
que a taxa mBxima de transferência entre ele e o
computador hospedeiro, é de 625Kbyteslsegundo.
Podemos supor então que o "gargalo " do sistema
est8 sendo o "software" de desenvolvimento, o ACPSYS . (OBÇ: De fato, nova versão do ACPSYS que ainda não
p8de ser implementada no CBPF dever8 aumentar a taxa
de transferência do sistema em 30%, ou seja, para
lOOkbytes/segundo.)
2. Problemas com comunicação entre os processadores
Implementamos um programa de simulação para um
problema contendo csmunicaçEío entre os processadores, e
obtivemos uma taxa de transferência entre os
processadores do sistema de lMbyte/seg.
Avaliamos do mesmo estudo de "gargalos" do Sistema
ACP que a taxa de transferência mAxima entre os
processadores & de 4Mbytes/seg.
Concluímos que para problemas onde existe comunicação
entre os processadores o sistema apresenta uma taxa
de transferência de dados 25% da sua taxa
de transferência mAxima.
3. Comparação entre os resultados obtidos
O Sistema ACP apresenta
um melhor aproveitamento da sua capacidade de taxa de
transferencia de dados em problemas onde ocorre
comunicaç~o entre os processadores.
Estes resultados podem ser explicados pelo fato de
que as subrotinas que executam toda a comunicação entre
o computador hospedeiro e o Sistema ACP , fazem parte
de um pacote de software de alto nível, o ACPSYS (seção
III.2), cuja finalidade & a de tornar o mais "amig8vel"
possivel o desenvolvimento de programas em FORTRAN IV.
Para problemas onde existe comunicação entre os
processadores não foram desenvolvidas rotinas de
comunicação, de forma que o usu8rio tem que trabalhar
em um nivel mais baixo de programaç30, tendo que por
exemplo implementar endereçamento absoluto para acessar
a membria remota, e implementar seus prbprios sem8foros
Capêndice c].
Podemos concluir que ao ter sido implementado um
software de alto nivel, se ganhou na facilidade e na
rapidez de desenvolvimento de programas, mas se perdeu
no seu desempenho.
Estgo sendo desenvolvidas melhorias no software e
no hardware do Sistema ACP [apêndice AI, com a
finalidade de melhorar o seu desempenho. Para sabermos
o quanto elas serão eficientes ser& necessArio a
implementaçgo dos programas de simulação desenvolvidos.
5. OUTRAS CONCLUSUES
5.1) Baseado nos resultados obtidos, na avaliação
da DEGRADAÇRO e da ACELERAÇEO do Sistema ACP , conforme
definidos no capitulo IV, verificamos que os
parâmetros que alteram o desempenho do Sistema ACP em
um problema do tipo "orientado para eventos" são :
135
O namero de palavras sendo transmitidas
O tempo de proeessamento do evento
O namero de processadores do sistema
5.2) Comprovamos que os programas de simulação são
eficientes para a avaliaçso do desempenho do Sistema
ACP .
5.3) Baseado nos resultados do estudo de
desempenho, desenvolvemos um modelo analitico para o
Sistema ACP , e verificamos que o modelo não era vzilido
para alguns resultados obtidos pelo programa de
simulação.
Podemos concluir que este modelo analitico
desenvolvido, est& deficiente para a avaliação do
desempenho do Sistema ACP . E por estar fora dos
objetivos desta tese, deixaremos como sugestgo para
futuros estudos, o desenvolvimento de um novo modelo
analitico para o Sistema ACP .
E importante ressaltar que os resultados obtidos para a
anklise do desempenho do Sistema ACP ntXo sergo
proporcionais a resultados obtidos caso sejam adotados
outros par&metros.
Consequentemente, para obtermos o comportamento do
sistema para problemas com parametros diferentes dos
adotados para o estudo da tese, como por exemplo para
determinarmos o comportamento do sistema para um tempo de
proeessamento mkdio de vinte segundos, (P3=2Osegundoe),
teremos que aplicar o mktodo apresentado no capitulo IV.
C17 THE ACP MULTIPROCESSOR SYSTEM AT FERMILAB
/I.GAINES, H.ARET1, R.ATAC, J.BIEL, A.COOK, M.FISCHLER,
R. I-IANCE , D . HUSNY , T . NASH and T . ZMUDA , Fermilab-Conf-86/132
C23 THE FERMILAB ABVANCED COMPUmR PROGRAM MULTI-
PICROPROCESSOR PROJECT/ T.NASH et al., Proc. Conf.
Computing in High Energy Physics, Amsterdam, June 1985
(North-Holland,Amsterdamfl!386) and referentes therein.
C33 SOFTWARE FOR EVENT BRIENTED PROCESSING ON
MULTIPROCESSOR SYSTEMS/ M.FISHCLER, H-ARETI, J.BIEL,
S.BRACKER, G.CASE, I.GAINES, D.HUSBY and T.NASH,
Processar and software research for High-Energy
Physics, Guanajuato, Mexico (1984) p.175.
C47 Bus Switch Specification,BSS. R.ATAC/ACP/FERMILAB
C57 AcpQ8020 CPU module User ' s Manual.
R.ATAC/ACP/FERMILAB
E67 E-769 Acquisition Systern. C.GAY/Toronto University
C71 Projeto MSPARALLEL, Colaboração IFT , Colaboração
COPPE CAPENDICE B3
C87 Extensões do Sistema ACP/Roberto Valoisl CBPF
C93 Segunda Geraçgo de Processadores Paralelos da
"Advanced Computer Program" (ACP)/ B.Schuze, R. Valois
/ CBPF
C107 "ACP User's Guide for LUNIN/Advanced Computer
Program-FERMILAB/Revision 3.1 /December 1,1987.
C117 "ACP User's guide for Utilities"/Advanced Computer
Program-FERMILAB/Revision 3.1 /December 1,1987.
C127 "ACP Software User's guide for Event Oriented
Processing"/Advaneed Computer Program-FERMILAB/Revision
2.0 /april 27,1987.
E137 BBBW1,"Branch Bus to Bus Switch
Interfacen/ADVANCED COMPUTER PROGRAM- FERMILAB/April
1,1987
C147 BSS,"Bus Switch Specification"/ADVANCED COMPUTER
PROGRAM-FERMILAB/April 2,1987.
E157 "Branch Bus to VME Interface(BVI)"/ADVANCED
COMPUTER PROGRAM-FERMILAB/March 11,1987.
C163 The VMEbus Specification/MOTOROLA/Reviaion
C.l-October 1985
C171 "MC68020 32-Bit Microprocessor User ' s
Manual/MOTOROLA
E187 "Le bus VME: description du fonctionement
dynamiqueM/Minis et Micros numero 162/Dominique Girod
C193 "Q-bus to VME Interface (QVI)"/ADVANCED COMPUTER
PROGRAM-FERMILAB/March 11,1987.
C201 "VMEvbus Branch Bus Controler(VBBC)"/ADVANCED
COMPUTER PROGRAM-FERMILAB/March 11,1987.
139
C213 "VMEbus resource module(VRM)"/ADVANCED COMPUTER
PROGRAM-FERMILABIMarch 11,1987.
C223 "Q-bus Branch Bus Controler"/ADVAbJCED COMPUTER
PROGRAM-FmMILAB/March 06,1987.
C237 "ACP User's guide for LUNIN/ADVANCED COMPUTER
PROGRAM-FERMILAB/Revision 2.0-April 14,1987
C241 Colaboração FERMILAB CAPENDICE B1
C253 Computer Architecture and ParalleL Processing/ Kai
Hwang Fayé, A. Biriggs
C263 Uma Introdução A Computação Paralela e Distribuida
/Claudia Amorim,Valmir Barbosa e Edil Fernandes
C273 VI1 Congresso da Sociedade Brasileira de
Computaçao /Introdução aos Supercomputadores lVirgilio
Almeida
C287 MAquinas de CAlculo Coordenado/Claudio Amorim,
Ronald Shellard
C293 Operating System Concepts/James Petrson, Abraham
Silberschatz
C303 Mips Dhrystones, and other tales /Datamation
/ july87.
C317 MIMD Computing in the USA-1984/ R.W.HOCKNEY/
Parallel Computing (19851119-136
C327 Experiência E-769 realizada no periodo de 06/87
a 03/88 no FERMILAB/U.S.A.,
C331 Tape transport Subsystem User's Guide , TSV05
DIGITAL EK-TSV05-UG-003
C341 Maxtor Product Specification and OEM Manual
/ XT-2000 PIONEER
C353 DRV11-WA General Purpose DMA Interface User's
Guide, DIGITAL EK-DRWA-UG-002
C363 Branch Bus Specification, BB, Advanced Computer
Programl March 6,1986
C373 Fastbus do Branch Bus Controler (FBBCII Advanced
Computer Program 14 oct.l985/Marcus Larwill.
C381 ACP32100CPU MODULE / Advanced Computer Program
oct.23,1986
C393 VME DISPLAY MODULE Advanced Computer Prsgram
jan.l986/Carla Osthoff
APENDICE A
DESEW0LVIi"EMTOS NO SISTEMA ACP
Para melhorar o Sistema ACP estão sendo conduzidas
duas linhas de pesquisa. A primeira tem como finalidade
desenvolver melhorias no software e no hardware da atual
sistema (se~go V.l) e a segunda tem como finalidade o
desenvolvimento de uma nova geração compativel com a
primeira mas com um poder computacional muita maior, o
Sistema ACP I1 C353 (seçgo V.2).
I - MELHORIAS NO ATUAL SISTEMA
A bltima atualização do ACPSYS & a versão 1.13
Implementãç2ío de uma extenszo de Linguangem Fortran
para programação concorrente.
Maior comunicação entre processadares:
- Desenvolvimento de um mbdulu que permite que um
processador mestre no barramenta VME possa ser
mestre no Barramento Branch, o VBBC C207.
- Implementação de Sistemas ACP possuindo mais de um
Barramento Branch acessando um mesmo bastidor VME.
- Desenvolvimento de um estrutura de chaveamento do
Barramento Branch, o Bus Switch C43:
1-42
o 16 portas bi-direcionais
o Banda de 20 Mhz para cada porta
o A ROM de endereçamento 6 capaz de endereçar até
2048 pracessadores
- Implementação de leitoras de fita com maior taxa de
transferência e de armazenamento de dados.
I1 - SEGUNDA GERAÇAO DO SISTEMA ACP
1. Opera~go com o sistema operacional UNIX
2. Eliminaçgo da dependência do computador
hospedeiro:
- Qualquer processador do sistema poderá assumir
a função de mestre e gerenciar a ditribuição
das tarefas de E/S.
- As tarefas de E/S serão realizadas par vdrios
processadores simultaneamente, atraves de
perifericos distribuídos no sistema.
- Os processadores do sistema poderão se
comunicar sem a necessidade de intervenção do
"mestre".
- Os processadores serso logicamente configurados
em grupos, com dados fluindo entre os grupos.
- Qualquer processador poderá ser um "nó"
conectado ao barramento Branch ou a um rede
Ethernet.
3. Novas unidades de processamento:
- Os novos processadores do Sistema ACP utilzam o
microprocessador MIPS de 32 bits com
arquitetura RISC E393, que deverá atingir um
desempenho computacional dez vezes superior ao
desempenho dos atuais microprocesãadores
MC68020/MC68881.
- Eles obedecerão o padrzo VME e poderão
gerenciar interrupções externas.
- Relógio de 8 Mhz e desempenho previsto de 8
MIPS .
APENDICE B
Projeto MSPARALLEL.Tem como objetivo o desenvolvimento
de um programa para a resoluç3o de problemas de
contorno em equa~õoes diferenciais ordinárias. O
algoritimo bdsico 6 um "multiple Shooting" adotado para
aproveitar o processamento paralelo do computador ACP
do CBPF. Este programa ser8 incorporado a um pacote
para resolução de equaçees diferenciais
parciaiâ.(projeto em colaboração com a Universidade
Simon Bolivar,IMIUFRJ e CBPF.
A colaboração com o IFT visa a pesquisa em algoritimos
paralelos e aplicações à fisica e matemática.
A colaboração com a COPPE est8 desenvolvendo dois
trabalhos de pesquisa : Na Brea de Sistemas de
Computação desenvolvendo a tese de mestrado "Uma
Avaliaçgo Experimental do desempenho do
Multiprocessador ACP. por Valmir Barbosa, Claudia
Amorim e Carla Osthoff.
Na Area de Engenharia Eletrica desenvolvendo a
tese de mestrado "CBlculo do Fluxo de Potencia em
sistemas de energia elktrica utilizando decomposição e
cellculo paralelo a partir de metodos iterativos." por
Eugenius Kaskurewick e por Nestor Roqueiro,
Na drea Engenharia Civil desenvolvendo a t e s e de
mestrado "Analise de Confiabilidade de Estruturas
Reticuladas" por Luis Volnei Sudati e Edson Lima, e a
tese de mestrado "Analise de grandes estruturas por
particao de dominio aplicada a computaeao paralelaUpor
Marcos Siqueira e Edson Lima Sagrillo
4. No período de desenvolvimento inicial deste
projeto,participou, pelo CBPF a engenheira CARLA
OSTHOFF .
No período de implementação do sistema
participaram pelo CBPF os engenheiros CARLA OSTHOFF e
BRUNO SCHULZE.
Atualmente participa do desenvolvimento de novos
projetos o engenheiro MARIANO MIRANDA pelo CBPF e, no
CBPF os engenheiros CARLA OSTHOFF, BRUNO SCHULZE e
VLADIMIR SALGADO a analista de sistemas ROBERTO VALOIS.
APENDICE C
................................................. 1 PROGRAMA EV.UPF ................................................. ! system=CBPP host source=EV.for hmt. library=QUAO:Clib.hplot.hp1digs11hpldigs.olb host library=DUAQ:tlib.digs3yralib.olb host library=DUAO:Clib.hbook7packlib.olb host library=DUAO:Clib.cernlib3kernlib.olb node source=node-ev.for node main subroutine = wait node blocks = lzinput, S:output, 3:calib class 1: node = 16 68020
~ A A A A A A A A ~ A ~ A A ~ A A k A A k A A k k A A A A A A A A A k ~ A A h A A A A A A k A A A h k A
C PROGRAMA W . f or ~ A A A A A A A A A A A A A ~ A A A k A A A A k j , k A A A A A k A A A k k k A A A A A A A A A k ~ A A A
C este programa avalia o tempo total de proces C de um evento de tamanho (Pl), de tempo de pr C (P3) em um Sistema ACP de (P2) processadore A k ~ A ~ A k A A A ~ A A ~ A A A A A A f c A A * ~ A k j , ~ A ~ A ~ A A ~ A * ~ A ~ ~ ~ A A * A A A A A ~
C comando necessdrio para a utilização das subro
C include 'acp$area:user~comrnon.inc'
C C declaração local:
common/calib/wat(2) logical nodeready,nodedone,lastevent,alldone logical readdone,response-node real- t i m e o s t f 10000) ,start-time~num~inl ,-speed( 11 , 17 real A(5>,SIG(5~,CH12,rnode,watfsoma,media(l1,l7~ real m(ll,l7) ,s(11,17~,0(11,17),overhead(ll,l7) real tp,tc(lO) COMMON / / HPiEM(10000) C G Inicializar o processo RMIMOM, carregar o LU C e o programa PJODEEVENTOS.FOR nos processador C do Sistema ACP. c
call hplint(0) cal1 acp-init
C C
C Abrir os arquivos de entrada e de saida
C
call acp-input-tape-open-file(status) call acp-output-tape-openfile(status)
C
call htable(l,'tp=8s $',11,1.,11.,17,1.,17.,0.)
call htable(2,'speed up $',11,1.,11.,17,1.,17.,0.)
call hbook2(4,'tp=8s $',11,1.,11.,17,1.,17.,0.)
call hbookZ(5,'speed up $',11,1.,11.,17,1.,17.,0.)
call hhookZ(6,'overhead $',11,1.,11.,17,1.,17.,Q.)
C Inicializar as variáveis e
C obs:o processamento m6dio C de um evento (P3)serB: 4.48 0.67 =3 seg C onde (P3)=wat(l)
wat11)=4.48
event=100 write(*,l)
1 format(lx,'entre o numero de proc. > > ' , $ I ACCEPT 2,node
2 FORMAT (I) iseed=secnds(O.O) iiseed=secnds(O.O)*Z
c Inieializar o "loop" de variação C do tamanho do evento (Pl=num-in) e do tamar C do resultado coletado (P4= num-out) C
C lembrar que num-out max=8000 C
read-done = .true. nodeready = .true. nodedone = .false. lastevent = .false. L = O.
cal1 acp-broadcast (3,wat,l,acp-r-4) C start of event loop C -----------e---------- ...................... 10 continue
CALL ACP-RWTAPE(IN,NUM-IN,READ-DONE,byte-count)
k*********k*k******k*******~***kh*kkk**************A A k SEND * k*****A***A***kk*k*****h**A*kk**A******A***********A
if(.not.lastevent) then if(nodeready) then 1= 1+1
nuln-in=rndm(iseedf*i*10000 end if cal1 acp-sendevent(in,num-in,nodeready) else if(acpp&lldone(responsenode)fgo to 20
end if h * A h * ~ * ~ * ~ A k k ~ k * A * * * * o t * * * A k * A A * * * * * * * * A k * * * * * * * * * * * * * PC GET 7k
*k***kk**********k********************hh***********A
go to 10- k****************k****k****k*******************~**** A Fim do "loop" de envio de eventos * ****Ah*******************kk****k*******************A
20 continue C determinaçgo do tempo total de procesamento C .............................................. time-host(mm) = secnds (start-time)
soma=time-host (mm)+soma
continue
media(i,l)=hij(l,i,l) end if
determinação da aceleração .....................................
determinaçgo da degradação ......................................
end if armazenar os resultados .........................
-- -
call hf i11 ( 1 .float ( i),f loat (nod=) ,media( i .nc
call Bfill(2,float(i),float(node),speed(i,nc
call hfill(3,float(i),floatfnode),overhead(: C voltar ao loop C -------e-------- ---------------- 400 continue
C fechar os arquivos de saida C -----------------e---- ...................... C
call acp-output-tape-closefile(status) call acp-input-tape-close_file(status)
C plotar ------ C ------ C
call hplego(4,60.,60.) call hplot(4)
cal1 hplego(5,60.,60.) call hplot(5)
call hpleyo(6,60.,60.) call hplot(6)
call hplend
call houtpu
call hprint
cal1 hprint
call hprint(3)
c os procedimentos de saida do C Sistema ACP
C fim do programa: c ----a----------- ---------------- C
stop end
subrout ine wait
C declaraçao local C
return end
APENDICE D
include 'acp$area:user-common.incl
c local variables: C - - - - - - - - - v - - - - - - ----------------
integerA4 in,out,status integerA4 num-in,num-out,event,node common/input/in(100000) c~rnmon/autput/out(l000~0) logiçal nodeready,nodedone,lastevent,alldone logical read-done,response-node real time~host(10000),start~time real wat,soma,media
event=100 num-out = 1. num-in = 1.
C Inicializar o "loop" de variaçSio C do tamanho do evento c ............................................
nodeready = .true. nodedone = .false. laatevent = .false. L = o.
start-time = secnds(0.0)
10 continue
IF(L.Gt.EVENT)LASTEVENT=.TRUE. A ~ A ~ A A h A * ~ A A * A A k k * h * * h * * * * * * * k * * * A * h * * * k * ~ * * ~ * * * * * * * * *
* * A SEND A * * k * * ~ A A A * ~ ~ A * k * * * * * * * * * * * * * * h * * A A A A * * * * * * * * * * * * * * * * * * * *
if(.not.lastevent) then iflnodeready) then 1= 1+1
end if c a l l acp-sendevent(in,num-in,nodeready) else if(aep-alldone(responsenode))go to 20
end if
~ k * A A ~ * * * A * * * * * * k * * * * * * A * * * k * * * * * * * * * * k k * * * * * * * * * * * * * * * * * Grn A * * k**AAk*******A*k*************k************************
call acp-getevent(out,num-o~t~nodedone)
20 continue
time-host(k) = secnds (start-time)
2 continue
C Avaliacao do valor medi0 c .....................................
!&RITE( 6,55 )media 55 FORMAT(/,lOx,' Processing time (sec) =',F8.2,/)
NUM OUT=NU-OUT+5000 CONTINUE
stop end
subroutine wait
C local declaration: C ------------------
-----------e------
return end
~kkkA*k**A*kkAkA*A*kA*A*AAAk**k*kkAA**~AAAAA~A*** ! PROGRAMA M4.UPF !AA**Ak*A~*A***k*kkAA~kA*AAkAA~Ak**kkkAk***AA*~AA
system=CBPF host source-m4.for hoãt library=dua0:Clib.hplot.hpldigsJhpldigs.olb host library=duaO:Clib.digs3gralib.olb host library=dua0:Clib.hbook3packlib.olb host library=dua0:Clib.cernlib7kernlib.olb node source=nodem4.for node main subroutine = wait node subroutine = wait node blockâ = l:input, 2:output, 3:calibf4:va class 1: nodes = 4 68020
~ A k k k ~ A k A k k * * k k A A k A A A A ~ A A A k A ~ h ~ A A j i A k k A A A A ~ A A A ~ A ~ A A A A A A A A A A A A
c PROGRAMA M4.FOR c A k * k k k ~ A k A * k ~ * * A * * * ~ * * A * A ~ A * A * A * A A A k * ~ A ~ * * A A A * * A A A * A A * * ~ ~ ~ A
C Programa para determinar o tempo total de processamento C de uma tarefa composta de 16.000 sub-tarefas, onde cada C sub-tarefa porcessa por um tempo (P3) e acessa a memori, C remota de um processador vizinho para ler um bloco C de tamanho (P1) C AA**~***kA*kAk**~*kA*A***A*kAkA*k*AAAkkkAA~***AAA***AAA****A.
include 'acp$area:user-common.incl
local varíables: -----------e---- ----------------
common//hmem(10000) comrnon/input/in(l0) common/output/out(l0) comrnon/calib/addr(lOO) comrnon/va/vec(100000) logical nodeready,nodedone,lastevent,alldone logical read-done,responsenode,send-done real*4 time~host(1000Õ),start~time,xl,x1,~2,yl,y2 realA4 soma,media(10000,17),tr(10000,17),np,tc,t integerk4 nodeaddress1,addr integerk4 in,out,status,vec,cont íntegerk4 num-in,num-out,event,nodes
Inicializar o processo RMIMOM, carregar o LUNI e o porgrama NODEMBSTER4.FOR nos processadores do Sistema ACP.
call acp-init call hplint(0)
determinação do endereço de VME do bloco a ser lido
..........................................
num-in = 1 addr(5)=2 addr(9)=l addr(8)=1000 addr(7)=10
call hbookZ(CONT+l,'master$',6,1.,6.,1,6.,0.)
call kibsokS(CONT+S,'tr table $',6,1.,6.,6,1.,6.,0.)
call htable(CONT+3,'master table $',6,1.,6.,6,1.,6.,i
call ktable(CONT+4,'tr table $',6,1.,6.,6,1.,6.,0.)
inicializar o "loop" de variacao do tempo de prõcessamento de uma tarefa (P3)
-------------------------------------a--------- ...............................................
inicializar o "loop" de variaçgo do namero de palavras lidas (P1)
------e------------------------------------ ...........................................
A BROADCAST A * * * * A A ~ A A * * * * ~ ~ * * * k * A * * * * * ~ * * * * * * * * * * * * * * * * * * * * * * * * * * * * A
c carregar os valores dos endereços de VME dos C blocos
call acp-broadcast (3,addr,9,ACP-1-4)
nodeready = .true. nodedone = .false. lastevent = .false. L = o. n=O
C Inicializar a contagem do tempo total de c processamento C ........................................
start-time = secnds(0.0)
10 continue
IF(L.eq.nodes)LASTEVENT=.TRUE. ******A&**&*********************h********************* * * A SEND A
* *A*A**k**&*A***~**************************************
if(.not.lastevent) then if(nodeready1 then 1= 1+1 n=n+l if(n.gt.nodes)n=l write(6,66)n
format(/,2x,' n =',i81 end if call acp-runnode(l,inr0,n,l,'wait',nodeready)
addr(5)=addr(5)+1
else if(acp-alldone(response-node})go to 20
end if A**&*k*hkk*k*A*~kkA*kA~k***k**kkkkk*h*k**k~***~***k*kk h * k GET k * * kk~kAk*kh*kk**k*kk*~k****k*kk***************k**k******
kk*~*k~hk*k****k*kA***********hkk****k***~hk***k****** k * ic end of event loop A h i+
~***~k*hkh~***kkkk**k**~***k********k***k***h*********
20 continue
C determinar o tempo total de processamento C
time-host(1) = secnds (start-time)
eont inue
determinar o valor mkdio
c addr(8)= numero de tarefas por processador C 0.4A0.0001 =tempo necessario para uma transmissão C add(4)*5= ntamero medi0 de transmissóes por tarefa C tc = tempo de comunicação por processador
C 0.005 =tempo medi0 de processamento por tarefa C addr(7)= cte que multiplica a funçgo randomica
0.65 = valor de correção da funçgo secnds np= tempo de processamento por processador
call hfill(cont+l,float(m),float(jj),media(m,jj))
call hfill(cont+2,float(m),float(jj),tr(m,jj))
call hfill(csnt+4,float(m),float(jj),tr(m,jjl)
somar 5000 no valor de (P1) e voltar ao "loop"
continue
continue
call hplego(cont+1,60.,60.) call hplot(conti-1) call hplego(cont+2,60.,60.) call hplot(cont+2) call hplend
call acp-exit stop end
subroutine wai t
call acpndi('PHYS1CAL NUMBER1,ph)
c inicializar a variavel randomica C -----------------------------
iseed = 1001*ph*addr(5)
seed = lOOlAphAaddr(9)
C i n ) 6 C o nQmero de acessos a membria remota(P1) C e iam varidvel randamica cujo limite C e fornecido pelo hospedeiro C .....................................
--------------------------------e----
C inicializar o loop para executar C 1.000 sub-tarefas C ..............................
(secnds) i? o tempo de porcessamento e o resultado de uma variavel randomica cujo limite(P3) foi fornecido pelo hospedeiro .......................................
executar a rotina de retardo ....................................
call acpwat(secnds)
caso seja o processador mestre, escreva na memoria local
.....................................
if (ph.eq.3) then call acpsup
do 40 i=l,n flag=long(addr(3))
continue call acpusr
caso seja processador escravo escreva na membria remota
............................................
else
call acpsup do 10 i=l,n
vm (LI )L= l ong ( add r12 1 continue call acpusr
end ii
CONTINUE
return end
! * * * * * * * * * * *~k*~~**kkkkk** * j , * * * * * * * * * * * * * * *~*~** * 1 PROGRAMA M. UPF !Ak*k*****kk*k************h******k**It*k**********
system=CBPF host source=m.for host library=dua0:Clib.hplot.hpldigslhp1digs.olb kost library=dua0:Clib.digslgralib.olb hont library=dua0:Clib.~ooklpacklib.olb host library=dua0:Clib,cern~ibIkernlib.olb node source=nodem4.for node main subroutine = wait node subroutine = wait node blocks = l:input, 2:output, 3:calib,4:va class 1: nodes = 16 68020
çAA&AAAAAAAAA&AAAAAAAkAAAhAAA*AAA*AA*A*AAAAA**AAAAA~*A****A*
C PROGRAMA M.FOR ~*AA*Ak**AA**k***A*A******~Ah*****~*************************
c Este programa determina a aceleração de um Sistema ACP d c proceãsadores para o processamento de uma tarefa composta c 16.000 sub-tarefas onde em cada sub-tarefa um processador c processa por (P3) segundos e acessa a mambria c remota de um processador vizinho (P1) vezes. C A A ~ & A A A ~ A A * A A & A A ~ A A A * A i t A A h * A * * * * * ~ * * * * * * * * ~ * A * k * * * * * * * * * * * * *
include 'acp$area:user-common.incl
C variáveis locais C ----------------
common//hmem(10000) common/input/in(lO) common/output/out(l0) common/calib/a(lO),addr(l0) common/valvec(100000~ logical nodeready,nodedone,lastevent,alldone logical read-done,responsenode,send-done real*$ time~host(10000),start_time,xl,x2,yl,y2,a real*4 soma,media(10000,17~,speed(10000,17),np integer*4 nodeaddress1,addr integer*4 in,out,status,vec,cont integer*4 num~in,num~out,event,nodes
call hplint(0) C determinar o endereço de Vm dos blocos C comuns dos processadores C -----------------------------------e------ ..........................................
num-in = 1 addr(5)=2
inictalizar o "loop" de variação do nGmero de processadores (P2) .......................
call ~ook2(CONT+l,'master$1f3.fl.,3.,16,1.f16.f0.~ I
call hbook2(CONT+2,'speed up Q1,3,1.,3.,16,1.,16.,0.
call htable(CONT+3,'master table Q1,3,1.,3.,16,1.,16
call htable(CONT+4,'speed up/tp=ls $',3,1.,3.,16,1.,
C inicializar o loop de processamento do numero de lei C ..................................................... .....................................................
h * A A * A A * * A * ~ * ~ A * * * * * A A * * A * * * * ~ ~ ~ * * * * * * * * A A * * * * * * A A * * * * * * A BROADCIÃST section fr A * * * ~ * h * k * ~ * A * A * h * * * * * k * * * * A * * ~ * * * * * * * k * * k * ~ * * * * * * A * * * * *
C carregar nos processadores o endereco de C VME do bloco comum
cal1 acpbroadcast (3,addr,8,ACPmI-4) a(l)=0.0001 a(2)=0.0002 a(3)=0.0003
c&ll acp-broadcast (3,a,8,ACP-r-4)
start-time = secnds(0.0) 10 continue
IF(L.eq.nodes>LASTEVENT=.TRUE. A * * A A A ~ * ~ A ~ A * ~ A * A A * ~ * * A ~ ~ * A * * A * * * * * * * A * * * * A * A * A * * * * * * * * k A SEND section A * A k*****A*****k***kA**A*~***************kk**************
if(.not.lastevent> then if(nodeready) then 1= 1+1 n=n+l if(n.gt.nodes)n=l
end if cal1 acp-runnode(l,in,O,n.l,'wait',nodeready)
addr(5)=addr(5)+1 else if(acp-alldone(response-node))go to 20
end if
**kk******k**********************k******************** * * A GET section A ik * k****k***A************k**k**************************k*
cal1 acp-getevent(out,l,nodedone)
~A*A&AA*AAA*&*A*A*AA* * * * * * * * * * * * *A* . j , * * k * * * * * * *A* * * * *~ * * k end of event loop A * * ***k*A*k*k*****************k********************k*****
20 continue
time-host(1) = secnds (start-time)
continue
determinar o valor medio .........................
call hfill(cont+l,float(m),float(jj),media(m,jj))
call hfill~cont+2,float(m),flsat(jj),speed(m,jj))
call hfill(cont+3,float(m),float(jj),media(m,jj))
call hfill(cont+4,float(m),float(jj),speed(m,jj))
incrementar o valor de (P1) e voltar ao loop ............................................
continue
continue
plotar -----e--- ---------
call hplego(cont+1,30.,30.) call hplot(cont+l) call hplego(cont+2,60.,60.) call hplot(cont+2) call hplend impri-~nir os histogramas no arquivo forOl5.dat ........................................... -------e-----------------------------------
call acp-exit stop end
APENBICE G
~k~AAAA**~~*~~~*Ak**AkA***AA*k*k*k****~k***A****A
1 PROGRAMA T . UPF ~AAAAA***AAk***A*~****k******kA***A~~A*A~A*A~AA~*
system=CBPF host source=T.for node source=nodeT.for node main subroutine = wait node subroutine = wait node blocks = l:input, 2:output, 3:calib,4:va class 1: nodes = 1 68020
~A&AAAAA*AhA**Ak**AAAAAkAAAAAkA**AkAAAAA***A***AAAAAAA*AAA*4
C PROGRAMA T.FOR C A A A A ~ A A A A ~ & A A A A ~ A A A A A ~ A ~ A A A A * A A A A * ~ ~ * A ~ ~ A A A A A * A A A A A A A A A A A A A J
e programa para deteminar o tempo de um processador realize c uma leitura de uma palavra em c uma memoria remota via barramento VP4E C AAAA&AAAAAAAAAAAAAAAAAAAAAAAA*AA*A**AAAAkAAAAAAAAAA** * * *AAAJ
include 'acp$area:user-common.incl
C local variables: C ----------------
common//hmem(10000) cornmon/input/in(lO) common/output/out(lO) çommon/calib/a(lO),addr(lO) common/va/vec(100000) logical nodeready,nodedone,lastevent,alldone logical read-done,responsenode,send-done real*4 time-host(10000),start-time,x1,~2,yl,y2,a realA4 soma,media(10000,17),speed(10000,17),np integerA4 nodeaddress1,addr integerA4 in,out,status,vec,cont integerA4 num-in,num-out,event,nodes
Inicializaçgo do processo RMIMOM, carregamento do processo nodemaster.for e do LUNI nos processadores do Sistema ACP
call acp-init call hplint(0)
num-in = 1 addr(5)=2 cont=O NODES = 1
C executar apenas uma sub-tarefa C ...............................
------------------------------e
ADDR( 8) =1
call acpbroadcast (3,addrr8,ACP-1-41 a(l)=0.0001
call acpbroadcast (3,aF8,ACP-r-4)
inicializar o valor medi0 ................................
inicializar o loop do evento -e------------------
nodeready = .true. nodedone = .false. lastevent = .false. L = o. n=O
inicializar a contagem do tempo total de processamento ........................................
10 continue
IF(L.eq.nodes)LASTEVENT=.TRUE. A******~**k**********hk*******hk*****h*k***********k** * h A SEND section * k k*****A*kk****k~k******k******~**k*k**k***************
if(.not.lastevent) then if(nodeready1 then 1= 1+1 n=n+l call acp-runnode(l,in,0,n,l,'wait',nodeready)
addr(5)=addr(5)+1 else if(acp-alldone(responsenode) )go to 20
end if
~*k*****************************k*k******************* * * k GET section k A A****k****h****~**************k*******kh***~*~******~*
call acp-getevent(out,l,nodedone)
subroutine wait
inicializar o loõp para executar 1.000 sub-tarefas ..............................
C escreva C na mem6ria remota C ............................................
call acpsup do 10 i=l,ADDR(4) vec(l)=long(addr(Z))
eont inue call acpusr
end if
CONTINUE
return end