Laboratoire

de

l'Informatique

du

Parall?lisme

Ecole

Normale

Sup?rieure

de

Lyon

Unit

de

recherche

associ?e

au

CNRS

n

Utilisation

de

processus

l?egers

pour

l'ex

ecution

de

programmes

a

parall?elisme

de

donn?ees

etude

exp?erimentale

Christian

Perez

Avril

Research

Report

No

Ecole

Normale

Sup?rieure

de

Lyon

Adresse

lectronique

lip@lip.ens-lyon.fr

T?l?phone

-LRB-

-RRB-

T?l?copieur

-LRB-

-RRB-

All?e

d'Italie

Lyon

Cedex

France

Utilisation

de

processus

l?egers

pour

l'ex

ecution

de

programmes

a

parall?elisme

de

donn?ees

etude

exp?erimentale

Christian

Perez

Avril

Abstract

This

paper

studies

the

use

of

threads

to

support

the

execution

of

data-parallel

programs

The

overhead

induced

by

the

multithreaded

environment

is

experimentally

studied

global

synchronization

thread

creation

communication

thread

migration

We

propose

some

simple

criteria

to

determine

the

right

size

of

threads

with

respect

to

the

expected

overhead

We

use

the

multithreaded

environment

which

provides

thread

migration

facilities

R?esum?e

Ce

rapport

pr?esente

une

etude

de

quelques

aspects

importants

des

processus

l?egers

pour

leur

utilisation

a

l'ex

ecution

de

programmes

a

parall?elisme

de

donn?ees

La

surcharge

de

l'environnement

d'ex

ecution

le

co

ut

des

synchronisations

globales

de

cr?eation

de

processus

l?egers

le

comportement

des

processus

l?egers

vis

a-vis

des

communications

ainsi

que

le

co

ut

de

la

migration

des

processus

l?egers

sont

etudi?es

Nous

en

d?eduisons

des

crit?eres

simples

pour

la

d?etermination

de

la

bonne

taille

des

processus

l?egers

en

relation

avec

le

surco

ut

engendr?e

L'environnement

d'ex

ecution

choisi

est

car

il

int?egre

la

migration

de

processus

l?egers

Mots-cl

es

Langages

a

parall?elisme

de

donn?ees

compilation

environnement

d'ex

ecution

multithread

processus

l?egers

etude

exp?erimentale

des

co

uts

Utilisation

de

processus

l?egers

pour

l'ex

ecution

de

programmes

a

parall?elisme

de

donn?ees

etude

exp?erimentale

Christian

Perez

y

Avril

Table

des

mati?eres

Introduction

Parall?elisme

de

processus

lourds

et

l?egers

Surcharge

g?en?er?ee

par

l'environnement

de

processus

l?egers

Parall?elisme

de

processus

Parall?elisme

de

threads

Premi?ere

exp?erience

programme

de

test

et

threads

Seconde

exp?erience

co

ut

de

gestion

des

threads

Discussion

Conclusion

Synchronisations

globales

de

processus

l?egers

Le

probl?eme

L'exp

erience

synchronisation

intra-processus

Discussion

synchronisation

ou

cr?eation

de

threads

Conclusion

Gestion

des

communications

Description

de

notre

exp?erience

Les

communications

intra-processus

Les

communications

inter-processus

Conclusion

Migration

et

processus

l?egers

Description

de

la

migration

de

threads

Co

ut

de

la

migration

de

threads

Conclusion

Conclusion

y

Financ?e

par

le

projet

CNRS-INRIA

ReMaP

Introduction

Dans

la

recherche

de

haute

performance

en

calcul

le

langage

a

parall?elisme

de

donn?ees

High

Performance

Fortran

-LRB-

HPF

-RRB-

-LSB-

-RSB-

semble

amen?e

a

jouer

un

r

ole

important

De

nombreuses

recherches

se

sont

attaqu?ees

aux

probl?emes

de

trouver

un

ordonnancement

et

un

placement

statiques

performants

-LSB-

-RSB-

Cependant

il

semble

int?eressant

d'ins

erer

aussi

des

possibilit?es

d'

equilibrage

de

charge

a

HPF

En

effet

les

travaux

de

G.

Utard

et

G.

Cuvillier

-LSB-

-RSB-

-LRB-

-LSB-

-RSB-

pour

une

version

plus

d?etaill?ee

-RRB-

sur

l'int

egration

d'un

module

d'

equilibrage

de

charge

au

code

produit

par

le

compilateur

C

-LSB-

-RSB-

de

l'Universit

e

du

New

Hampshire

sont

prometteurs

Comme

C

HPF

est

un

langage

a

parall?elisme

de

donn?ees

et

donc

suivant

la

owner

computes

rule

les

calculs

se

font

l?a

o?u

se

trouvent

les

donn?ees

Par

cons?equent

equilibrer

la

charge

revient

a

equilibrer

les

donn?ees

La

notion

de

processeur

virtuel

dans

HPF

permet

de

consid?erer

qu

equilibrer

la

charge

d'un

programme

HPF

revient

a

faire

comme

dans

le

cas

de

C

de

l'

equilibrage

de

processeurs

virtuels

Il

faut

pour

cela

bien

s

ur

disposer

d'un

nombre

de

processeurs

virtuels

suffisamment

grand

Le

probl?eme

auquel

ce

rapport

apporte

des

el?ements

de

r?eponse

est

d'estimer

les

avantages

et

les

inconv?enients

a

l'utilisation

de

processus

l?egers

a

l'ex

ecution

de

programmes

a

parall?elisme

de

donn?ees

style

HPF

En

effet

nous

voudrions

d?eterminer

si

un

code

multithread

est

comp?etitif

par

rapport

au

parall?elisme

de

processus

classique

Nous

nous

attendons

a

avoir

une

surcharge

due

a

la

gestion

des

processus

l?egers

Mais

nous

esp?erons

que

d'une

part

elle

ne

sera

pas

trop

grande

et

que

d'autre

part

cette

surcharge

pourra

au

moins

etre

en

partie

masqu?ee

par

un

meilleur

recouvrement

des

communications

par

les

calculs

En

effet

nous

d?esirons

introduire

de

l'

equilibrage

de

charge

dans

HPF

mais

sans

alt?erer

sensiblement

les

performances

de

HPF

pour

du

code

r?egulier

Unit?e

de

la

migration

Le

premier

probl?eme

est

de

savoir

sous

quelle

forme

migrer

les

donn?ees

d'un

processeur

virtuel

En

effet

nous

pouvons

migrer

seulement

les

donn?ees

les

donn?ees

et

le

code

-LRB-

i.e.

un

processus

-RRB-

ou

les

donn?ees

et

la

pile

d'ex

ecution

-LRB-

i.e.

un

processus

l?eger

ou

thread

-LSB-

-RSB-

-RRB-

-LCB-

La

migration

de

processus

est

la

plus

facile

a

mettre

en

place

En

effet

les

compilateurs

actuels

comme

Adaptor

-LSB-

-RSB-

ou

Portland

Group

HPF

-LSB-

-RSB-

g?en?erent

un

parall?elisme

de

processus

En

ajoutant

un

syst?eme

de

migration

de

processus

comme

MPVM

-LSB-

-RSB-

ou

Cocheck

-LSB-

-RSB-

nous

obtenons

la

capacit?e

de

migration

Malheureusement

cette

approche

n'est

pas

compatible

avec

la

recherche

de

haute

performance

pour

deux

raisons

principales

Tout

d'abord

la

migration

d'un

processus

est

une

op?eration

extr

emement

co

uteuse

car

la

taille

d'un

processus

se

mesure

en

millions

d'octets

Ensuite

le

parall?elisme

de

processus

n'est

gu?ere

performant

du

fait

du

co

ut

elev?e

des

changements

de

contexte

dans

un

syst?eme

Unix

Par

cons?equent

le

nombre

de

processus

pr?esents

sur

un

m

eme

processeur

est

fortement

limit?e

et

donc

le

d?ecoupage

du

domaine

est

fait

a

un

tr?es

gros

grain

-LCB-

La

migration

de

donn?ees

est

parfaite

du

point

de

vue

finesse

de

l'

equilibrage

de

charge

En

effet

il

est

possible

de

calculer

un

equilibrage

de

charge

dont

l'ordre

de

grandeur

de

la

pr?ecision

est

la

donn?ee

Malheureusement

le

prix

a

payer

est

la

perte

de

la

simplicit?e

des

fonctions

de

parcours

du

domaine

De

surcro

t

le

domaine

de

recherche

est

grand

La

recherche

dynamique

d'une

bonne

solution

dans

cet

espace

demande

donc

un

temps

non

n?egligeable

-LCB-

Les

processus

l?egers

se

placent

entre

les

deux

Par

rapport

aux

processus

ils

ont

l'avantage

d'

etre

beaucoup

moins

co

uteux

a

migrer

car

seules

les

donn?ees

et

la

pile

migrent

De

plus

le

temps

de

changement

de

contexte

est

de

plusieurs

ordres

de

grandeur

plus

petit

Ces

caract?eristiques

font

que

leur

granularit?e

est

plus

petite

que

celle

des

processus

mais

n'est

pas

aussi

fine

que

celle

de

l'approche

donn?ee

Une

etude

d?etaill?ee

sur

des

avantages

et

des

inconv?enients

de

ces

trois

approches

peut

etre

trouv?ee

dans

-LSB-

-RSB-

R?egularit?e

et

granularit?e

Notre

but

est

d'introduire

de

la

r?egularit?e

au

niveau

du

traitement

des

donn?ees

Cela

revient

a

augmenter

la

granularit?e

de

l'application

D'une

granularit?e

au

niveau

de

la

donn?ee

nous

voulons

passer

a

une

granularit?e

sup?erieure

Nos

motivations

sont

les

suivantes

-LCB-

La

r?egularit?e

des

donn?ees

est

primordiale

pour

avoir

un

parcours

efficace

des

donn?ees

En

effet

elle

permet

de

limiter

le

co

ut

du

contr

ole

de

flot

qui

peut

vite

devenir

important

C'est

en

partie

pourquoi

la

pr?ecision

des

d?ecoupes

est

rarement

au

niveau

de

la

donn?ee

C'est

le

cas

des

bissections

r?ecursives

des

partitions

rectilin?eaires

-LSB-

-RSB-

de

la

partition

-LSB-

-RSB-

etc.

-LCB-

Une

granularit?e

au

niveau

de

la

donn?ee

appara

t

comme

inutile

car

la

d?ecision

de

r?e?equilibrer

est

prise

lorsque

le

d?es?equilibre

est

suffisamment

grand

pour

que

le

gain

esp?er?e

d?epasse

le

co

ut

des

communications

