-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrapport.tex
124 lines (95 loc) · 4.39 KB
/
rapport.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
\documentclass[a4paper]{article}
\usepackage[french]{babel}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{fullpage}
\usepackage{pgf}
\usepackage{tikz}
\usetikzlibrary{arrows,automata}
\usetikzlibrary{positioning}
\begin{document}
\title{Réseaux de Kahn : différents choix pour différentes
implémentations }
\author{Antonin Delpeuch et Thomas Bourgeat}
\date{\today}
\maketitle
\section{Séquentielle}
Dans cette implémentation, nous avons utilisé un type en quelque sortes "glaçon". Ceci
nous permet de différencier un calcul qui est une valeur d'un calcul
non-terminé.
Ensuite durant un doco, on fait en sorte d'executer étape par étape les
processus dans le but d'avoir la liste des processus qui sont des
valeurs. Les évaluations se font circulairement, dans le but d'effectuer
une distribution juste : donc un processus dont on vient de faire une
étape va faire la queue pour qu'on lui fasse faire une deuxième étape.
\section{Processus lourds}
\section{Sockets}
\subsection{Utilisation}
Pour utiliser cette implémentation il va falloir lancer
l'application sur plusieurs machines : une machine initialisatrice, et
des machines disponibles pour executer des processus. Toutes ces machines seront
interconnectées avec une architecture décentralisée, il faut donc
qu'elles connaissent toutes la liste des ip des machines qui vont servir
au calcul.
Pour lancer les clients on utilise \texttt{./example.native c
fichiermachine p} qui
permet de lancer le client en attente de code à executer sur le port p.
Pour lancer l'application initiatrice, on execute \texttt{./example.native s
fichiermachine}
Pour créer le fichier fichiermachine, on pourra utiliser l'application
fournie \texttt{./example.native g nbrmachines fichiermachine} qui demandera à
l'utilisateur le nom des machines ainsi que les ports utilisés pour la
communication de code.
\subsection{Architecture globale}
La structure choisie est la suivante : au départ il y a disymétrie: une
machine est initialisatrice, et les autres sont des clients en attente de
calcul. Mais quand une machine commence à executer du calcul elle peut
alors diffuser à n'importe quelle autre machine du calcul. Le doco est la seule étape de
parallelisation.
Il y a donc deux types de communications : les communications de code, et
les communication de données.
Pour les channels, étant donné qu'une machine A peut créer un channel de
communication qui servira entre les machines B et C, nous avons décidés
de faire une architecture simple : A est un serveur pour ce channel.
Quand B veut parler à C, il parle en fait à A, et A retransmet à C.
Nous avons décidé de faire un put bloquant dans cette implémentation.
Le protocole de communication sur le canal choisit est le suivant :
Si B communique avec C dans un channel crée par A ; du point de vue de A, deux cas sont
possibles. Soit un get arrive en premier:
\begin{itemize}
\item C fait un get.
\item On attends un put de B.
\item C confirme que tout s'est bien passé à B
\end{itemize}
Ou alors un put arrive en premier :
\begin{itemize}
\item B fait un put.
\item On attends un get de C
\item C confirme que tout s'est bien passé, et l'étape s'est bien
déroulé.
\end{itemize}
Bien entendu ce protocol naif empeche le put/put/get/get, mais il est
possible de faire un put bloquant comme dans ce dernier schéma
uniquement lorsqu'un buffer est plein (qui donc est ici de taille 1). Cependant nous avons décidé de ne
pas nous attarder sur ces détails et plutot d'essayer divers autres
stratégies de communication.
D'autre parts, nous avons choisi d'utiliser le modèle suivant :\\
Connection-Lecture/Écriture-Déconnection \\
De ce fait, on effectue un grand nombre de connections. Cependant le
serveur du channel reste toujours en écoute, sur la meme socket. Ceci
limite donc un minimum la lourdeur du protocole.
\section{Résultats}
Dans le but de comparer la verbosité des différentes implémentations
nous avons executés le compteur sur une architecture simple coeur
\footnote{AMD V120-2.2 Ghz}, avec
les différentes implémentations, ceci durant 10 secondes.
Les valeurs atteintes sont les suivantes: \\
Seq : 515724\\
Threads: 409080\\
Processus lourds: 5621\\
Sockets : 23723\\
On remarquera que bien sur sur des machines multi-coeurs,
l'implémentation processus lourds remonte nettement en performance.
Cependant elle reste anormalement lente.
\section{Performances}
\end{document}