Implementação e estudo da arquitetura a fluxo de dados Wolf

(1)

UNIVERSIDADE

DE

sAo

PAULO

INSTITUTO DE FISICA DE

sAo

CARLOS

"IMPLEMENTA<;=Ao E ESTUDO DA

ARQUITETURA

A FLUXO DE DADOS

W O LF'

(,

USP! IFQSC

I

S8!

M arcos A ntonio C avenaR hi

IIIIII\IIIIIII!IIIIIIIIIIIIIIII!IIIIIIIIIIIIIIIII

8-2·001184

Tese

J\presentada

au

lnstituto

de

Fisica

de

Sao

Carlos.

da

Universidadc

de

Sao

Paulo,

para

obten<;:ao do Titulo

de

D o u to r

em Ciencias:

Fisica

Aplicada

- op<;:3.o:Fisica Computacional.

DEPARTAMENTO

DE FISICA E INFORMATICA

sAo

CARLOS - 1997

r " " ·

lIe

p

(2)

I

Cavenaghi, Marcos Antonio

.

I

Imolementacao

e Estudo da Arquitetura a Fluxo de Dados Wolf

I

Marcos Antonio

I

Cav~naghi - S~o Carlos, 1997.

• I

I

193 p.

I

Tese (Doutorado) -lnstituto

de Ffsica de Sao Carlos. 1997.

I

Orientador: Prof. Dr. Alvaro Garcia Neto

\

11. Arquitcturas Para1clas

2. Arquiteturas

a Fluxo de Dados

3. Simula<;ao

I

(3)

U N IV E R S ID A D E

D E S A O P A U L O

Av. Dr. Carlos Botelho, 1465

CEP 13560-250 - Sao Carlos - SP

Brasil

Fone (016) 274-3444

_

Fax

(016) 272-2218

MEMBROS

DA

COMISSAO

JULGADORA

DA

TESE

DE

DOUTORADO

DE

M A R C O S

A N T O N IO

C A V E N A G H I

APRESENTADA

AO INSTITUTO

DE FISICA

DE SAG CARLOS,

DA UNIVERSIDADE

DE SAG PAULO, EM 25 DE NOVEMBRO

DE 1997.

\

\\

---1- ...•.

·~.•...---tO/IF~C-USP

_/!

.·Z

< --'

i

/ --

.>---./~

~~;;;-.:_._---"';---~---.;._.:_---.;.---~-Prof

Dr. Luis Carlos Trevelin/UFSCar

/ I' I

<--IA 'c___ _ .'1

)"t..-.-

J : > ~ . : · h

(4)

-minha

sobrinha

Paula pelo incentivo,

confian~a

e amor.

E a todas

as pessoas

que, atraves de seus

exemplos,

mostraram-rne urn pouco

do profundo

significado

do que

e

a vida equal

seu objetivo."

(5)

(6)

Folhas

secas pelo

chao;

Este

luar ca da cidade

tao escuro

Nao tern aquela

saudade

(7)

(8)

C o n te u d o

I

I m p le m e n t a c : ; o e s a F lu x o

d e D a d o s

1.1 Tntroduc;ao

.

1.2 A ~Ifaquina a Fluxo de Dados de Manchester

1.3 A

Afit

Tagguj

Tokw

D ataflow

A rdtitu:luT'(:

.

1.3.1 a

Conceito de Elemento

de

J-Stnu:tuT'(:

1.4 A Maql1ina Monsoon

.

1.4.1 a

Conceito de

Explicit

Token

Ston

(ETS)

1.5 A Maql1ina

*T

.

1.5.1 a

Conceito de

M ultithrtading

1.6 A Maqllina

EM-4

.

1.6.1 a

Conceito de

A/aero-D ataflow

1.7 Considera<.;oes Finais e Sintese do Capitulo

1.8 Conclllsoes...

II

A A r q u it e t u r a

a F lu x o

d e D a d o s

W o lf

2.1 Tntrodll<.;ao

.

2.2 Defini<.;aoda Arqllitetura

\VoIr

2.3 Funcionamento

da Arqllitetura

WoIr

2.4 Unidades

da Arquitetura

\Volf Tmplementadas

no Simulador*

2.4.1 a

M()dulo de Entrada

e Saida

(9)

2.4.4 A ;\Iernclria

de Instruciws

Interna

2.4.5 A. \Iernclria

de Instmc/ws

Externa

2.4.G

A Chave

de DistribuicJio

2.4.7 A Fila de Fichas

2.4.8 A U nidade

Funcional

2.4.9 A \lernclria

de Estmturas

2.5.1 Caraeterfst

icas de urna

Lingllagern

para

Prograrnac.;iio

Paralela

48

2.5.2 D ata