Les

temps

mis

en

jeu

sont

en

g?en?eral

beaucoup

plus

grands

que

celui

du

calcul

sur

une

donn?ee

-LCB-

Les

communications

etant

encore

co

uteuses

il

appara

t

plus

profitable

de

r?eduire

les

communications

que

de

chercher

un

equilibrage

parfait

des

donn?ees

au

d?etriment

d'un

co

ut

de

communication

exorbitant

La

r?egularit?e

des

blocs

est

un

moyen

qui

permet

de

calculer

assez

rapidement

et

pr?ecis?ement

le

co

ut

en

communication

d'un

bloc

de

donn?ees

Elle

permet

donc

de

choisir

un

placement

qui

minimise

le

temps

de

calcul

plus

le

temps

de

communication

-LCB-

En

restreignant

l'espace

de

recherche

la

probabilit?e

de

trouver

un

bon

placement

en

un

temps

r?eduit

augmente

Il

s

av?ere

donc

qu'une

granularit?e

sup?erieure

a

la

donn?ee

est

int?eressante

Cependant

la

gestion

a

la

main

des

blocs

el?ementaires

de

donn?ees

-LRB-

i.e.

une

partie

contigu?e

d'un

tableau

-RRB-

appara

t

assez

lourde

En

effet

il

faut

mettre

en

place

un

m?ecanisme

de

gestion

des

d?ependances

entre

blocs

sur

le

m

eme

processus

Or

un

sur-ensemble

des

fonctionnalit?es

utiles

est

pr?esent

dans

les

processus

l?egers

Nous

choisissons

donc

d'encapsuler

un

bloc

de

donn?ees

r?egulier

dans

un

thread

Compilation

HPF

et

processus

l?egers

Nous

choisissons

les

threads

pour

les

raisons

suivantes

les

environnements

de

processus

l?egers

arrivent

a

maturation

gr

ace

notamment

a

la

norme

POSIX

-LSB-

-RSB-

ce

qui

leur

conf?ere

une

stabilit?e

suffisante

pour

etre

utilis?es

sereinement

-LSB-

-RSB-

la

migration

de

processus

l?egers

appara

t

un

niveau

ad?equat

pour

notre

approche

l'efficacit

e

de

certains

environnements

devient

satisfaisante

Enfin

cette

solution

a

l'avantage

d'une

plus

grande

simplicit?e

d'impl

ementation

pour

une

performance

qui

devrait

etre

bonne

Nous

avons

choisi

l'environnement

multithread

-LSB-

-RSB-

car

il

remplit

ces

crit?eres

en

plus

celui

d'avoir

ses

sources

disponibles

Les

threads

commencent

a

etre

utilis?es

pour

la

compilation

de

programme

HPF

mais

seulement

dans

le

but

d'avoir

un

meilleur

recouvrement

calcul

communication

Dans

-LSB-

-RSB-

les

threads

sont

utilis?es

afin

d'avoir

un

thread

de

r?eception

de

messages

qui

au

travers

d'un

thread

de

gestion

donne

du

travail

au

thread

de

calcul

quand

toutes

les

donn?ees

relatives

a

un

bloc

de

travail

sont

pr?esentes

Dans

-LSB-

-RSB-

l'approche

qui

consiste

a

avoir

un

parall?elisme

de

threads

a

l'int

erieur

d'un

processus

est

etudi?ee

Cependant

ces

deux

papiers

ne

m?enent

pas

une

etude

pr?ecise

sur

les

diff?erents

co

uts

des

threads

intervenant

a

l'ex

ecution

de

leurs

programmes

Plan

du

travail

Le

but

de

ce

papier

est

d'

etudier

les

diff?erents

aspects

des

threads

Ainsi

dans

la

section

suivante

nous

estimerons

la

surcharge

g?en?er?ee

par

l'utilisation

de

threads

dans

le

cas

d'un

programme

de

calcul

simple

Nous

etudierons

dans

la

section

la

question

de

synchronisation

globale

de

threads

et

de

temps

de

cr?eation

d'un

thread

Ensuite

dans

la

section

nous

introduirons

les

communications

entre

threads

Nous

aborderons

la

question

de

la

migration

de

threads

dans

la

section

Parall?elisme

de

processus

lourds

et

l?egers

Le

but

de

cette

section

est

d'

etudier

le

comportement

d'un

programme

multithread

sans

communication

Nous

regarderons

plus

pr?ecis?ement

la

surcharge

engendr?ee

par

l'introduction

des

threads

par

rapport

au

m

eme

programme

s?equentiel

et

parall?elis?e

par

Adaptor

-LSB-

-RSB-

En

effet

nous

voudrions

essayer

de

s?eparer

la

surcharge

due

a

la

parall?elisation

de

la

surcharge

due

aux

threads

Nous

comparerons

d'abord

diff?erentes

approches

afin

d'estimer

le

co

ut

de

la

parall?elisation

Ensuite

nous

consid?erons

le

parall?elisme

de

processus

pour

nous

donner

un

point

de

r?ef?erence

Enfin

nous

nous

attaquerons

au

parall?elisme

de

processus

l?egers

Nous

consid?erons

deux

classes

de

machines

des

stations

Sparc

ELC

et

des

stations

Sparc

afin

d'avoir

une

id?ee

de

l'

evolution

des

r?esultats

sur

des

machines

plus

ou

moins

puissantes

Les

Sparc

sont

environ

fois

plus

rapides

que

les

Sparc

ELC

Programme

de

test

Le

programme

de

base

pour

cette

section

est

un

programme

de

calcul

sans

communication

dont

le

coeur

calculatoire

est

constitu?e

de

deux

nids

de

boucles

de

profondeur

Afin

d'

eviter

les

d?ebordements

de

calcul

et

les

optimisations

trop

pointues

des

compilateurs

-LRB-

comme

la

suppression

de

code

inutile

-RRB-

le

premier

nid

de

boucle

calcule

A

-LRB-

I

J

-RRB-

A

-LRB-

I

J

-RRB-

-LRB-

T

-RRB-

A

-LRB-

I

J

-RRB-

T

sur

un

tableau

de

taille

de

flottants

en

double

pr?ecision

pendant

it?erations

d?ecrites

par

la

variable

T

Pour

les

m

emes

raisons

le

deuxi?eme

calcule

B

-LRB-

I

J

-RRB-

A

-LRB-

I

J

-RRB-

T

B

-LRB-

I

J

-RRB-

sur

un

domaine

de

pendant

it?erations

Les

valeurs

et

ont

et?e

choisies

exp?erimentalement

pour

eviter

les

d?ebordements

Notre

but

est

seulement

d'occuper

le

processeur

Choix

du

temps

mesur?e

Nous

avons

choisi

de

mesurer

les

temps

r?eels

pour

pouvoir

tenir

compte

des

temps

de

communication

et

du

temps

pass?e

par

nos

programmes

dans

le

noyau

du

syst?eme

Unix

Par

cons?equent

tous

les

temps

report?es

sont

l?eg?erement

perturb?es

par

le

syst?eme

processus

syst?emes

parasites

changements

de

contexte

entre

processus

etc.

Surcharge

g?en?er?ee

par

l'environnement

de

processus

l?egers

L'exp

erience

description

et

mesures

Afin

de

mesurer

les

co

uts

induits

par

chaque

ex?ecution

nous

mesurons

les

performances

sur

une

machine

inoccup?ee

avec

un

processus

contenant

au

plus

un

processus

l?eger

de

calcul

Les

exp?eriences

ci-dessous

sont

ex?ecut?ees

sous

Solaris

Les

mesures

n'int

egrent

pas

les

co

uts

d'initialisation

des

programmes

La

version

Adaptor

est

la

version

HPF

de

la

version

Fortran

Les

versions

sans

thread

et

avec

threads

utilisent

la

m

eme

routine

de

calcul

qui

est

la

version

C

du

code

Fortran

produit

par

Adaptor

La

diff?erence

entre

ces

versions

est

que

la

deuxi?eme

est

ex?ecut?ee

dans

l'environnement

Adaptor

transforme

le

tableau

bidimensionnel

en

un

tableau

unidimensionnel

Par

cons?equent

les

acc?es

au

tableau

A

-LRB-

i

j

-RRB-

sont

de

la

forme

-LRB-

A

j

S

i

C

-RRB-

avec

A

la

base

du

tableau

S

le

pas

et

C

le

d?ecalage

a

l'origine

Seul

la

version

Fortran

fait

exception

et

utilise

un

tableau

bidimensionnel

Langage

Temps

sur

ELC

-LRB-

s

-RRB-

Temps

sur

Sparc

-LRB-

s

-RRB-

Fortran

Adaptor

C

sans

thread

C

thread

-LRB-

sans

preemption

-RRB-

C

thread

-LRB-

avec

preemption

courte

-RRB-

C

thread

-LRB-

avec

preemption

longue

-RRB-

Tab

Temps

d'un

noyau

de

calcul

pour

diff?erents

compilateurs

et

diff?erents

environnements

d'ex

ecution

Analyse

des

r?esultats

Comme

le

montre

le

tableau

l'emploi

d'un

thread

avec

ou

sans

pr?eemption

induit

une

surcharge

de

sur

ELC

et

de

sur

Sparc

Cependant

les

effets

de

la

pr?eemption

sont

tr?es

faibles

Les

auteurs

de

estiment

le

co

ut

de

la

pr?eemption

a

moins

de

ce

qui

est

en

accord

avec

nos

r?esultats

La

version

Adaptor

est

sur

ELC

et

sur

Sparc

plus

rapide

que

la

version

Fortran

avec

le

m

eme

compilateur

et

les

m

emes

options

de

compilation

La

cause

doit

etre

recherch?ee

dans

le

fait

qu'Adaptor

lin?earise

les

tableaux

En

conclusion

un

code

Adaptor

multithread

sur

Sparc

devrait

etre

plus

lent

que

le

m

eme

code

non

multithread

mais

aussi

rapide

que

du

code

Fortran

Le

surco

ut

semble

acceptable

Il

trouve

ses

sources

d'une

part

dans

le

m?ecanisme

de

pr?eemption

et

d'autre

part

dans

les

perturbations

du

thread

de

communication

En

effet

emploie

des

appels

de

proc?edures

distantes

l?eg?eres

-LRB-

LRPC

-RRB-

pour

communiquer

et

utilise

un

thread

comme

handler

pour

activer

l'appel

de

proc?edures

distantes

Ce

thread

teste

d?es

qu'il

peut

si

des

messages

sont

arriv?es

et

consomme

donc

un

peu

de

ressource

processeur

Parall?elisme

de

processus

L'exp

erience

description

et

mesures

Les

threads

sont

par

d?efinition

plus

