typos
This commit is contained in:
parent
7043d65423
commit
1f60916f09
1 changed files with 25 additions and 25 deletions
|
@ -78,13 +78,13 @@ de \texttt{quicksort.c}. Elle lance les tâches sans threads.
|
|||
Cette implémentation correspond à simplement démarrer un nouveau thread
|
||||
pour chaque nouvelle tâche.
|
||||
|
||||
Comme cette implémentation n'ordonnance rien et que le nombre de threads créer
|
||||
Comme cette implémentation n'ordonnance rien et que le nombre de threads créés
|
||||
est important.
|
||||
|
||||
\subsection{Threads avec pile}\label{desc:th_pile}
|
||||
Pour cette implémentation, nous gardons en mémoire une pile,
|
||||
et nous démarrons un nombre fixe de threads et à chaque ajout d'une tâche,
|
||||
le thread l'empile. Chaque thread récupère la dernière tâche ajoutée à la pile.
|
||||
Pour cette implémentation, nous gardons en mémoire une pile et nous démarrons
|
||||
un nombre fixe de threads, et à chaque ajout d'une tâche, le thread l'empile.
|
||||
Chaque thread récupère la dernière tâche ajoutée à la pile.
|
||||
|
||||
\subsubsection{Sélection aléatoire de tâche}
|
||||
Même fonctionnement que dans l'algorithme de \docref{desc:th_pile}, sauf
|
||||
|
@ -92,8 +92,8 @@ qu'au lieu de récupérer la dernière tâche, le thread récupère une tâche
|
|||
aléatoire de la pile.
|
||||
|
||||
\subsection{Répartition par \ws}\label{desc:ws}
|
||||
Ici, chaque \coeur~a sa propre liste de tâche. Quand un thread n'as
|
||||
plus de tâche, il essaie d'en voler une à un autre thread.
|
||||
Ici, chaque \coeur~a sa propre liste de tâches. Quand un thread n'a
|
||||
plus de tâches, il essaie d'en voler une à un autre thread.
|
||||
|
||||
|
||||
\section{Comportement}
|
||||
|
@ -110,9 +110,9 @@ un vol, c'est le dernier élément qui est récupéré par le thread.
|
|||
Dans mes implémentations, j'ai exclusivement utilisé des mutex ainsi que des
|
||||
variables de conditions pour endormir/réveiller mes threads.
|
||||
|
||||
Pendant le développement j'ai parfois utilisé \texttt{usleep} au lieu des
|
||||
Pendant le développement, j'ai parfois utilisé \texttt{usleep} au lieu des
|
||||
variables de conditions pour faire attendre les threads, mais j'ai obtenu de
|
||||
meilleurs résultats avec les variables de conditions. Aussi je pense qu'avoir
|
||||
meilleurs résultats avec les variables de conditions. Aussi, je pense qu'avoir
|
||||
les variables de conditions m'assure que mon ordonnanceur fonctionne sur
|
||||
n'importe quel CPU, qu'il soit lent ou rapide, avec des performances honnêtes.
|
||||
En effet, choisir une valeur qui fonctionne bien sur mon ordinateur n'assure pas
|
||||
|
@ -122,11 +122,11 @@ qu'elle soit la meilleure pour un autre.
|
|||
Pour avoir un programme performant, il faut équilibrer le nombre de threads par
|
||||
rapport aux nombres de \coeur{}s disponibles. Il faut également équilibrer la
|
||||
création de nouvelles tâches par thread par rapport au véritable travail
|
||||
effectué par ledit thread. Par exemple dans le \btwo, chaque tâche soit créer 4
|
||||
nouvelles tâches, soit calcule une portion de l'image. Une plus grande création
|
||||
de tâche favorise le \ws~parce qu'une pile unique atteint ses limites quand
|
||||
trop de tâches est ajouté, car les threads n'ont pas le temps "d'abattre
|
||||
le travail" assez rapidement.
|
||||
effectué par ledit thread. Par exemple, dans le \btwo, chaque tâche soit crée
|
||||
quatre nouvelles tâches, soit calcule une portion de l'image. Une plus grande
|
||||
création de tâches favorise le \ws~parce qu'une pile unique atteint ses limites
|
||||
quand trop de tâches sont ajoutées, car les threads n'ont pas le temps
|
||||
"d'abattre le travail" assez rapidement.
|
||||
|
||||
\section{Statistiques}
|
||||
|
||||
|
@ -138,8 +138,8 @@ de \texttt{gcc}, sur 2 machines.
|
|||
\item \textbf{8 \coeur{}s} pour la \mtwo.
|
||||
\end{enumerate}
|
||||
|
||||
Le programme utilisé pour tester les implémentations sont le quicksort fourni
|
||||
et une adaptation de mandelbrot fournis dans le TP10.
|
||||
Le programme utilisé pour tester les implémentations est le quicksort fourni
|
||||
et une adaptation de mandelbrot fournie dans le TP10.
|
||||
|
||||
\subsection{Séquentiel}\label{stats:seq}
|
||||
\begin{description}
|
||||
|
@ -183,13 +183,13 @@ Ce programme ne bénéficie pas de toute la puissance de la machine.
|
|||
\end{description}
|
||||
\end{description}
|
||||
|
||||
La création des threads pour chaque tâche créer un énorme
|
||||
La création des threads pour chaque tâche crée un énorme
|
||||
goulot d'étranglement qui réduit de grandement les performances.
|
||||
|
||||
Le temps d'exécution étant long, nous pouvons voir les threads via la commande
|
||||
\texttt{top} : \mintinline{bash}|top -Hp $(pgrep ordonnanceur)|.
|
||||
|
||||
Pour augmenter les performances, il faut avoir une taille fixe de threads créer,
|
||||
Pour augmenter les performances, il faut avoir une taille fixe de threads crée,
|
||||
et donc il faut gérer les tâches et décider de quelle tâche va sur quel thread.
|
||||
|
||||
\subsection{Threads avec pile}\label{stats:stack}
|
||||
|
@ -211,16 +211,16 @@ et donc il faut gérer les tâches et décider de quelle tâche va sur quel thre
|
|||
\end{description}
|
||||
\end{description}
|
||||
|
||||
Le lancement de nouveau thread étant limité, les performances
|
||||
Le lancement de nouveaux threads étant limité, les performances
|
||||
sont grandement améliorées par rapport aux tests de \docref{stats:th_ges}.
|
||||
|
||||
Également grâce au fait que désormais nous utilisons les \coeur{}s~de notre CPU,
|
||||
Également, grâce au fait que désormais nous utilisons les \coeur{}s~de notre CPU,
|
||||
les performances sont aussi améliorées par rapport aux tests de
|
||||
\docref{stats:seq}.
|
||||
|
||||
Dans la \autoref{fig:btm-lifo}, nous observons que les \coeur{}s du CPU ne sont pas
|
||||
tous utilisé à 100\%. Ceci est dû au fait que l'accès à la liste des tâches est
|
||||
limité, car partagé entres les threads.
|
||||
tous utilisés à 100 \%. Ceci est dû au fait que l'accès à la liste des tâches est
|
||||
limité, car partagé entre les threads.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
|
@ -250,7 +250,7 @@ limité, car partagé entres les threads.
|
|||
|
||||
Cette implémentation est identique à \docref{stats:stack}, à l'exception que
|
||||
les threads récupèrent une tâche aléatoire de la pile au lieu d'y prendre
|
||||
la dernière ajouté.
|
||||
la dernière ajoutée.
|
||||
|
||||
Cette façon de faire réduit les performances.
|
||||
|
||||
|
@ -273,12 +273,12 @@ Cette façon de faire réduit les performances.
|
|||
\end{description}
|
||||
\end{description}
|
||||
|
||||
Dans cet implémentation, nous n'utilisons plus une pile mais un deque de tâches.
|
||||
Dans cette implémentation, nous n'utilisons plus une pile, mais un deque de tâches.
|
||||
Cette façon de faire est légèrement meilleur que \docref{desc:th_pile}.
|
||||
|
||||
Dans la \autoref{fig:btm-ws}, nous observons que les \coeur{}s du CPU sont
|
||||
proche de 100\% d'utilisation. Comparé à \docref{stats:stack}, nous gagnons
|
||||
en moyenne \approx~10\% de l'utilisation du processeur dans son entièreté.
|
||||
proches de 100 \% d'utilisation. Comparé à \docref{stats:stack}, nous gagnons
|
||||
en moyenne \approx~10 \% de l'utilisation du processeur dans son entièreté.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
|
|
Reference in a new issue