P(J'T'{llltl

C

Exttnsion.';

- D PC E.

50

2.5.3 H iqh pfTfonnana

For·tm n

- H PF

50

2.5.4 Stn:aTTl.'; and

Jttm tions

in

a Singh

AssignTTlw t

[,angw lgt

- SISAl,

51 o

Processo

de Cornpila<Jio

para

0 Sirnulador

Algoritrnos

Utilizados

.

Conclllsc)es

. . . .

I I I

I n v e s t ig a n d o

a A r q u it e t u r a

W o lf

3.1 Introduc;ao

.

:3.2

Irnplernentac;ao

do Sirnulador*

:3.2.1

0 T\Iecanisrno

de Ternporizac;ao

:3.3.1

Execllc;ao

de C6digo

Seqiiencial

ern Arquitduras

a Fluxo

de Dados

GO

:3.3.2

Mecanisrno

Simples

de Detecc;ao

e Execuc;ao

de Ccldigo Seqiiencial

63

3.3.2.1 Resultados

da Irnplernentac;ao

no SiTTllllador

:3.4

Experirnento

de Balancearnento

das Unidades

do \iVo!r

:3.4.1

Critprios

para

Escolha

d(' Tempos

e Parada

:3.4.2

Resultados

do Experimento

.

3.4.2.1 Escolha

de mn dos Resultados.

:3.4.2.2

Validac;ao

dos Resultados

3.5 0 Experimento

de Multiprogramac;ao*

0; [

n v

I ',: ()

C

r:

BIn

t

lOT

E C A

,

(10)

(11)

130

132 1 3 4

(12)

L is ta d e F ig u r a s

1.1 Maquina

Fluxo de Dados de ~I/Ianchester.

1.2 A Arquitetura

da MTTDA.

1.3 A Arquitetura

da Monsoon.

1.4

0 l'vfodelo ETS.

1.5 A IVfaquina

" T .

1.6 A l\!laquina ENf-4 ..

2.1 A Arqllitetura

FlllxO de Dados \Volr .

2.2

0 Modulo de Entrada

e Safda.

2.3 A Chave de Coleta.

. .

2.4 A ~Tem6ria de Dados ..

2.5 A Mem()ria de Instru<;oes Interna.

2.6 A Mem6ria de Instru<;oes Externa.

2.7 A Chave de Distribui<;ao.

2.8 A Fila de Fichas.

. . .

2.9 A Unidade Funcional.

.

2.10 A Memoria de Estruturas.

2.11 ProcesS() de Compila<;ao.

.

2.12 Seqiiencia de Compila<;ao de urn Program a SISAL.

3.1 C6digo Seqiiencial.

. . . .

:3.2

Ocupa<;ao da Memoria de Dados para 1 Gauss ..

3.3 Ocupa<;ao da Mem6ria de Dados sem Seqiiencialidade ..

:3.4

Ocnpa<;ao da Fila de Fichas sern Seqiiencialidade.

(13)

;3.6

Ocupa<';<loda ~remoria de Dados para

1

O i l

11.';,'; ..

;3.7

Ocupa<;ao da Fila de Fichas para 5

O i l ' l l . , ; , ' ; .

;3.8

Ocupa<;ao da Fila de Fichas para

I

O i l ' l l . , ; , ' ; .

4.1 Ocupa<;ao da \Jemoria

de Dados para Ackermann.

. . . . .

4.2 Ocupa<;ao da \Iemc)ria de Dados para Dinamica

fvlolecular.

4.3 Ocupa<;ao da ~remoria de Dados para Somalorial.

4.4 Ocupa<;ao da Fila de Fichas para Somatorial.

.

4.5 Ocupa<;ao da Memc)ria de Dados para

F F T .

4.6 Ocupa<;ao da Fila de Fichas para FFT ....

4.7 Ocupa<;ao da \Iemoria

de Dados para Gauss.

4.8 Ocupa<;ao da Fila de Fichas para Gauss.

4.9 Ocupa<;ao da \Iemc)ria de Dados para Interpola<;ao.

4.10 Ocupa<;ao da Fila de Fichas para Interpola<;ao.

4.11 Ocupa<;ao da \Iemoria

de Dados para Laplace.

4.12 Ocupa<;ao da Fila de Fichas para Laplace.

4.13 Ocupa<;ao da \Iem()ria

de Dados para MuHiplica<;ao de Malrizes ..

4.14 OCllpa<;ao da Fila de Fichas para ~/rllltiplica<;ao de l\tJatrizes.

4.15 Ocupa<;ao da Memoria de Dados para N-Qlleens ..

4.16 Ocupa<;ao da Fila de Fichas para N-Queens ....

4.17 Ocupa<;ao da \femoria

de Dados para Quicksort ..

4.18 Ocupac;ao da Fila de Fichas para Quicksort.

.

4.19 Ocupa<;ao da \'Iemoria

de Dados para Simple.

4.20 Ocupa<;ao da Fila de Fichas para Simple.

96

97

98

99

100

102

104

105

106

107

108

109

110

111

5.1 Exemplo de utilizac;ao dos aneis

.

0.2 Arquitetura

\Volf corn a FF descentralizada.

5.3 Distribui<;ao de Carga com Descentraliza<;ao da FF.

0.4 Varia<;ao do tempo da

r-.H.

5.5 A Arquitetura

\Volf II ...

5.6 A Arquitetura

da !\Iemc)ria de Dados.

5.7 Arqu itet ura para

0

Processador

e Memoria vetoriais.

(14)

L is ta d e T a b e la s

3.1 :3.2

:3.3

3.4 Tnifego de Fichas pela Mern6ria de Dados

.

Porcentagem

de Utiliza<;ao de cada unidade

- parte

1. Porcentagem

de Utiliza<;ao de cada unidade

- parte 2.

Porcentagem

de Utiliza<;ao de cada unidade

- parte 3.

Porcentagem

de Utiliza<;ao de cada unidade

- parte 4.

Porcentagem

de Utiliza<;ao de cada unidade

- parte 5.

Tempos Utilizados

para as Unidades

do Simulador

.

Valida<;ao do Experimento

...

Multiprograma<;ao

com Gauss.

Multiprograma<;ao

com

Fator·ial.

Multiprograma<;ao

com

A c k f : r · m a n n .

Multiprograma<;ao

com 5 Program as Diferentes.

Multiprograma<;ao

com 4 Program as Diferentes.

:3.6

3.7

3.8

3.9 :3.10

3.11

3.12

3.13 Distribui<;ao de Carga nos Aneis MI-UF.

Comportamento

da Cc.

.,.

. . .

Comportamento