l?egers

que

les

processus

Afin

d'avoir

un

rep?ere

de

co

ut

nous

allons

mesurer

maintenant

le

co

ut

du

parall?elisme

de

processus

pour

un

m

eme

programme

de

calcul

Le

programme

de

test

est

celui

utilis?e

pr?ec?edemment

avec

une

distribution

des

donn?ees

de

type

-LRB-

BLOCK

BLOCK

-RRB-

Dans

cette

exp?erience

nous

faisons

varier

le

nombre

de

processus

sur

une

machine

Dans

la

version

avec

threads

chaque

processus

contient

au

plus

un

thread

de

calcul

et

utilise

une

pr?eemption

courte

Les

r?esultats

sont

r?esum?es

dans

le

tableau

Nous

n'avons

pas

les

chiffres

pour

plus

de

processus

car

une

ex?ecution

a

processus

n

a

pas

et?e

possible

par

manque

de

m?emoire

Aucune

ex?ecution

n

a

g?en?er?e

d'

echange

entre

la

m?emoire

et

la

zone

de

swap

sur

le

disque

dur

Nombre

de

processus

Temps

sur

ELC

-LRB-

s

-RRB-

Temps

sur

Sparc

-LRB-

s

-RRB-

Adaptor

C

Adaptor

C

Tab

Parall?elisme

de

processus

sur

une

machine

Analyse

des

r?esultats

Le

tableau

montre

un

ph?enom?ene

a

priori

surprenant

le

temps

total

diminue

quand

le

nombre

de

processus

augmente

pour

les

processus

Adaptor

alors

que

le

temps

augmente

pour

les

processus

Comme

nous

le

verrons

par

la

suite

le

temps

des

processus

Adaptor

baisse

a

cause

des

effets

de

cache

Pour

l'instant

int?eressons

nous

au

cas

des

processus

La

raison

pour

laquelle

le

temps

augmente

pour

les

processus

vient

de

la

mani?ere

dont

est

impl?ement?ee

la

pr?eemption

-LSB-

-RSB-

Toutes

les

ms

par

d?efaut

le

processus

re?coit

un

signal

qui

arr

ete

l'ex

ecution

du

thread

courant

et

donne

la

main

a

l'ordonnanceur

c'est

la

base

du

m?ecanisme

de

pr?eemption

Or

recevoir

un

signal

signifie

faire

un

appel

au

noyau

-LSB-

-RSB-

Comme

l'ordonnanceur

Unix

est

appel?e

a

chaque

retour

du

noyau

le

processus

perd

la

main

Lorsque

le

nombre

de

processus

ou

la

fr?equence

des

signaux

augmentent

le

processeur

passe

de

plus

en

plus

de

temps

dans

le

noyau

a

effectuer

des

changements

de

contexte

de

processus

du

fait

de

l'augmentation

du

nombre

de

signaux

Par

cons?equent

le

calcul

proprement

dit

avance

moins

vite

le

temps

r?eel

total

augmente

Nous

avons

men?e

une

exp?erience

dans

laquelle

nous

avons

mesur?e

le

temps

r?eel

et

le

nombre

de

changements

de

contexte

en

fonction

de

la

tranche

de

temps

pour

une

m

eme

somme

de

travail

Les

r?esultats

sont

report?es

a

la

figure

Nous

pouvons

y

voir

tr?es

clairement

qu'une

surcharge

de

signaux

d?egrade

fortement

le

syst?eme

Le

tableau

montre

aussi

l'influence

de

la

puissance

des

machines

sur

la

pr?eemption

Ainsi

la

diff?erence

entre

et

processus

est

de

sur

ELC

alors

qu'elle

n'est

que

de

sur

une

Sparc

Proportionnellement

une

ex?ecution

sur

Sparc

passe

moins

de

temps

dans

le

noyau

qu'une

ex?ecution

sur

ELC

Il

y

a

donc

un

choix

a

faire

entre

la

fr?equence

de

pr?eemption

des

threads

et

le

nombre

de

processus

par

processeur

si

nous

voulons

garder

un

m?ecanisme

de

pr?eemption

Cependant

l'int

er

et

d'un

m?ecanisme

de

pr?eemption

dans

le

cadre

de

l'ex

ecution

de

programmes

data-parall

eles

n'est

pas

clair

En

effet

comme

l'ex

ecution

est

fortement

coupl?ee

tous

les

threads

sont

oblig?es

de

progresser

ensemble

Le

changement

de

contexte

se

produit

naturellement

lorsqu'un

thread

atteint

l'une

des

nombreuses

barri?eres

de

synchronisation

Il

peut

etre

quand

m

eme

int?eressant

de

garder

la

pr?eemption

afin

de

ne

pas

p?enaliser

le

thread

de

r?eception

des

communications

et

donc

les

communications

l'ordonnanceur

de

garantit

qu'un

thread

aura

bien

la

main

de

temps

en

temps

gr

ace

a

un

syst?eme

de

priorit?es

entre

threads

Il

est

ainsi

possible

de

r?egler

via

les

priorit?es

le

d?elai

de

prise

en

compte

d'une

communication

Nous

10 100 1000

Temps

-LRB-

en

sec

-RRB-

Tranche

de

temps

-LRB-

en

ms

-RRB-

processus

10 100 1000

Nombre

de

changement

de

contextes

par

seconde

Tranche

de

temps

-LRB-

en

ms

-RRB-

Processus

Processus

Adaptor

Fig.

Temps

d'ex

ecution

et

nombre

de

changements

de

contexte

en

fonction

de

la

tranche

de

temps

pour

un

programme

qui

a

une

somme

de

travail

fixe

et

g?en?erant

processus

A

titre

de

r?ef?erence

un

programme

Adaptor

a

processus

g?en?ere

environ

changements

de

contexte

par

seconde

garderons

donc

par

la

suite

la

pr?eemption

d'autant

plus

que

son

co

ut

est

petit

pour

un

processus

par

processeur

et

que

nous

ne

consid?erons

justement

qu'un

processus

par

processeur

Parall?elisme

de

threads

Nous

allons

maintenant

nous

pencher

sur

le

cas

du

parall?elisme

de

threads

dans

la

perspective

d'une

ex?ecution

d'un

programme

data-parall

ele

Premi?ere

exp?erience

programme

de

test

et

threads

Cette

exp?erience

va

de

pair

avec

celle

de

la

section

pr?ec?edente

Nous

pourrons

ainsi

comparer

la

surcharge

du

parall?elisme

de

threads

par

rapport

au

parall?elisme

de

processus

Description

et

mesure

Nous

reprenons

le

m

eme

programme

que

pr?ec?edemment

mais

au

lieu

de

varier

le

nombre

de

processus

nous

varions

le

nombre

de

threads

a

l'int

erieur

d'un

processus

unique

Les

r?esultats

ont

et?e

regroup?es

dans

le

tableau

La

courbe

pour

diff?erentes

strat?egies

de

partition

et

pour

une

plus

grand

plage

de

threads

est

pr?esent?ee

en

figure

Analyse

des

r?esultats

Tout

d'abord

nous

remarquons

que

le

nombre

de

threads

possible

est

evidement

beaucoup

plus

grand

que

le

nombre

de

processus

Nos

exp?eriences

ont

utilis?e

jusqu

a

threads

Un

parall?elisme

de

threads

consomme

donc

beaucoup

moins

de

m?emoire

qu'un

parall?elisme

de

processus

Ensuite

comme

le

laissent

supposer

les

temps

sur

la

Sparc

la

surcharge

due

au

parall?elisme

de

threads

est

petit

Nous

obtenons

environ

le

m

eme

temps

pour

thread

que

pour

threads

Enfin

comme

le

montre

la

figure

la

chute

de

la

courbe

d?epend

tr?es

peu

de

la

forme

du

domaine

affect?e

a

chaque

thread

Cette

courbe

est

obtenue

en

faisant

varier

le

nombre

de

threads

pour

diff?erentes

partitions

La

quantit?e

de

donn?ees

n

etant

constante

un

nombre

t

de

threads

implique

une

quantit?e

Nombre

de

threads

Temps

sur

ELC

-LRB-

s

-RRB-

Temps

sur

Sparc

-LRB-

s

-RRB-

Tab

Parall?elisme

de

threads

a

l'int

erieur

d'un

seul

processus

Unix

de

donn?ees

par

thread

egale

a

n

t.

La

courbe

d?epend

donc

essentiellement

de

la

quantit?e

de

donn?ees

par

thread

C'est

donc

bien

le

signe

d'un

effet

de

cache

Les

effets

de

cache

nous

g

enent

pour

exploiter

les

r?esultats

Nous

allons

donc

faire

une

exp?erience

diff?erente

avec

deux

objectifs

Premi?erement

analyser

le

ph?enom?ene

du

cache

pour

deuxi?emement

mesurer

plus

pr?ecis?ement

le

co

ut

du

parall?elisme

de

threads

Seconde

exp?erience

co

ut

de

gestion

des

threads

Nous

avons

mis

en

evidence

dans

l'exp

erience

pr?ec?edente

les

effets

du

cache

Nous

allons

faire

une

exp?erience

afin

de

mieux

les

ma

triser

pour

estimer

le

surco

ut

li?e

aux

threads

Cette

exp?erience

ne

sera

men?ee

que

sur

une

station

Sparc

car

elle

poss?ede

un

cache

pour

les

donn?ees

et

un

cache

pour

les

instructions

contrairement

a

la

station

ELC

qui

n

a

qu'un

seul

cache

Nous

n'avons

pas

ainsi

a

estimer

la

quantit?e

d'instructions

qui

se

trouve

dans

le

cache

de

la

station

ELC

L'exp

erience

description

et

mesures

Notre

programme

consiste

en

it?erations

sur

un

tableau

a

une

dimension

de

flottants

en

double

pr?ecision

-LRB-

bits

-RRB-

Un

bloc

contigu

de

ce

tableau

est

attribu?e

a

chaque

thread

qui

calcule

ensuite

dessus

Les

r?esultats

sont

pr?esent?es

a

la

figure

Analyse

des

r?esultats

Notre

principale

hypoth?ese

pour

expliquer

la

forme

de

la

courbe

est

que

le

temps

en

fonction

du

nombre

de

threads

est

une

courbe

affine

En

effet

la

somme

de

travail

reste

constante

mais

la

surcharge

li?ee

aux

threads

augmente

La

surcharge

comprend

la

partie

contr

ole

de

flot

du

programme

qui

est

en

partie

r?epliqu?ee

sur

tous

les

threads

-LRB-

le

parcours

de

la

boucle

s?equentielle

mais

pas

le

parcours

de

la

boucle

parall?ele

qui

est

bien

distribu?e

-RRB-

