typos

report/document.tex

@@ -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,11 +273,11 @@ 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
+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!]