da Temporiza(~ao.

Utiliza<;ao de cada unidade.

118

119

(15)

R e s u m o

Esse trabalho

apresenta a arquitetura

a ftuxo de dados Wolf. Essa arquitetura

foi

proposta

considerando-se alguns problemas conhecidos ern execu<;ao de c6digo ern

ar-quiteturas ,a fluxo de dados tais como tratamento

de c6digo seqiiencial e tratamento

de

estruturas

de dados (vetores e matrizes).

\Volf

e

baseado no modelo de ftuxo de dados dimimico e explora granulosidade varia vel:

sendo a mais fina "a nivel der- instru<;ao. Alguns conceitos explorados por outras

arquite-turas a fluxo de dados guiaram

0 desenvolvimento do Wolf. Entre esses estao

0 conceito

de "macro-dataflowr- e "multithreading':.

Para

0 estudo da arquitetura

Wolf foi desenvolvido urn simulador dirigido a tempo

que implementa suas caraderfsticas.

0 simulador Saw foi escrito na linguagem orientada

a objetos C++

e pode ser compilado ern qualquer plataforma

que use urn compilador

padrao ANSI de 32

b i t s .

0 cOdigodo simulador foi exaustivamente testado e os resultados

numericos dos programas executados estao de acordo corn resultados apresentados por

uma arquitetura

yon Neumann padrao.

Ap6s

0 estudo dos resultados obtidos corn as simula<;Oes:foram identificados alguns

problemas com a arquitetura

Wolf. Algumas hipOteses foram testadas para solucionar

tais problemas.

Os resultados desses testes levaram

it

altera<;ao da arquitetura.

Desta

altera<;ao: originou-se a arquitetura

Wolf II que sera apresentada

tambem nesse trabalho.

Por se tratar

de uma conseqiiencia dos estudos realizados corn a arquitetura

Wolf: nao

(16)

A b s t r a c t

This work presents the dataflow architecture

Wolf. Wolf has been proposed in t he focus

of some known problems identified in previous works: the execution of data structures

(vectors and matrices) and sequential code: to name a few.

Wolf is based in the dinamic dataflow model and explores variable granularity

(the

thinnest is at instruction level). Some concepts developped in the designing of other hybrid

architectures:

guided the Wolf implementation.

The macro-dataflow

and multithreading

were two of them.

Focusing the study of the Wolf architecture:

it has been developped a time driven

simulator

(Saw). The object oriented language

C + +

was used for this implementation.

The code can be compiled on any ANSI standard

32 bits compiler.

This code was

ex-haustivelly

tested and the numeric results obtained

with the experiments

were equal to

the ones obtained with a von Neumann architecture.

This study identified some problems with the \Volf architecture.

Some proposals were

implemented

in the simulator to try to identify the causes for the problems.

The results

led to an alteration

in the \Volf architecture.

The new proposed architecture

(\Volf II) is

(17)

I n t r o d u < ; a o

Wolf

[1,

2, 3,4: 5, 6: 7] e uma arquitetura

baseada no modelo de ftuxo de dados dinamico

com granularidade

variavel. Esta arquitetura

foi proposta inicialmente em reunioes do

grupo de fiuxo de dados do Instituto de Fisica e Quimica de Sao Carlos (IFQSC-USP)

com-posta pelos professores Alvaro, Ruggiero e Catto (Unicamp) e alunos de p6s-graduac;ao.

Estas reunioes ocorreram ate 1992. A proposta inicial era propor uma arquitetura

que

reuni-se as Iic;oes aprendidas com a implementac;ao da Maquina a Fluxo de Dados de

Manchester (MFDML visto que os tres professores participaram

das pesquisas com a

MFDM praticamente durante todo

0 periiodo em que esta Ikou operacional.

Para investigar a arquitetura

Wolf: foi desenvolvido urn simulador (Saw) que

imple-menta as caraeteristicas da arquitetura em questao. 0 simulador foi desenvolvido na

lin-guagem orientada a objetos C++.

Utilizou-se apenas func;6esdocumentadas peIo padrao

ANSI sendo possivel compilar

0 c6digo do simulador em diferentes plataformas.

No

tra-balho de mestrado deste mesmo autor

[81:

[oi desenvolvido urn simulador simplificado para

a arquitetura

Wolf. 0 leitor nao familiarizado com a arquitetura

Wolf, pod era ter urn

melhor aproveitamento se iniciar seus estudos pelo trabalho de mestrado.

Esta tese apresenta os resultados obtidos na investigac;ao da arquitetura

a fluxo de

dados Wolf atraves do uso do simulador Saw, e para isto foi dividida em cinco capitulos:

o

Capitulo 1 apresenta as principais arquiteturas

a fluxo de dados desenvolvidas nos

principais grupos de pesquisa

( M a n c h E s t E r ':

M I T

e

E T L / M I T l ) .

A discussao sobre estas

arquiteturas

visa mostrar suas principais caraeterlsticas

e inovac;oes. No caso das

ar-quiteturas estudadas no

AfIT,

serao apresentados os problemas encontrados e as soluc;oes

propostas com a implementac;ao de novas arquiteturas.

Note-se que todas as arquiteturas

apresentadas

foram propostas como "arquiteturas

de

11S0

geral": nao sendo projetadas

(18)

o

Capitulo 2 apresenta a arquitetura

a fluxo de dados \Volf. Aspectos da

imple-menta<;ao de cada uma de suas unidades tambem sao discutidas em detalhe.

Durante

0 desenvolvimento do simulador foram propostas varias caracteristicas

a

cad a unidade da

arquitetura.

Estas caracteristicas foram implementadas no simulador e

0 detalhamento

delas encontram-se neste capitulo. Sao apresentadas tambem algumas linguagens de

pro-grama<;ao paralela usadas por varias propostas

de arquiteturas

paralelas.

0 capitulo

encerra-se com a apresenta<;ao do processo de compila<;aousado para gerar codigo para

0 simulador.

o

Capitulo 3 apresenta as caracteristicas implementadas pelo simulador com base nas

consider~<;oesde cada unidade discutida no capitulo anterior.

Mostra tambem a

inves-tiga<;ao do simulador desenvolvido~ isto e~ descreve

0 ajuste do simulador para obten<;ao

de resultados. Este ajuste consistiu em alguns experiment os que sao descritos no decorrer

do capitulo. Todos os ajustes feitos no simulador sao importantes~ visto que esses ajustes

permitem a adequa<;ao de suas unidades ao comportamento

desejado.

o

Capitulo 4 discute os resultados obtidos com

0 simulador. Estes resultados foram

apresentados em forma de curvas de ocupa<;ao de duas unidades simuladas.

0 estudo

da ocupa<;ao destas unidades permite conduir como a arquitetura

comporta-se durante

o processo de execu<;ao de urn programa.

Algumas caracteristicas

gerais do algoritmo

utilizado tambem podem ser obtidas com base nesses dados. Para situar a arquitetura em

termos de desempenho: foi utilizado urn experimento que comparou

0 tempo de execuc;ao

de urn programa em uma arquitetura

yon Neumann e no simulador.

o

Capitulo

5 apresenta

0 problema de distribui<;ao de carga nos aneis

memoria-procestador verificado com a uso do simulador.

Sao propostas algumas hipoteses para

explicar a distribui<;ao ineficiente.

Cada hipotese e discutida e testada

atraves da

ex-perimenta<;ao com

0 simulador.

As conclusoes de tais experimentac;oes levaram a uma

remodelagem da arquitetura.

Com esta remodelagem espera-se que a nova arqllitetura

(19)

Capitulo I

Implementa<;oes a Fluxo de Dados

1.1 Introd u<;ao

(20)

r

Matching Store

1 _{'[_ _}

_{N o _ d e_ S t_ o re_ h}

• Token

Queue

I

U

_r

I

11'0 modelo

a flllXO de dados dinamico

usado pcla MFDM,

a cor de um dado designa

a instancia<;ao

(21)

• 0 mimero

de estagios

do pipeline

da

M F D M

e maior

que

0 necessario

e atrapalha

o desempenho.

• A implementa<.;ao

aSSlTIcrona dos estagios

causa

atrasos

no

piptlint

e dillculta

a

depura<.;ao do prot6tipo.

• 0 comprimento

fixo da palavra

(;32 hits) nao e adequado,

sendo muito pequeno

para

aplica<.;oes numericas

e excessivamente

grande

para

aplica<.;oes simh()licas.

• A granulosidade

Ilxa da ~!rFDM impossibilita

a pesquisa

sobre a granulosidade

6jima

em process adores

a [luxo de dados.

• Ra redundancia

em diversos campos

das Ilchas, aumentando

de forma desnecessaria

o espa<.;o de emparelhamento.

• 0

emparelhamento

associativo

degrada

0 desempenho

da maqulTla,

aumentando

consideravelmente

a latencia

para

execu<.;ao de lUna instru<.;ao.

A linguagem

de programa<.;ao usada

e

SISA L

uma

linguagem

funcional

desenvolvida

pelo

La'W T'tfU ;t LivtTTTlor·t jV aliorull

IA lbom lor'y

na decada

de

1980.

Um prot{)tipo

de urn

anel

foi construido

e esteve

operacional

durante

varios

anos,

tendo

sido desativado

em

1 .3

A

M it

Tagged Token D ataflow

A rchitecture

(22)

I~

~

I

n-cube

switch

1 1 1 \1

I

I-Structure

Memory

(23)

(24)

A linguagem

de programa<;ao

da ]'vlTTDA e

[ ( L

mna

linguagem

espedflca

para

ar-quiteturas

a fluxo de dados desenvolvida

pelo gnlpo

do ]'vlIT na decada

de

1980 [11].

A

arquitetura

0.JTTDA

foi implementada

em mn sim1l1ador em 1987 e largamente

explo-rada.

As li(i>es aprendidas

com sua implementa<;ao

e estudo

deram

origem

a uma nova

arquitetllra

(Afonsoon

-

descrita

na se<;ao seguinte);

incorporando

conceitos

novos ao

mo-delo de fluxo de dados.

Todos os resultados

obtidos

com esta arquitetura

foram atraves

do

sirrmlador.

A Irnplementa<;ao

do

haniw an.

nunca

foi descrita

na literatma.

0 artigo

que

introduz

esta arquitetura

foi publicado

no infcio de

1990.

Nao foram publicados

resultados

que mostrassem

os pontos

probleTmiticos

da arquitdura.

Urn elemento

de

J-Str71clurt

(IS)

[12]

e urn modulo de memoria

com urn controlador

que

gerencia

pedidos

de leitma

e escrita

de estruturas

de dados

como vetores

e matrizes.

Na

area de armazenamento

de dados; cad a posi<;ao tern

bits

de preseTl(~a ext ras que especi ficam

esiados:

Presente;

Ausente

ou

Esperando.

Quando

uma

IS e alocada;

todas

as suas

posi<;oes sao colocadas

no est ado

Ausente.

Quando

llma ficha de leit ura chega a mn elemento

de IS; ela contem

0 endere<;o da

posi<;ao a ser lida e

0

t a g

da instru<;ao

que esta

esperando

0

valor.

Se esta

posi<;ao e

Presente;

0 dado e lido e enviado

para

a respeetiva

instrll<;ao; nao alterando

0 estado.

Se

0 estado

e

Ausente

ou

Esperando;

a leitura

e deferida;

isto e

0 dado e "enfileirado"

naquela

posi<;ao. A fila formada

at raves deste processo

e uma lista encadeada

de

la g s .

(25)

(26)

I

Ii

II

I

(27)

no ;\HT em

1988

[131:

a maquina

lVlonsoon contribuiu

para

0 aprimoramento

dos

con-ceitos

de fluxo de dados,

proporcionando

0

aparecimento

de novas ideias.

Um conceito

fundamental

nos dias de hoje para

arquiteturas

a fluxo de dados

e cujo embriiio

surgiu

dos est udos da Monsoon

e

0 m ultithnading.

Neste sentido,

pode-se

dizer que a maquina

?vlonsoon originou

algumas

das ideias

fundamentais

para

implementa<Jio

de uma

nova

arquitetura

a fluxo de dados chamada

* T .

o

C o n c e it o d e

Explicit

Token StaTe (ETS)

o

Explicit

Token Store (ETS)

[15]

(Figura

1.4) e urn modelo

simplificado

de execu~ao

de fluxo de dados dinamico

centrado

na no<;ao de

fm m t

de ativa<;ao. Este modelo perrnite

armazenamento

explicito

de operandos

e

bits

de presen<;a baseado

na associa<;ao do

tag

(contexto

e instru<;ao

destino)

com posi<;oes ffsicas nos quadros

de memorias

locais aos

elementos

de procestamento.

Os

bits

de preser\(;a sao usados

para

guiar

0 procestamento

de instru(,;(ws.

Este

sis-tema eJimina

0 m atching

associativo:

a aloca<;ao de armazenamento

implfeito

presente

em

modelos

de fluxo de dados

com

lags.

0 compilador

deterrnina

0 uso de

slols

dentro

de

urn

fram E

e instala

opera<;oes de aloca<;ao e desaloca~ao

ern

fm m u;

nos gra[os.

(28)

,

\ \

\ bitp res. ld J o r

L' ~ ~'aLJO

I i rrcs 6.& + 7

::21

,",JO

l'v

I

t

1 " - - - - 1 "

cH

I

(29)

1 .5

A

M a q u in a

* T

',: f'

r~'.;

I (."

(1

p r:

n

I

n

I lOT

E CA'

IF

,..,r ..

_{J "-...-}

I. _~.,-

j,cr;

-

_{;- (''')}

(30)

Coprore;sad<>r de

R e q u l'ik a o d e

C oproc ••••• d<>rde Procossador

S ln c r o n tz a c a o _{d e D a d o s}

I,PI _(dl';

D

,0'

D

dO'

F ila d e C o n tin u a c a o

B

,FP I<TP,FP>.

B

dFP

,VI R I

(31)

latencia

grande

na suspensao

da execu<;ao de

lhTf:ad.< ;

devido a inevitavel

dependencia

de

dados

existente

entre

eles.

Nao for am apresentados

resultados

obtidos

corn a maquina:

apenas

artigo corn conclus()es.

Para diminuir

esta latencia:

foi proposta

uma nova

arquite-tura

chamada

"'T-NG

(17: 18].

Esta

arquitetura

usa mecanismos

de coen~ncia de

caclu

para

a memoria

global compartilhada.

A "'T-NG nao sera abordada

por este trabalho:

ja

que nao possui

nenhum

mecanismo

especial

cujo conceito

sera usado neste trabalho.

o

C o n c e it o

d e

M 'ultdhr-ead'ing

urn

lhnad

(19]

e uma sequencia

de instru<;<)es estaticamente

ordenadas

pelo

compl-lador.

Quando

urn

thnad

e escalonado

para

execu<;ao: este nao e interrompido

ate que

todos

os seus I\(>s seJam executados.

Um

thnad

define uma unidade

basica

de trabalho

consistente

com

0 modelo

de nuxo de dados.

0 conceito

de

lhnad

combina

chavearnento

de contextos

"a nlvel de'" instru<;<)es com escalonarnento

seqiiencial.

Como

m T l

lhnad

define a unidade

basica de escalonamento

de um programa:

a

granlI-losidade

da computa<;ao

e definida

pelo tamanho

do

thnad

utilizado.

Cada

lhTuul

possui

urn custo

de procestamento

associ ado:

afetando

diretamente

a quantidade

de

o'U f:rhuu!

necessaria

a sinuoniza<;ao.

PorenL

0 alvo principal

no particionarnento

de um program a

em

lhn(uL

e a maximiza<;ao

do parale1ismo

e a minimiza<;ao do

o'U f:Thuul.

Existern

varias maneiras

de se obter urn

lhnad

quando

do particionamento

de urn

pro-grarna.

Pode-se

obter

lhruuls

subdividindo

urn

loop

paralelo

ern urn mlmero

de processos

seqiienciais.

Como conseqiiencia:

a granulosidade

de cada

lhnod

tende

a ser grossa:

(32)

dados que sao resolvidas

apenas

dinamicamente.

Iannucci

[20]

propoe

liTn metodo

de particionamento

para

maXlmlzar

0 paralelisrno

exploTilveL

isto e, instr1J(~oes que san agrupadas

em

thn.ads

devem

fazer parte

de lITTl

C<ldigo onde 0 paralelismo

explonlvel

e baixo 011 de preferencia

nenhurn.

Qualquer

arco

que ultrapasse

os limites

de urn

thrtad

implica

em sincronizae,;ao dinamica

introdllzindo

oVfrhtad

e aumentando

os cic10s de procestamento.

Todo

0 particionamento

do program a em

thnads

e execlltado

em tempo de compila<;ao,

tornando

diffcil preyer

resultados

de dependencias

dinamicas.

Desta

forma,

as tecnicas

para part icionamento

de program as ern

thnads

nao abrangern

10dos os casos.

1st

0

provoca

urn allrnento

no tempo

de execlI<;ao de urn

thn(uL

allmenlando

0 oVfrhf(ul

introdllzido

devido

as dependencias

de dados

causadas

por arcos dinarnicos.

Vma tentativa

de minimizar

este

oVfrhtad

e multiplexar

0 escalonamento

entre

varios

thnads.

Este eo

conceito

de

m uU ithrtading.

Neste sistema,

qllando

urn

thnad

necessitar

de urn dado armazenado

remotarnente,

0 processador

suspende

a execll<;ao do

thTU J.d

em

questao

e inicia a execu<;ao de 11m 011tro

thnad.

0 custo do chaveamento

entre os

thn:rul.c;

e inferior

a latencia

de uma leitura

a urn dado arrnazenado

remotamente.

Vma consequencia

deste mecanismo

e

0 sllrgirnento

do conceito

de

contin'lw .tiorJ.

Urn

continuation

e urn identificador

que as mensagens

de leitura

e resposta

de leitllra

carregam

para

que 0 respectivo

thnad

possa ser reiniciado

adequadarnente.

A

M a q u in a E M -4

o

£1vl-4

[21]

e

lIma Tmlquina com gran1l10sidade

variavel

empregando

°

conceit () de

(33)

(34)

3. U n id a d e d e

F tlch

e

E m p a r e lh a m e n t o

( F M U ) :

A FMU realiza

a operac;ao

de

emparelhamento

e busca de instru(;<'>es.

4. U n id a d e d e E x e c ll( ; ; a o( E X U ) :

Responsavel

pela

exec1l<;ao de instru<;<>es sobre os

dados,

ambos

trazidos

pela FMU.

5. U n id a d e d e C o n t r o le d e M e m o r ia ( M C U ) :

A MCT; arbitra

sobre as requisi<;c)es

de aCf~SSO

a

mem6ria

pe1a

IB 1 1 ,

FMU e EXU, enviando

entao

dados

entre

a area de

mem6ria

fora do

chip

e

0

EMC-R.

6. C o n t r o la d o r d e M a n u t e n f ; a o ( M A I N T )

0 MAINT

opera

principalmente

para

iniciar

0 sistema,

monitorar

a execuc;ao de program as e

dtlJ11g

do

har·dw an:

e

.< ;o/lw an:.

11m prot6tipo

com

80 elementos

de procestamento

esLi operacional

desde

1990

no

F ;ltlm ltchnical

f.,a!Jom lo'ry

(ETLjMTTI)

no Japao.

Nao foram publicados

resultados,

ape-Bas artigos

com analises

e conc1us<>es. A linguagem

usada

para programa<;ao

da maquina

EM-4

e

D F C J J

[221,

uma

versao

de C com caraderlsticas

de atribuic;ao

unica

e sem

0

conceito

de ponteiros.

As pesquisas

realizadas

COIn

°

EM-4 originaram

ainda

outras

ar-quiteturas

(EM-X e EM-5)

[23]. Estas

arquite1uras

nao serao abordadas

por este trabalho,

ja que nao possuem

nenhuTTl mecanismo

especial

Clljo conceito

sera usado

neste

trabalho.

o

C o n c e it o d e

M

a c r - o - D a t a f lo 'lJ l

o

modelo

m acT'O -dala.flow e

baseado

no conceito

de arcos fortemente

conectados.

Est a

(35)

C o n s id e r a < ;o e s F in a is e S in te s e d o C a p itu lo

I

r'

t- :)

r ~

C LJ

-

c:

.

D

.1 ,

•..•.

f'lt->\

IO TECA

II

p ,",,:t-l \1 I

C ()

,.0 t J ._

(36)

grarnador

df'vf' con lwcf'r caract

f'r1st icas arquitf't

urais

da maquma

qUf' f'sta

1rabalhando

para

podf'r

f'xplorar

adf'quadamente

todos

os seus recursos

de paralelismo.

N

a segllnda,

o programador

df'ixa

ao compilador

a t arefa

de paralelizar

Sf'U c{>digo.

Problemas

comuns

existem

nas

duas

categorias

de linguagens.

0 principal

esta

no

fat

0

df'stas

linguagens

poss1l1rern

carader1sticas

f'speciais

que as diff'rem

das linguagens

imperativas

usadas

em maquinas

v o n f V t l 1 m a n n .

Estas

carader1sticas

tornam

diffcil

a

tarera

df' migrar

pacoks

de sof1warf' j3 prontos

para

estas

linguagens,

alern df' dificultar

a popularizac;ao

pela

"dificllldadf'''

na forma

de programac;ao.

Vma

possibilidade,

apesar

df' Sf'r apenas

eSTwcula1iva

e nao ter sido estudada

por f'stf' 1rabalho,

seria

0 uso de

pr~-compiladorf's

para

mapear

pacotes

em linguagcm

convencional

para

linguagem

funcional

e ent ao, usar compiladoH-'s

para

mapear

de linguagem

funcional

para

llTna linguagern

com

caracter1sticas

de linguagem

paralela.

Divf'rsas

propostas

e irnplementac;<->f's a Ouxo de dados

foram

H'alizadas

desdf' meados

da d~cada

df' 1970.

A arquitet

ura da

M F D M

foi llTna das priTTlf'iras a ser f's1udadas.

As

li<J)f's aprendidas

com a implementa<,;ao

desta

arquitetura

e da arquitetura

da :-"fTTDA,

nor1eararn

0

desenvolvimenio

da arquiidura

da Monsoon

no MIT.

A Monsoon

elirninou

o emparelharrlf'nto

associat ivo criando

0

conceit

0

de

Explicit

Toktn

SlO Tt

ou

"arrnaZf'na-mento

explfcito

de fichas"

(armazenamento

virtual).

Para

implemeniar

as inova<,;(ws propostas

pelo modelo

ETS,

foi criado

0

concf'it

0

df'

lhnad.

Conceitualmente,

urn

IhTtad~

urn bloco de d>digo cuja dependencia

de dados

entre

as ins t f1I<,;<'ws

que

0

cornp<->ee rnui

t

0

f~Strei ia.

0 esca lonarnen to de llTn

lh Ttad

para

eXf'cuc;ao

e

feit

0

assirn

que a execu<,;ao do

IhTtad

terrninf'

no processador.

Est (' eS<J11f'rna

(37)

Df'vi<lo 3 <lificul<la<lf' <If' prf'Vf'r arc os dinamicos

f' ao maTWaTTlf'nto f'st<itico df'

t h n r u ! s

nos elementos

de procestarnento,

surgiu

a ideia de suspender

urn

t h n a r l

quando

este

neces-site df' dados

nao arrnazena<los

localmente.

Quando

isto oconf'.

outro

t h T 'f : r u !

e

f'scalonado

para

exec1HJio

evitando

que

0

elemento

de procestarnento

ftque ocioso

enquanto

espera

pela

chegada

do dado.

Est e e

0 conceito

de

r T lu llit h T 'f : r u !

f' a arquit etura

*T

implf'TT1ent a

este conceito.

No rnodf'lo

<If'

T T lu llit h n ( J ( L

0

particionamento

do grafo

t~m

t h n a r h

e

feit

0

Twlo

com-pilador.

0 criterio

ut ilizado

para

estf' part icionament

0

torna

crHica

a execll<;ao

de 1lTII

programa,

visto

que Sf'

0 particionaTTlf'nto

nao

for adequado.

a latencia

gerada

pe]a

de-pendencia

df' dados

entre

cada

t h n : a r l

pode

degradar

a f'xecu<;ao

do programa.

Uma

maneira

de minlmizar

esta

dependencia

e utilizar

0

conceito

de "bloco

fortemente

conec-tado".

Dest a forma

urn grafo

e particionado

ern blocos

forteTTlPnte conectados,

rnini-mizando

a dependencia

entre

cada

bloco.

Este

concf'ito

foi desenvolvido

no .Japao

e e

conhecido

como

T f U lc m - r la t a I lo w .

Os diversos

grupos

de pesquisa

apresentaram

poucos

resultados

praticos

sobrf' as

ar-quiteturas

a Ouxo de dados

estudadas.

Geralmente

os artigos

sobre

uma

detenninada

ar-quitetura

apenas

apresentam

esta

arquitetura

e discorrem

subre suas principais

inova<./>es

e propostas

para

resolver

problemas

ate

enlao

conhecidos.

Artigos

que

apresentam

[ t '

-sultados

de

. , ; p u : r l 'l l p

e oCllpa<;ao

de recursos

do sist ema

est Ildado

sao Hmito

raros.

A

prf'OCllpa<;ao comllrn

das principais

implementa<,;<>es a OllXO de dados

foi ser capaz

de

re-solver

problemas

gerf'ricos.

NenhuTTla das

arquiteturas

apresentadas

neste

capItulo

toi

desenvolvida

com a finalidade

de ser dedicada

~l

resolu<;ao

de UTn deterrninado

problema

(38)

de dados ainda nao

e

uma realidade.

A

medida que a demanda por maquinas mais rapidas

lF S C ·U S P

S E R " ' C O D E B I B l I O T E C , , " • .

(39)

C a p i t u l o

I I

A

A r q u i t e t u r a

a F l u x o

d e D a d o s W o l f

2 . 1

I n t r o d

u~ao

Este capItulo apresenta a arquitetura

a fluxo de dados \Volf e discute aspectos gerais

da implementac;ao de cada unidade (0 termo

u n i d a d e

sera. usado para designar qualquer

parte da arquitetura:

nao necestariamente

referindo-se

a

Unidade Funcional: que

repre-senta apenas uma das varias unidades que compoem a arquitetura

Wolf) que a compoe.

As unidades descritas neste capitulo fmam implementadas usando a linguagem orientada

a objetos C++ eo conjunto destas unidades denominaremos de Simulador da Arquitetura

Wolf (Saw).

Apresenta tambem tres linguagens de alto nivel elaboradas corn

0 intuito de facilitar a

programaC;ao de computadores paralelos:

D a t a

P a r a l l t l

C

E x t w s i o n s

(DPCE):

H i g h P t T

-f o r m a n c t

F O R T R A N

(HPF) e

S t r t a m s

a n d

I t t r a t i o n s

i n

a S i n g l t

A s s i g n m w t

L a n g u a g t

(SISAL). As duas primeiras linguagens (DPCE e HPF) SaGapresentadas

apenas a titulo

ilustrativo: ja que nao

e

objetivo deste trabalho fazer urn tratado sobre linguagens de

pro-gramaC;ao paralela.

A linguagem SISAL e apresentada

corn urn pouco mais de detalhes

(40)

serem c.ompilados para os testes que serao realizados.

Finalmente,

0 processo de compilac;;aousado para gerar os programas utilizados pelo

simulador para os testes sao apresentados.

Neste processo, um program a SISAL

e

compi-lado num grafo a ftuxo de dados. Este grafo

e

carregado diretamente no simulador para

investigac;;aodo comportamento

da arquitetura.

2 . 2

Defini~ao

d a A r q u i t e t u r a W o l f

A arquitetura

a fluxo de dados Wolf

e

baseada no modelo de fluxo de dados dimimico

com granulosidade

variavel [25]. A Figura 2.1 apresenta sua estrutura.

A arquitetura

'VoIf visa resolver alguns problemas encontrados em arquiteturas

baseadas no paradigma

de ftuxo de dados tais como:

Estes e outros problemas foram identificados nas pesqUlsas anteriores de fluxo de

dados realizada nos diversos grupos de pesquisa, tal como discutido anteriormente

neste

trabalho.

2 . 3

F u n c i o n a m e n t o d a A r q u i t e t u r a W o l f

o

funcionamento de uma arquitetura

a fluxo de dados

e

controlado por fichas. Vma

ficha represent a urn dado no arco do grafo de dependencia sob interpretac,;ao. Fichas saD

(41)

\~ [\1 0 R L \ D l r\STI{I·COI.S

(\11,

:V1E:V101{IA DE

r\STI,ITOLS ( \1 1 ;

j

Cma instruc;ao

proliferate

gera um

stream

de fichas dependendo

do valor de um de seus operandos .

.,'.

L

usada para traramento

de vetores.

1\0 conjunto

de instruc;oes llsados pdo

simulador.

cxistem

tres

(42)

numa

LTnidade Funcional

por urn periodo

de tempo

muito

maior que as outras

instrU<;oes: geralmente

produzindo

muiias fkhas.

Isto geralmeuie

afeta negaiivamenie

0

funciollarnellia

e u equilibria de qualquer

multicomputador

.

(43)

distin<;ao entre elas) tern a informa<;ao de que urn dado no

e

parte de uma cadeia. Quando

urn pacote executavel de uma cadeia

e

produzido, a Memoria de Instru<;OeslTlICla,por

conta propria,

urn cicIo de busca usando

0 endere<;o de destino do pacote executavel

produzido como endere<;o de busca.

Desta forma, quando a Vnidade Funcional termina

0 consumo do pacote executavel

anterior, urn novo pacote executavel esta em condi<;ao de ser produzido pe1a Memoria

de Instru<;oes. Este novo pacote executavelusara

os resultados intermediarios do pacote

executa vel anterior como entrada (resultados que estao armazenados nos registradores da

V

nidade Funcional correspondente).

0 Capitulo 3 detalha este mecanismo.

Vma ou mais unidades de Memoria de Estruturas

[26]estao coneetadas entre as chaves

de Distribui<;ao e Coleta. A Memoria de Estruturas

e

responsavel pelo arrnazenamento de

dados estruturados

(vetores e matrizes).

Esta unidade aloca espa<;osob demanda e possui

urn mecanismo de contagem de referencias que permite a libera<;ao do espa<;o alocado

automaticamente.

As opera<;oes de leitura e escrita podem ser executadas em qualquer

ordem, pois a Memoria de Estruturas

consegue armazenar internamente

os pedidos de

leitura para os dados ainda nao produzidos

( I - S tr u c tu r e

[ 1 2 ] ) .

A Vnidade de Controle de Paralelismo [27] controla a quantidade de processos ativos

na maquina.

E

esta unidade que gerencia a utiliza<;ao de "nomes de ativa<;ao" imp

lemen-tando

0 n : c y c l i n g .

Esta unidade foi parcialmente implementada no sirnulador mas nao foi

utilizada para obten<;ao dos resultados desta tese, visto que nao foram implementadas as

(44)

2 . 4

U n i d a d e s d a A r q u i t e t u r a W o l f I m p l e m e n t a d a s n o

S i m u l a d o r

SERVICO

DE

BIBllOTECA

•

(45)

I

______________________________

l~~ .

_ t _

'

I

U nidade de

~

CodificilCao de

I

Pr

I

••

ograma

I_ ~ -

I

I---r

---r

~CC

~Out

I

(46)

Cnidark dr

Connole e

(47)

, r c...."

L : ('

P

~,~

~

It'll

G

0 n

I,

5

I,

B

t.

I ~) T

t'

C A

iii

(48)

correspondente.

Se a safda estiver

ocupada

podern

()Correr duas possibilidades

de-pendendo

do destino

da ficha.

Se a ficha se destinar

ao MES~ a UDisF aguarda

que

esia llTlidade fique

disponfve1.

Tsto

e

feito devido

ao pequeno

mlmero

de fichas que

san destinadas

a esta unidade.

Se a ficha se destinar

it

Mernoria

de Dados.

a UDisF

a envia para

a Fila de Fichas

(descrita

na se<;ao 2.4.7).

Quando

Ulna ficha

e

enviada

corn sucesso~ a UDisF

envia

it

uca

uma mensagem

para que esta providencie

uma

nova ficha.

A Mem()ria de Dados (MemDad)

e

responsavel

pelo emparelhamento

e armazenamento

de fichas

destinadas

a opera<;Oes diadicas.

As fichas referentes

a opera<;oes monadicas

passam

COIn urn tralamento

mfnimo

pelas unidades

da l'vlemDad.

A "MemDad possui uma

memoria

RANI para

arrnazenar

fichas que estao esperando

a parceira.

o

mlmero

de

fichas

arrnazenadas

nesta

unidade

fornece

uma

medida

para

a

de-pendencia

de dados

do algoritmo

usado.

Por exemplo~ se ern urn determinado

rnomenlo

durante

a execu<;ao de urn prograrna

0 mlmero

de fichas nesta unidade

corne<;ar a <TeSCeL

pode-se

afirmar

que

0 ramo

do grafo que est a sendo

executado

esta gerando

fichas para

opera<;oes diadicas

cujo segundo

operando

nao esta ainda

disponfve1.

Quando

ocorre

este

tipo

de situa<;ao~ costurna-se

dizer

que as fichas produzidas

san de "vida

longa".

Se a

ocupa<.;ao da unidade

come<.;a a diminuiL

exisiem

dependencias

de dados sendo resolvidas

e os resultados

produzidos

nao estiio gerando

nova dependencia~

rnas sim ajudando

na

diminui<.;ao desta.

(49)

I I I I I I I I I I I

' -J

I

Armazenarnento

I

de Dados

I

~

I

1,

! ,

I

~I

I

(50)

,

envia para a DE. Se nao exisiir ficha armazenada no enderec;o: a

M A D

envia uma

(51)

Yiemona oe

Nmazenamen[o

Lnidade de

l)C{;odificac3o

de Ficha,

t:nidade de

(52)

continuar sendo executado seqiiencialmente.

Nestes casos a UCS envia como parte

da mensagem para a Memoria de Armazenmento de InstnI~oes a identifica~ao de

qual dos ramos do grafo devera ser executado seqiiencialmente.

M e m o r i a

d e A r m a z e n a m e n t o

d e

Instru~oes

-

M A l :

A MAl armazena

0 program a

a ser executado.

Quando a MAl recebe da UDecF

0 enderec;o da instru~ao: ela

executa uma leitura naquele endere~o enviando seu conteudo para a Unidade de

Codifica~ao de Fichas e apenas os endere~os de destino dos resultados

que serao

produzidos

com a execuc;ao da instru~ao que esa sendo tratada

para a UCS. Ao

receber uma mensagem da UCS: a MAl repete a opera~ao descrita neste item.

U n i d a d e

d e

Codifica~ao

d e F i c h a s - U C o d F :

A UCodF recebe da UDecF os dados

correspondentes

a

instnI~ao a ser executada.

Recebe tambem da MAl a instru~ao

correspondente.

A UCodF constroi e envia entao urn pacote contendo est as

in-forma~oes para a Unidade Funcional (descrita na se~ao 2.4.8).

A UCodF possui

urn mecanismo de sincroniza~ao que faz

0 controle da chegada das duas partes do

pacote que e enviado para a Unidade Funcional.

2 . 4 . 5

A

M e m o r i a d e

Instru~oes

E x t e r n a

A Memoria de InstnI~oes Externa

(MIO) e responsavel por verificar se os dados que

chegam sao destinados a uma instruc;ao de tratamento

de vetoresfescalares ou controle de

atividade da maquina. Instru~Oes de tratarnento escalar sao instru~oes que san executadas