ainsi

que

les

changements

de

contexte

Une

telle

surcharge

est

donc

proportionnelle

au

nombre

de

threads

Cette

hypoth?ese

se

trouve

v?erifi?ee

par

les

parties

gauche

et

droite

de

la

courbe

qui

sont

des

morceaux

de

droites

La

partie

centrale

de

la

courbe

est

due

au

cache

des

donn?ees

du

processeur

En

effet

plus

le

nombre

de

threads

augmente

plus

la

taille

des

donn?ees

par

thread

diminue

et

donc

plus

la

proportion

de

r?eutilisation

du

cache

-LRB-

cache

hit

-RRB-

augmente

C'est

la

phase

de

transition

durant

laquelle

la

proportion

de

r?eutilisation

des

donn?ees

pr?esentes

dans

le

cache

passe

de

a

10 100 1000 10000

Temps

-LRB-

s

-RRB-

Threads

R?gulier

-LRB-

-RRB-

32 64 128 256

512 1024 2048

Temps

-LRB-

s

-RRB-

Threads

Calcul

-LRB-

-RRB-

Fig.

Partition

de

donn?ees

et

effets

de

cache

Mise

en

evidence

d'un

ph?enom?ene

singulier

pour

diff?erentes

partitions

d'une

quantit?e

de

donn?ees

totale

constante

et

d'un

nombre

variables

de

threads

Nombre

de

threads

et

effets

de

cache

pour

une

quantit?e

de

donn?ees

totale

constante

Mod?elisation

de

l'exp

erience

Nous

allons

tenter

de

mod?eliser

l'exp

erience

afin

d'en

extraire

des

informations

utiles

comme

le

co

ut

par

thread

Le

temps

est

donc

une

fonction

affine

du

nombre

de

threads

t

et

de

la

taille

des

donn?ees

n.

D'

o?u

temps

-LRB-

t

n

-RRB-

-LRB-

ffi

I

-RRB-

t

I

n

-LRB-

-RRB-

avec

comme

constante

ffi

qui

est

le

co

ut

d'initialisation

du

thread

I

qui

repr?esente

le

nombre

d'it

erations

qui

mod?elise

la

surcharge

par

thread

et

par

it?eration

-LRB-

i.e.

les

changements

de

contexte

-RRB-

et

pour

le

temps

de

calcul

sur

une

donn?ee

Nous

devons

distinguer

en

fait

deux

cas

pour

Soit

le

flottant

est

dans

le

cache

processeur

-LRB-

cache

hit

-RRB-

et

nous

noterons

soit

il

est

en

m?emoire

-LRB-

cache

miss

-RRB-

et

nous

noterons

alors

La

partie

gauche

de

la

courbe

a

alors

pour

equation

temps

-LRB-

t

n

-RRB-

-LRB-

ffi

I

-RRB-

t

I

n

-LRB-

-RRB-

et

la

partie

droite

de

la

courbe

a

pour

equation

temps

-LRB-

t

n

-RRB-

-LRB-

ffi

I

-RRB-

t

I

n

-LRB-

-RRB-

La

partie

centrale

a

besoin

d'une

hypoth?ese

suppl?ementaire

Nous

supposons

en

effet

que

durant

cette

portion

le

proportion

de

cache

r?eutilisable

est

egale

a

R?eutilisation

du

cache

xB

xA

n

t

nc

-LRB-

-RRB-

o?u

-LSB-

xA

xB

-RSB-

repr?esente

le

segment

d'abscisse

de

la

partie

centrale

-LRB-

pour

nous

xA

et

xB

-RRB-

nc

est

la

taille

du

cache

et

n

t

est

la

quantit?e

de

donn?ees

affect?ee

a

un

thread

En

effet

il

faut

que

le

cache

des

donn?ees

soit

utilis?e

a

au

d?ebut

de

ce

segment

de

droite

et

a

a

la

fin

L'

equation

du

segment

de

droite

central

est

alors

temps

-LRB-

t

n

nc

-RRB-

-LRB-

ffi

I

I

l

I

-RRB-

t

-LRB-

-RRB-

avec

l

le

nombre

de

donn?ees

pr?esentes

dans

le

cache

processeur

et

le

nombre

de

donn?ees

non

pr?esentes

dans

le

cache

processeur

Les

variables

l

nc

n

et

t

sont

li?ees

par

les

deux

equations

suivantes

l

de

r?eutilisation

du

cache

taille

du

cache

xB

xA

n

t

nc

nc

-LRB-

-RRB-

et

l

n

t

-LRB-

-RRB-

L'

equation

se

r?e?ecrit

gr

ace

aux

equations

et

en

temps

-LRB-

t

n

nc

-RRB-

-LSB-

ffi

I

nc

-LRB-

-RRB-

-RSB-

t

I

n

-LRB-

-RRB-

-LRB-

-RRB-

L'application

num?erique

a

partir

des

r?esultats

de

la

figure

nous

donne

ffi

I

s

soit

ns

I

s

soit

ns

I

s

soit

ns

nc

flottants

soit

nc

ko

La

diff?erence

entre

les

mesures

exp?erimentales

et

notre

mod?ele

est

en

tout

point

strictement

inf?erieur

a

sauf

pour

threads

ou

l'erreur

est

de

De

plus

la

taille

du

cache

donn?ees

sur

les

stations

Sun

Sparc

est

bien

de

ko

-LSB-

-RSB-

Ces

r?esultats

valident

ainsi

nos

hypoth?eses

Retour

a

la

premi?ere

exp?erience

Nous

pouvons

maintenant

comprendre

pourquoi

le

ph?enom?ene

appara

t

plus

vite

sur

la

station

ELC

En

effet

son

cache

est

de

ko

Le

point

de

transition

se

situe

donc

apr?es

threads

En

effet

le

domaine

a

une

taille

de

flottants

-LRB-

soit

octets

-RRB-

De

plus

le

point

de

transition

se

situe

d?es

que

les

donn?ees

affect?ees

a

un

thread

repr?esentent

deux

fois

la

taille

du

thread

Or

-LRB-

-RRB-

arrondi

par

d?efaut

a

Nous

n'observons

pas

d'effet

de

cache

pour

threads

Par

contre

nous

l'observons

pour

threads

Nos

r?esultats

ne

contredisent

donc

pas

la

premi?ere

exp?erience

Discussion

Le

parall?elisme

de

processus

se

comporte

somme

toute

assez

bien

Cependant

nous

nous

sommes

plac?es

dans

de

bonnes

conditions

en

ne

g?en?erant

pas

de

communications

entre

processus

-LRB-

voir

la

section

pour

les

communications

-RRB-

Pourtant

il

souffre

d'une

tr?es

forte

limitation

le

nombre

de

processus

En

effet

la

duplication

de

code

consomme

trop

de

m?emoire

Le

parall?elisme

de

threads

offre

une

plus

grande

extensibilit?e

car

seule

la

pile

est

dupliqu?ee

L'utilisation

de

threads

dans

un

programme

de

calcul

intensif

para

t

avoir

un

co

ut

tr?es

raisonnable

En

effet

dans

nos

exp?eriences

il

nous

en

co

utait

s

par

thread

pour

it?erations

En

supposant

que

le

co

ut

de

lancement

soit

nul

-LRB-

ffi

-RRB-

ce

qui

n'est

pas

le

cas

nous

obtenons

un

co

ut

de

ns

par

thread

C'est

a

dire

le

temps

de

calcul

de

moins

de

flottants

dans

le

cache

ou

flottants

non

pr?esents

dans

le

cache

de

notre

exemple

Gr

ace

a

ces

estimations

nous

pouvons

donner

deux

crit?eres

pour

le

choix

de

la

taille

des

threads

-LRB-

et

donc

leur

nombre

-RRB-

en

posant

le

syst?eme

d'

equation

suivant

n

t

nc

-LRB-

a

-RRB-

n

t

s

-LRB-

b

-RRB-

L'

equation

-LRB-

a

-RRB-

exprime

que

la

taille

des

donn?ees

affect?ee

a

un

thread

doit

etre

inf?erieure

a

la

taille

du

cache

afin

de

maximiser

l'utilisation

du

cache

L'

equation

-LRB-

b

-RRB-

propose

de

borner

le

surco

ut

des

threads

par

it?eration

La

quantit?e

s

repr?esente

la

proportion

maximale

de

temps

qu'un

thread

peut

perdre

en

surco

ut

par

rapport

au

calcul

qu'il

effectue

Homog?en?eisons

le

syst?eme

n

t

nc

-LRB-

a

-RRB-

n

t

s

-LRB-

-RRB-

Le

d?efaut

du

syst?eme

d'

equation

-LRB-

a

-RRB-

est

qu'il

n

a

pas

toujours

de

solution

En

effet

il

ne

poss?ede

de

solution

que

si

le

surco

ut

s

nc

Par

exemple

pour

l'exp

erience

pr?ec?edente

le

syst?eme

a

une

solution

si

s

Nous

pouvons

donc

obtenir

des

solutions

pour

une

surcharge

tout

a

fait

raisonnable

dans

notre

exemple

Nous

remarquons

aussi

qu'il

ne

prend

pas

en

compte

la

d?ecoupe

du

domaine

Il

faut

donc

contraindre

le

syst?eme

par

des

equations

sp?ecifiant

la

forme

du

domaine

Par

exemple

pour

un

domaine

a

deux

dimensions

la

d?ecoupe

peut

etre

-LRB-

BLOCK

BLOCK

-RRB-

ou

-LRB-

BLOCK

-RRB-

Conclusion

D'abord

nous

avons

vu

les

d?etails

de

l'impl

ementation

de

qui

en

font

un

mauvais

candidat

pour

le

parall?elisme

de

processus

Nous

avons

aussi

constat?e

que

le

surco

ut

li?e

aux

threads

de

calcul

sans

communication

est

faible

Nous

avons

revu

l'importance

du

cache

Ces

consid?erations

nous

ont

men?e

a

formuler

deux

crit?eres

pour

d?eterminer

une

bonne

taille

des

threads

pour

un

probl?eme

donn?e

Avant

d'envisager

d'utiliser

les

processus

l?egers

pour

l'ex

ecution

de

programme

a

parall?elisme

de

donn?ees

il

nous

reste

a

d?eterminer

le

co

ut

d'une

synchronisation

globale

entre

n

threads

d'un

m

eme

processus

op?eration

tr?es

courante

en

data-parall

elisme

Ce

probl?eme

est

l'objet

de

la

prochaine

section

Synchronisations

globales

de

processus

l?egers

Le

probl?eme

Nous

allons

maintenant

t

acher

d'estimer

le

co

ut

de

synchronisation

globale

de

n

threads

En

effet

une

ex?ecution

d'un

programme

data-parall

ele

g?en?ere

un

grand

nombre

de

synchronisations

C'est

donc

une

forte

contrainte

pour

le

nombre

de

threads

par

processus

La

surcharge

g?en?er?ee

par

la

synchronisation

des

threads

devra

rester

dans

des

proportions

acceptables

Notre

probl?eme

est

de

synchroniser

n

threads

Nous

distinguons

deux

niveaux

de

synchronisation

une

synchronisation

interne

a

un

processus

et

une

synchronisation

de

threads

sur

des

processus

diff?erents

La

synchronisation

interne

est

un

probl?eme

de

m?emoire

partag?ee

Elle

est

r?ealis?ee

de

fa?con

classique

en

utilisant

un

compteur

du

nombre

de

threads

qui

ont

appel?e

la

fonction

de

synchronisation

L'acc

es

au

compteur

est

en

exclusion

mutuelle

Le

dernier

thread

appelant

la

fonction

r?eveille

tous

les

threads

endormis

sur

la

barri?ere

Si

la

synchronisation

met

en

jeu

plusieurs

processus

nous

sommes

face

a

un

probl?eme

de

m?emoire

distribu?ee

Une

fois

la

synchronisation

interne

r?ealis?ee

chaque

processus

participe

a

la

syn

chronisation

des

processus

C'est

un

probl?eme

tr?es

etudi?e

et

il

existe

quantit?e

de

protocoles

plus

ou

moins

performants

-LSB-

-RSB-

L'exp

erience

synchronisation

intra-processus

Nous

nous

int?eressons

qu'au

cas

de

synchronisations

entre

threads

a

l'int

erieur

d'un

unique

processus

En

effet

la

synchronisation

de

threads

sur

des

processus

distincts

revient

a

faire

des

synchronisations

internes

a

chaque

processus

puis

des

synchronisations

de

processus

classique

Notre

probl?eme

est

d'estimer

le

co

ut

d'une

synchronisation

interne

qui

contrairement

aux

synchronisations

de

processus

est

peu

connu

Description

de

l'exp

erience

et

mesures

L'exp

erience

consiste

donc

en

un

programme

qui

effectue

synchronisations

entre

tous

les

threads

a

l'int

erieur

d'un

unique

processus

Les

effets

de

cache

eventuels

ont

et?e

supprim?es

Le

temps

du

programme

en

fonction

du

nombre

de

threads

est

pr?esent?e

en

figure

Il

n

y

a

pas

de

mesures

pour

threads

pour

la

station

ELC

car

la

station

ne

disposait

pas

de

suffisamment

de

m?emoire

500 1000 1500 2000

Temps

-LRB-

s

-RRB-

Nombre

de

threads

Sparc

ELC

Sparc

Fig.

Influence

du

nombre

de

threads

sur

la

synchronisation

globale

Analyse

des

r?esultats

La

figure

nous

apprend

que

le

co

ut

d'une

synchronisation

semble

etre

proportionnel

au

nombre

de

threads

Essayons

d'analyser

plus

finement

ce

qui

se

passe

Notre

mod?ele

d'ex

ecution

pour

un

thread

est

qu'il

passe

un

certain

temps

a

calculer

puis

qu'il

se

synchronise

avec

les

autres

threads

Nous

supposons

que

le

temps

de

calcul

est

inf?erieur

au

temps

de

pr?eemption

Nous

ne

consid?erons

donc

pas

de

changements

de

contexte

pendant

les

calculs

En

fait

nous

pouvons

n?egliger

ce

co

ut

car

il

repr?esente

moins

de

s

toutes

les

ms

soit

moins

d'un

milli?eme

du

temps

d'ex

ecution

-LRB-

voir

section

-RRB-

Soit

le

co

ut

d'une

synchronisation

en

-LRB-

T

-RRB-

o?u

T

est

le

nombre

de

threads

En

effet

une

synchronisation

entre

T

threads

impliquent

que

T

threads

se

bloquent

et

qu'un

thread

le

dernier

a

atteindre

la

synchronisation

lib?ere

les

T

threads

bloqu?es

La

lib?eration

de

T

threads

dans

consiste

en

une

boucle

sur

les

T

threads

qui

englobe

un

appel

a

la

fonction

de

d?eblocage

d'un

thread

Son

co

ut

est

donc

en

-LRB-

T

-RRB-

Par

cons?equent

le

co

ut

d'une

synchronisation

entre

T

threads

est

de

-LRB-

T

-RRB-

-LRB-

co

ut

d'un

changement

de

contexte

co

ut

pour

d?ebloquer

un

thread

-RRB-

500 1000 1500 2000

Temps

-LRB-

s

-RRB-

Nombre

de

threads

Sparc

ELC

Sparc

Simulation

Sparc

ELC

Simulation

Sparc

Fig.

Courbe

exp?erimentale

et

de

la

mod?elisation

de

l'exp

erience

Les

courbes

exp?erimentales

de

la

figure

constituent

des

droites

affines

de

pente

respective

et

La

diff?erence

entre

les

courbes

exp?erimentales

et

les

courbes

issues

de

notre

mod?elisation

diff?ere

de

moins

de

en

tout

point

Elle

est

m

eme

fr?equemment

inf?erieure

a

Pour

la

Sparc

le

surco

ut

par

thread

comprenant

les

changements

de

contexte

et

les

synchronisations

est

donc

d'environ

ms

par

thread

pour

it?erations

soit

environ

s

par

thread

et

par

it?eration

Nous

avons

donc

l?a

notre

troisi?eme

contrainte

pour

d?ecider

de

la

taille

des

threads

En

effet

si

nous

d?esirons

maintenir

le

surco

ut

li?e

aux

synchronisations

en

de?c?a

d'un

certain

pourcentage

nous

obtenons

par

une

r?egle

de

trois

le

nombre

de

threads

par

processus

et

donc

la

taille

des

donn?ees

d'un

thread

Discussion

synchronisation

ou

cr?eation

de

threads

Les

threads

ont

la

r?eputation

d'avoir

un

co

ut

tr?es

faible

C'est

probablement

pourquoi

il

a

et?e

pens?e

que

les

threads

etaient

un

bon

moyen

pour

g?erer

les

diff?erences

de

parall?elisme

d'un

m

eme

code

Durant

les

parties

s?equentielles

il

n'existe

qu'un

seul

thread

qui

peut

cr?eer

d'autres

threads

pour

les

parties

parall?eles

du

code

Ainsi

les

probl?emes

de

synchronisations

des

threads

pour

le

code

s?equentiel

sont

r?esolus

Environnement

de

threads

Temps

moyen

de

cr?eation

d'un

thread

Sans

pr?eallocation

de

m?emoire

Threads

Marcel

-LRB-

-RRB-

s

Threads

Solaris

s

Avec

pr?eallocation

de

m?emoire

Threads

Marcel

-LRB-

-RRB-

s

Threads

Solaris

s

Tab

Temps

moyen

de

cr?eation

d'un

thread

ayant

une

pile

de

Ko

sur

une

station

Sparc

avec

Solaris

Marcel

est

le

noyau

de

gestion

de

threads

sur

lequel

s

appuie

Nous

avons

utilis?e

le

fait

que

Marcel

garde

la

m?emoire

allou?ee

a

un

thread

a

la

fin

de

celui-ci

pour

simuler

la

pr?eallocation

de

m?emoire

Nous

avons

donc

mesur?e

le

temps

moyen

de

cr?eation

d'un

nombre

elev?e

de

threads

sans

destruction

de

threads

Nous

avons

v?erifi?e

que

les

threads

cr?e?es

ne

s

ex?ecutaient

pas

durant

les

mesures

Malheureusement

comme

le

montre

le

tableau

le

temps

de

cr?eation

d'un

thread

est

loin

d'

etre

n?egligeable

Il

est

int?eressant

de

noter

que

le

fait

de

cr?eer

un

thread

en

ayant

pr?eallou?e

la

m?emoire

permet

de

gagner

s

soit

avec

les

threads

Solaris

Malheureusement

ne

permet

pas

de

pr?eallocation

m?emoire

Nous

nous

contenterons

de

signaler

que

l'allocation

de

m?emoire

est

une

op?eration

tr?es

co

uteuse

Cependant

a

la

mort

d'un

thread

garde

la

m?emoire

allou?ee

pour

la

cr?eation

de

ce

thread

lorsque

la

taille

de

la

m?emoire

est

standard

Dans

ce

cas

la

cr?eation

d'un

nouveau

thread

n'est

plus

que

de

s.

La

simulation

de

cette

fonctionnalit?e

avec

des

threads

Solaris

permet

de

voir

que

la

recr?eation

d'un

thread

est

beaucoup

moins

co

uteuse

que

la

cr?eation

d'un

thread

Solaris

m

eme

avec

pr?eallocation

de

m?emoire

Le

temps

de

cr?eation

d'un

thread

est

donc

environ

ss

fois

plus

lent

qu'une

synchronisation

-LRB-

ou

ss

si

nous

consid?erons

une

recr?eation

de

thread

-RRB-

Cependant

il

est

probable

que

le

co

ut

de

synchronisation

peut

etre

diminu?e

en

changeant

de

m?ethode

de

gestion

des

threads

En

effet

le

terme

dominant

de

la

synchronisation

globale

en

-LRB-

T

-RRB-

est

la

fonction

de

r?eveil

d'un

thread

Cependant

si

lorsqu'un

thread

s

endort

il

se

place

dans

une

file

sp?eciale

tout

en

pr?eparant

son

etat

pr

et

a

etre

ex?ecut?e

le

dernier

thread

n

a

plus

qu

a

concat?ener

cette

file

a

la

file

des

threads

actifs

Cette

op?eration

peut

etre

r?ealis?ee

a

un

co

ut

tr?es

faible

Le

co

ut

de

la

synchronisation

resterait

en

-LRB-

T

-RRB-

car

chaque

thread

doit

quand

m

eme

s

endormir

mais

la

constante

serait

sensiblement

plus

petite

-LRB-

nous

pensons

au

moins

de

moiti?e

-RRB-

Et

donc

le

co

ut

d'une

synchronisation

par

thread

diminuerait

presque

d'autant

Bref

le

ratio

du

temps

de

cr?eation

d'un

thread

sur

le

temps

de

synchronisation

a

plus

de

chance

d'augmenter

que

de

diminuer

Il

n'est

pas

donc

evident

de

savoir

s

il

vaut

mieux

cr?eer

des

threads

au

fur

et

a

mesure

des

besoins

ou

synchroniser

un

ensemble

de

threads

Dans

le

premier

cas

nous

avons

la

libert?e

de

cr?eer

exactement

le

nombre

de

threads

n?ecessaires

mais

pour

un

co

ut

plus

elev?e

Dans

le

deuxi?eme

cas

nous

disposons

d'un

ensemble

de

threads

n?ecessitant

des

synchronisations

ainsi

qu'une

programmation

plus

compliqu?ee

due

notamment

aux

tests

pour

savoir

qui

doit

travailler

Mais

la

deuxi?eme

solution

a

certainement

un

co

ut

-LRB-

tr?es

-RRB-

inf?erieur

a

la

premi?ere

Conclusion

Le

co

ut

d'une

synchronisation

est

donc

proportionnel

au

nombre

de

threads

participants

Le

co

ut

d'une

synchronisation

par

thread

sur

une

Sparc

est

de

l'ordre

de

s

-LRB-

a

comparer

avec

le

temps

de

cr?eation

d'un

thread

et

le

temps

de

latence

des

r?eseaux

qui

s

expriment

en

centaine

de

microsecondes

-RRB-

Ce

co

ut

est

raisonnable

et

permet

donc

d'utiliser

un

parall?elisme

de

threads

important

Nous

avons

vu

qu'une

synchronisation

est

beaucoup

moins

co

uteuse

qu'une

cr?eation

de

threads

Sans

pr?eallocation

de

m?emoire

le

rapport

est

d'environ

Gestion

des

communications

Maintenant

que

nous

avons

une

id?ee

assez

pr?ecise

sur

le

comportement

des

threads

nous

allons

nous

int?eresser

aux

communications

Nous

avons

trois

niveaux

de

m?emoire

et

donc

trois

types

d'acc

es

m?emoire

a

g?erer

les

acc?es

d'un

thread

a

sa

m?emoire

propre

les

acc?es

d'un

thread

a

la

m?emoire

d'un

autre

thread

du

m

eme

processus

et

les

acc?es

d'un

thread

a

la

m?emoire

d'un

autre

thread

d'un

autre

processus

Le

premier

point

est

bien

connu

et

l'introduction

de

threads

n'apporte

rien

de

nouveau

Le

deuxi?eme

point

est

un

probl?eme

de

m?emoire

partag?ee

En

effet

nous

voulons

qu'un

thread

puisse

directement

aller

lire

dans

la

m?emoire

d'un

autre

thread

qui

est

dans

le

m

eme

processus

afin

de

ne

pas

avoir

de

recopie

m?emoire

inutile

et

co

uteuse

Le

troisi?eme

point

est

le

seul

a

g?en?erer

des

communications

a

travers

le

r?eseau

Nous

pouvons

soit

consid?erer

des

communications

entre

threads

ou

bien

agr?eger

les

communications

et

ne

consid?erer

que

des

communications

entre

processus

Nous

allons

d?etailler

les

deux

derniers

points

dans

les

sous-sections

suivantes

Nous

commencerons

d'abord

par

les

communications

intra-processus

puis

par

les

communications

inter-processus

Description

de

notre

exp?erience

Notre

programme

de

test

est

tr?es

simple

Il

s

agit

de

it?erations

sur

un

tableau

de

flottants

en

double

pr?ecision

de

taille

En

chaque

point

o?u

cela

a

un

sens

le

programme

calcule

A

-LRB-

i

j

-RRB-

en

fonction

de

A

-LRB-

i

j

-RRB-

et

de

A

-LRB-

i

j

-RRB-

Le

calcul

d'une

ligne

n?ecessite

la

connaissance

de

la

ligne

du

dessous

ce

qui

nous

g?en?ere

des

communications

Les

communications

intra-processus

Afin

de

ne

pas

avoir

de

buffer

entre

threads

sur

le

m

eme

processus

et

donc

de

ne

pas

rajouter

une

surcharge

nous

permettons

a

un

thread

d'aller

directement

lire

dans

la

m?emoire

d'un

autre

thread

Nous

utilisons

un

m?ecanisme

de

s?emaphores

pour

garantir

les

d?ependances

Comme

nous

consid?erons

des

programmes

a

parall?elisme

de

donn?ees

style

HPF

nous

devons

introduire

une

synchronisation

globale

par

it?eration

dans

un

nid

de

boucles

parall?eles

classique

Elle

permet

a

ce

qu'un

thread

n'aille

pas

lire

trop

t

ot

dans

la

m?emoire

d'un

autre

thread

C'est

la

synchronisation

de

boucle

qui

emp

eche

un

thread

d'

ecraser

ses

donn?ees

trop

t

ot

Nombre

de

Nb

de

Vol

d'

comm

Vol

total

des

comm

Temps

Eff

threads

comm

-LRB-

en

double

-RRB-

-LRB-

en

double

-RRB-

-LRB-

en

s

-RRB-

-LRB-

en

-RRB-

L

L

L

L

L

L

L

L

L

L

L

Tab

Threads

et

communications

intra-processus

sur

Sparc

Le

temps

s?equentiel

sans

thread

est

de

secondes

Une

ligne

a

une

taille

de

L

flottants

En

d?efinitive

les

communications

intra-processus

ont

comme

co

ut

celui

d'une

synchronisation

interne

Nous

avons

vu

pr?ec?edemment

que

ce

co

ut

est

proportionnel

au

nombre

de

threads

Le

tableau

nous

confirme

que

les

synchronisations

ne

sont

pas

ch?eres

pour

threads

-LRB-

avec

deux

synchronisations

par

it?eration

et

it?erations

-RRB-

En

effet

nous

obtenons

quasiment

le

m

eme

temps

pour

threads

que

le

temps

s?equentiel

-LRB-

-RRB-

Les

variations

de

temps

observ?ees

au

tableau

doivent

etre

dues

a

la

forme

du

domaine

a

parcourir

et

aux

effets

de

cache

associ?es

Les

communications

inter-processus

Mesure

des

communications

Les

communications

sous

se

font

via

des

appels

de

proc?edures

distantes

l?eg?eres

-LRB-

Light

Remote

Procedure

Call

LRPC

-RRB-

Les

LRPC

sont

des

messages

PVM

C'est

le

thread

de

communication

de

qui

se

charge

de

recevoir

les

messages

PVM

et

d'appeler

la

fonction

de

traitement

ad?equate

Il

existe

sous

toute

une

vari?et?e

de

types

de

LRPC

-LSB-

-RSB-

synchrone

ou

asynchrone

r?esultat

diff?er?e

ou

non

avec

cr?eation

de

thread

ou

non

Il

y

a

donc

un

surco

ut

g?en?er?e

par

le

thread

de

gestion

des

LRPC

Ethernet

ATM

PVM

LRPC

PVM

LRPC

Latence

ms

ms

ms

ms

D?ebit

Mbits/s

Mbits/s

Mbits/s

Mbits/s

Tab

Latence

et

d?ebit

sur

r?eseau

Ethernet

entre

deux

stations

Sparc

Nous

avons

mesur?e

la

latence

et

le

d?ebit

d'un

LRPC

sans

cr?eation

de

thread

entre

stations

Sparc

sous

Solaris

sur

un

r?eseau

Ethernet

quasiment

inoccup?e

Le

tableau

r?esume

nos

mesures

alors

que

la

figure

montre

que

les

courbes

des

d?ebits

des

LRPC

et

des

messages

PVM

sont

semblables

10 100 1000 10000

Debit

-LRB-

Mo/s

-RRB-

Longueur

du

message

-LRB-

en

octet

-RRB-

Debit

PVM

Debit

LRPC

Fig.

Courbe

du

d?ebit

des

LRPC

et

de

PVM

sur

r?eseau

Ethernet

avec

les

options

PvmDataRaw

et

PvmRouteDirect

Il

y

a

plusieurs

facteurs

qui

expliquent

le

surco

ut

des

communications

Premi?erement

il

y

a

un

surco

ut

logiciel

d

u

a

la

gestion

des

LRPC

Deuxi?emement

en

plus

de

la

pr?eemption

du

processus

par

l'ordonnanceur

Unix

nous

avons

aussi

la

pr?eemption

du

thread

de

communication

par

Cependant

le

co

ut

reste

acceptable

avec

une

latence

de

plus

longue

et

un

d?ebit

de

plus

faible

Mesures

des

performances

de

notre

programme

Nous

n'avons

pas

introduit

de

syst?eme

d'agr

egation

pour

deux

raisons

D'une

part

pour

v?erifier

que

le

comportement

sans

agr?egation

est

bien

celui

attendu

D'autre

part

agr?eger

les

communications

revient

a

faire

des

synchronisations

internes

globales

dont

le

co

ut

est

minime

compar?e

aux

communications

Le

comportement

devrait

donc

etre

celui

avec

un

seul

thread

par

communication

Les

r?esultats

sont

pr?esent?es

dans

le

tableau

L

est

la

taille

de

notre

tableau

-LRB-

ici

L

-RRB-

Nombre

de

processus

Nombre

de

threads

par

processus

Nombre

de

communications

Volume

d'une

communication

L

L

L

L

Temps

total

-LRB-

s

-RRB-

Efficacit?e

-LRB-

-RRB-

Temps

de

comm

par

it?eration

-LRB-

ms

-RRB-

Recouvrement

des

comm

-LRB-

-RRB-

Tab

Threads

et

communications

Le

temps

s?equentiel

sans

thread

est

de

secondes

La

latence

est

de

ms

et

le

d?ebit

de

Mbits/s

L

flottants

en

double

pr?ecision

L'option

PvmRouteDirect

de

PVM

est

utilis?ee

Analyse

des

r?esultats

Nous

constatons

que

le

nombre

de

threads

augmentant

le

nombre

de

messages

augmente

et

avec

lui

le

temps

de

communication

bien

que

le

volume

total

de

communication

reste

constant

La

raison

en

est

que

la

latence

du

r?eseau

Ethernet

est

importante

Cependant

dans

la

pire

de

nos

exp?eriences

les

calculs

arrivent

a

recouvrir

encore

environ

du

surco

ut

engendr?e

par

les

communications

Les

threads

en

fait

ne

modifient

pas

le

probl?eme

des

communications

Ils

permettent

seulement

de

mieux

recouvrir

les

communications

par

les

calculs

mais

au

prix

d'un

plus

grand

nombre

de

messages

Cette

augmentation

de

message

conduit

pour

notre

exp?erience

a

des

performances

d?egrad?ees

a

cause

du

peu

de

calcul

d'un

unique

m?edium

de

communication

et

de

la

latence

importante

de

ce

m?edium

Conclusion

Nous

avons

vu

un

moyen

efficace

pour

g?erer

les

communications

inter-threads

dans

le

m

eme

processus

Leur

co

ut

est

au

plus

celui

de

synchronisations

entre

les

threads

participant

aux

communications

Le

surco

ut

des

communications

entre

processus

est

li?e

a

la

gestion

des

diff?erents

modes

de

LRPC

possibles

C'est

la

latence

qui

subit

la

plus

forte

d?egradation

avec

alors

que

le

d?ebit

n'est

r?eduit

que

de

Notre

exp?erience

a

montr?e

que

les

threads

recouvraient

les

communications

mais

que

le

prix

a

payer

est

une

hausse

du

nombre

de

messages

Vu

la

taille

des

messages

mis

en

jeu

-LRB-

moins

de

ko

-RRB-

et

la

faible

quantit?e

de

calcul

par

it?eration

le

temps

de

latence

s

av?ere

trop

important

pour

cette

approche

pour

notre

programme

de

test

Migration

et

processus

l?egers

Description

de

la

migration

de

threads

Nous

avons

choisi

l'environnement

parce

qu'il

offre

la

possibilit?e

de

migrer

les

threads

La

migration

d'un

thread

se

fait

par

l'interm

ediaire

d'une

fonction

sp?eciale

Cette

fonction

se

charge

d'empaqueter

la

partie

utilis?ee

de

la

pile

du

thread

ainsi

que

les

structures

de

contr

ole

du

thread

d'envoyer

les

donn?ees

sur

le

processus

destination

et

de

relancer

l'ex

ecution

du

thread

sur

ce

processus

ne

g?ere

pas

la

coh?erence

des

acc?es

aux

variables

globales

C'est

a

l'utilisateur

de

la

g?erer

Pour

faciliter

cette

gestion

propose

deux

fonctions

utilisateurs

L'une

est

appel?ee

juste

avant

l'envoi

du

message

et

l'autre

est

appel?ee

avant

de

relancer

le

thread

Ces

fonctions

permettent

d'une

part

de

g?erer

l'acc

es

aux

eventuelles

variables

locales

du

processus

-LRB-

comme

la

table

des

threads

locaux

-RRB-

et

d'autre

part

d'empaqueter

avec

le

thread

des

eventuelles

donn?ees

non

allou?ees

sur

la

pile

En

effet

dans

notre

impl?ementation

chaque

thread

alloue

la

m?emoire

dont

il

a

besoin

pour

stocker

son

bloc

de

tableau

sur

le

tas

ne

migrant

pas

ces

donn?ees

avec

le

thread

il

nous

est

facile

de

les

empaqueter

dans

le

message

de

migration

gr

ace

a

ces

deux

fonctions

fournit

aussi

la

possibilit?e

de

compresser

la

pile

avant

de

la

migrer

L'algorithme

par

d?efaut

ne

fait

que

la

compression

de

z?eros

Il

peut

s

av?erer

int?eressant

d'utiliser

un

algorithme

plus

performant

pour

des

r?eseaux

lents

Co

ut

de

la

migration

de

threads

Nous

voulons

faire

de

la

migration

de

threads

Il

est

par

cons?equent

primordial

d'avoir

une

id?ee

du

co

ut

de

la

migration

d'un

thread

Exp?erience

description

et

mesure

L'exp

erience

consiste

a

faire

effectuer

un

grand

nombre

d'allers-retours

a

un

thread

afin

d'avoir

le

temps

moyen

d'une

migration

Nous

faisons

varier

la

taille

du

thread

a

migrer

ainsi

que

les

types

de

r?eseaux

Nous

ne

couplons

que

des

machines

de

m

eme

type

Sparc

ELC

ou

Sparc

Nous

avons

d'abord

plac?e

les

deux

processus

sur

la

m

eme

machine

puis

sur

des

machines

connect?ees

par

un

r?eseau

Ethernet

puis

par

un

r?eseau

ATM

Nous

n'utilisons

pas

l'option

de

compression

ni

l'option

PvmRouteDirect

de

PVM

La

migration

utilise

quand

m

eme

l'option

PvmDataRaw

car

la

migration

de

threads

ne

peut

actuellement

se

faire

qu'entre

des

machines

ayant

entre

autres

la

m

eme

repr?esentation

des

nombres

Temps

-LRB-

ms

-RRB-

Longueur

du

message

-LRB-

octets

-RRB-

Sparc

ELC

Sparc

ELC

Ethernet

Sparc

Sparc

Ethernet

Sparc

ATM

Fig.

Temps

de

migration

de

threads

pour

diff?erents

machines

et

r?eseau

koctets/s

Longueur

du

message

-LRB-

octets

-RRB-

Sparc

ELC

Sparc

ELC

Ethernet

Sparc

Sparc

Ethernet

Sparc

ATM

Fig.

D?ebit

de

la

migration

de

threads

pour

diff?erents

machines

et

r?eseaux

Analyse

des

r?esultats

Les

figure

et

nous

montre

que

le

co

ut

est

essentiellement

d

u

aux

communications

et

donc

que

le

mod?ele

en

L

o

est

encore

valable

en

premi?ere

approximation

Cependant

la

latence

et

le

d?ebit

observ?es

ne

sont

pas

ceux

des

r?eseaux

Il

y

a

en

effet

un

surco

ut

d

u

a

la

migration

Ce

surco

ut

consiste

essentiellement

en

un

surco

ut

logiciel

d

u

a

la

pr?eparation

r?eception

du

thread

a

migrer

ainsi

qu'en

une

longueur

minimale

du

message

a

cause

des

structures

de

contr

ole

du

thread

qui

doivent

etre

migr?ees

Debit

-LRB-

Mo/s

-RRB-

Longueur

du

message

-LRB-

octets

-RRB-

Debit

PVM

Debit

LRPC

Debit

Migration

Fig.

D?ebit

entre

deux

Sparc

sur

r?eseau

Ethernet

de

PVM

des

LRPC

et

de

la

migration

L'option

PvmRouteDirect

de

PVM

est

utilis?ee

PVM

LRPC

Migration

Latence

ms

ms

D?ebit

Mbits/s

Mbits/s

Mbits/s

Temps

d'un

messages

de

ko

ms

ms

Tab

Latence

et

d?ebit

sur

r?eseau

Ethernet

Pour

les

performances

reportons-nous

a

la

figure

et

au

tableau

Cette

figure

et

ce

tableau

ont

et?e

obtenus

en

utilisant

l'option

PvmRouteDirect

Nous

observons

qu'entre

deux

Sparc

nous

obtenons

une

latence

de

ms.

La

latence

peut

para

tre

elev?ee

mais

c'est

principalement

parce

que

la

longueur

minimale

d'un

message

contenant

un

thread

a

migrer

est

d'environ

octets

sous

Solaris

C'est

la

taille

que

repr?esente

les

structures

de

contr

ole

du

thread

plus

la

taille

de

la

pile

utilis?ee

par

notre

thread

de

test

Ainsi

la

latence

de

la

migration

n'est

que

de

-LRB-

respectivement

-RRB-

plus

grande

qu'un

LRPC

-LRB-

respectivement

un

message

PVM

-RRB-

de

octets

Nous

obtenons

du

d?ebit

de

PVM

soit

presque

Mbits/s

Le

d?ebit

d'une

migration

est

sup?erieur

au

d?ebit

d'un

LRPC

Cette

diff?erence

doit

etre

imput?ee

au

syst?eme

de

codage

des

nombres

de

PVM

En

effet

la

migration

transf?ere

la

pile

comme

une

suite

d'octets

la

compatibilit?e

des

repr?esentations

des

nombres

etant

une

cons?equence

de

la

compatibilit?e

des

piles

La

migration

utilise

donc

la

fonction

pvm

pkbyte

qui

se

trouve

etre

plus

performante

que

la

fonction

pvm

pkint

que

nous

avons

utilis?ee

pour

empaqueter

les

donn?ees

dans

les

LRPC

Bref

comme

-LSB-

-RSB-

le

remarque

le

codage

des

nombres

baisse

sensiblement

les

performances

Conclusion

Le

co

ut

de

la

migration

de

processus

l?egers

d?epend

fortement

du

co

ut

de

communication

Par

cons?equent

sa

mod?elisation

se

fait

comme

celle

d'une

communication

classique

La

surcharge

minimale

introduite

sous

Solaris

par

les

threads

se

traduit

au

niveau

des

communications

par

l'envoi

de

ko

de

donn?ees

pour

un

thread

qui

ne

consomme

quasiment

pas

de

pile

Ces

donn?ees

comprennent

les

structures

de

contr

ole

du

thread

ainsi

que

la

pile

Les

performances

observ?ees

sont

proche

de

celles

de

PVM

soit

de

son

d?ebit

mais

une

latence

de

La

latence

est

de

plus

grande

que

celle

d'un

LRPC

mais

le

d?ebit

est

meilleur

de

Conclusion

Lors

de

nos

exp?eriences

nous

avons

trouv?e

que

l'introduction

de

environnement

multithread

avec

une

pr?eemption

toutes

les

ms

rajoutait

un

surco

ut

de

l'ordre

de

sur

une

Sparc

et

sur

une

ELC

Les

synchronisation

de

threads

repr?esentent

un

co

ut

de

s

par

thread

sur

une

Sparc

a

MHz

alors

qu'une

cr?eation

de

thread

est

a

fois

plus

co

uteuse

Les

communications

inter-thread

intra-processus

ont

comme

co

ut

au

plus

deux

synchronisations

lorsque

nous

permettons

a

un

thread

d'aller

directement

lire

la

m?emoire

d'un

autre

thread

Ces

synchronisations

sont

l?a

pour

la

garantir

les

d?ependances

entre

les

lectures

et

les

ecritures

Les

communications

inter-thread

inter-processus

au

travers

d'un

r?eseau

Ethernet

montrent

bien

un

recouvrement

des

communications

par

le

calcul

mais

le

co

ut

de

la

latence

d'Ethernet

est

un

s?erieux

handicap

vu

que

le

nombre

de

messages

augmente

La

migration

des

threads

dans

est

efficace

Nous

obtenons

une

latence

de

plus

grande

que

celle

de

l'envoi

d'un

LRPC

et

le

d?ebit

repr?esente

plus

de

celui

d'un

message

PVM

rajoute

en

fait

moins

de

ko

de

donn?ees

pour

la

gestion

d'un

thread

Nous

avons

aussi

donn?e

trois

crit?eres

pour

le

calcul

de

la

taille

d'un

thread

Ces

crit?eres

sont

le

surco

ut

maximal

que

nous

d?esirons

une

borne

sup?erieure

qui

est

la

taille

du

cache

donn?ees

et

le

co

ut

que

nous

d?esirons

pour

les

synchronisations

Cependant

une

etude

plus

pouss?ee

sur

l'influence

de

ces

crit?eres

serait

n?ecessaire

En

conclusion

les

threads

sont

de

bons

candidats

pour

encapsuler

des

processeurs

virtuels

de

HPF

Leur

co

ut

reste

acceptable

alors

qu'ils

ont

le

grand

avantage

de

ne

quasiment

pas

remettre

en

cause

la

compilation

de

programme

HPF

De

nouvelles

fonctionnalit?es

de

l'ex

ecutif

ainsi

que

quelques

structures

de

contr

ole

en

plus

devraient

suffire

Remerciements

Je

voudrais

d'abord

remercier

Luc

Boug?e

pour

ses

conseils

et

ses

encouragements

Je

tiens

aussi

a

remercier

Thomas

Brandes

pour

ses

explications

relatifs

a

Adaptor

et

pour

sa

disponibilit?e

Je

remercie

egalement

J.-M

Geib

J.-F

Mehaut

R.

Namyst

et

Y.

Denneulin

du

LIFL

pour

leur

accueil

et

leur

patience

a

m

expliquer

les

dessous

de

Je

remercie

aussi

Lo

c

Prylli

du

LIP

pour

son

aide

a

propos

d'ATM

R?ef?erences

-LSB-

-RSB-

Andr?e

-LRB-

F.

-RRB-

-LCB-

A

Multi-Threads

Runtime

For

The

Pandore

Data-Parallel

Compiler

-LCB-

Rapport

technique

n

IRISA

f?evrier

Available

at

URL

-LSB-

-RSB-

Bach

-LRB-

M.

J.

-RRB-

-LCB-

The

Design

of

the

Unix

Operating

System

-LCB-

Prentice-Hall

Software

Series

-LSB-

-RSB-

Blumofe

-LRB-

R.

-RRB-

Joerg

-LRB-

C.

-RRB-

Kuszmaul

-LRB-

B.

-RRB-

Leiserson

-LRB-

C.

-RRB-

Randall

-LRB-

K.

-RRB-

et

Zhou

-LRB-

Y.

-RRB-

-LCB-

Cilk

An

efficient

multithreaded

runtime

system

In

Proceedings

of

the

Fifth

ACM

SIGPLAN

Symposium

on

Principles

and

Practice

of

Parallel

Programming

-LRB-

PPOPP

-RRB-

pp.

-LCB-

-LCB-

Santa

Barbara

California

juillet

-LSB-

-RSB-

Brandes

-LRB-

T.

-RRB-

-LCB-

Adaptor

-LRB-

HPF

compilation

system

-RRB-

-LCB-

Available

at

URL

home.html

-LSB-

-RSB-

Brandes

-LRB-

T.

-RRB-

et

Zimmermann

-LRB-

F.

-RRB-

-LCB-

Adaptor

a

transformation

tool

for

HPF

programs

In

Programming

Environments

for

Massively

Parallel

Distributed

Systems

ed

par

Decker

-LRB-

K.

M.

-RRB-

et

Rehmann

-LRB-

R.

M.

-RRB-

pp

-LCB-

-LCB-

Birkh?auser

Verlag

-LSB-

-RSB-

Casas

-LRB-

J.

-RRB-

Konuru

-LRB-

R.

-RRB-

Otto

-LRB-

S.

W.

-RRB-

Prouty

-LRB-

R.

-RRB-

et

Walpole

-LRB-

J.

-RRB-

-LCB-

Adaptive

load

migration

systems

for

PVM

In

Proceedings

of

Supercomputing

pp.

-LCB-

-LCB-

Washington

D.C.

novembre

-LSB-

-RSB-

Christaller

-LRB-

M.

-RRB-

Castaneda-Retiz

-LRB-

MR.

-RRB-

et

Gautier

-LRB-

T.

-RRB-

-LCB-

Control

parallelism

on

top

of

PVM

The

Athapascan

Environment

In

EuroPVM

ed

par

Dongarra

-LRB-

J.

-RRB-

Gengler

-LRB-

M.

-RRB-

Tourancheau

-LRB-

B.

-RRB-

et

Vigouroux

-LRB-

X.

-RRB-

LIP

ENS

Lyon

pp.

-LCB-

-LCB-

Lyon

France

septembre

-LSB-

-RSB-

Cockcroft

-LRB-

A.

-RRB-

-LCB-

Sun

Performance

and

Tuning

SPARC

Solaris

-LCB-

Sunsoft

Press

PrenticeHall

-LSB-

-RSB-

Collard

-LRB-

J.-F

-RRB-

-LCB-

Parall?elisation

automatique

des

programmes

a

contr

ole

dynamique

-LCB-

Th?ese

de

doctorat

Univ.

Paris

janvier

-LSB-

-RSB-

Cuvillier

-LRB-

G.

-RRB-

et

Utard

-LRB-

G.

-RRB-

-LCB-

Compilation

de

programmes

data-parall

eles

pour

un

r?eseau

de

stations

de

travail

-LCB-

Rapport

technique

n

LIP

novembre

-LSB-

-RSB-

Darte

-LRB-

A.

-RRB-

-LCB-

Techniques

de

parall?elisation

automatique

de

nids

de

boucles

-LCB-

France

Th?ese

de

doctorat

LIP

ENS

Lyon

-LSB-

-RSB-

Dillon

-LRB-

E.

-RRB-

Santos

-LRB-

C.

Gamboa

Dos

-RRB-

et

Guyard

-LRB-

J.

-RRB-

-LCB-

Homogeneous

and

Heteregeneous

Networks

of

Workstations

Message

Passing

Overhead

-LCB-

Rapport

technique

n

France

Inria/Crin

juin

-LSB-

-RSB-

Forum

-LRB-

High

Performance

Fortran

-RRB-

-LCB-

High

Performance

Fortran

Language

Specification

-LCB-

Rice

University

Houston

Texas

novembre

Version

-LSB-

-RSB-

Foster

-LRB-

I.

-RRB-

Kesselman

-LRB-

C.

-RRB-

et

Tuecke

-LRB-

S.

-RRB-

-LCB-

The

Nexus

Task-parallel

Runtime

System

In

Int

Workshop

on

Parallel

Processing

-LSB-

-RSB-

Hinz

-LRB-

D.

Y.

-RRB-

-LCB-

A

run-time

load

balancing

strategy

for

highly

parallel

systems

Acta

Informatica

vol

pp.

-LCB-

-LSB-

-RSB-

IEEE

-LCB-

Threads

extension

for

portable

operating

systems

-LRB-

draft

-RRB-

f?evrier

-LSB-

-RSB-

Krone

-LRB-

O.

-RRB-

Aguilar

-LRB-

M.

-RRB-

et

Hirsbrunner

-LRB-

B.

-RRB-

-LCB-

PT-PVM

Using

PVM

in

a

multi-threaded

environment

In

EuroPVM

ed

par

Dongarra

-LRB-

J.

-RRB-

Gengler

-LRB-

M.

-RRB-

Tourancheau

-LRB-

B.

-RRB-

et

Vigouroux

-LRB-

X.

-RRB-

LIP

ENS

Lyon

pp.

-LCB-

-LCB-

Lyon

France

septembre

-LSB-

-RSB-

Namyst

-LRB-

R.

-RRB-

et

Mehaut

-LRB-

J.-F

-RRB-

-LCB-

Marcel

Une

biblioth?eque

de

processus

l?egers

-LCB-

LIFL

Lille

France

Available

at

URL

-LSB-

-RSB-

Namyst

-LRB-

R.

-RRB-

et

Mehaut

-LRB-

J.-F

-RRB-

-LCB-

Parallel

Multithreaded

Machine

Guide

d'utilisation

-LCB-

LIFL

Lille

France

Version

available

at

URL

-LSB-

-RSB-

Namyst

-LRB-

R.

-RRB-

et

Mehaut

-LRB-

J.-F

-RRB-

-LCB-

parallel

multithreaded

machine

A

multithreaded

envronment

on

top

of

PVM

In

EuroPVM

ed

par

Dongarra

-LRB-

J.

-RRB-

Gengler

-LRB-

M.

-RRB-

Tourancheau

-LRB-

B.

-RRB-

et

Vigouroux

-LRB-

X.

-RRB-

LIP

ENS

Lyon

pp.

-LCB-

-LCB-

Lyon

France

septembre

-LSB-

-RSB-

Nicol

-LRB-

D.

M.

-RRB-

-LCB-

Rectilinear

partitioning

of

irregular

data

parallel

computation

Journal

of

Parallel

and

Distributed

Computing

vol

pp.

-LCB-

-LSB-

-RSB-

Portland

Group

Inc.

-LRB-

The

-RRB-

-LCB-

The

Portland

Group

Welcome

Page

-LCB-

Available

at

URL

-LSB-

-RSB-

Sohn

-LRB-

A.

-RRB-

Sato

-LRB-

M.

-RRB-

Yoo

-LRB-

N.

-RRB-

et

Gaudiot

-LRB-

J.-L

-RRB-

-LCB-

Effects

of

multithreading

on

data

and

workload

distribution

for

distributed

memory

multiprocessors

In

Proceeding

of

the

IEEE

International

Parallel

Processing

Symposium

-LCB-

Honolulu

Hawaii

avril

-LSB-

-RSB-

Stellner

-LRB-

G.

-RRB-

et

Pruyne

-LRB-

J.

-RRB-

-LCB-

Resource

management

and

checkpointing

for

PVM

In

EuroPVM

ed

par

Dongarra

-LRB-

J.

-RRB-

Gengler

-LRB-

M.

-RRB-

Tourancheau

-LRB-

B.

-RRB-

et

Vigouroux

-LRB-

X.

-RRB-

LIP

ENS

Lyon

pp

-LCB-

-LCB-

Lyon

France

septembre

-LSB-

-RSB-

Tanenbaum

-LRB-

A.

-RRB-

-LCB-

Syst?emes

d'exploitation

syst?emes

centralis?es

syst?emes

distribu?es

-LCB-

InterEditions

-LRB-

Paris

-RRB-

Prentice

Hall

-LRB-

London

-RRB-

-LSB-

-RSB-

Thinking

Machines

Corp.

First

St.

Cambridge

MA

-LCB-

C

programming

guide

novembre

Version

Number

-LSB-

-RSB-

Utard

-LRB-

G.

-RRB-

-LCB-

Compilation

of

data-parallel

programs

into

PVM

code

for

local

area

network

of

workstations

In

EuroPVM

ed

par

Dongarra

-LRB-

J.

-RRB-

Gengler

-LRB-

M.

-RRB-

Tourancheau

-LRB-

B.

-RRB-

et

Vigouroux

-LRB-

X.

-RRB-

LIP

ENS

Lyon

pp.

-LCB-

-LCB-

Lyon

France

septembre

compilation
multithreaded environment
threads

data parallel languages
experimental cost study