Changeset 918e0137 for doc/theses/thierry_delisle_PhD/thesis/text/conclusion.tex

Timestamp:

Sep 8, 2022, 5:11:19 PM (21 months ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, ast-experimental, master, pthread-emulation

Children:

264f6c9

Parents:

e4855f6

Message:

First pass at spellchecking until chapter 2

File:

• doc/theses/thierry_delisle_PhD/thesis/text/conclusion.tex (modified) (1 diff)

doc/theses/thierry_delisle_PhD/thesis/text/conclusion.tex

@@ -9 +9 @@
 However, I discovered two significant challenges.
 
-First, modern symmetric multiprocessing CPU have significant performance penalties for communication (often cache related).
+First, modern symmetric multiprocessing CPU have significant performance penalties for communicationm, often cache related.
 A SQMS scheduler (see Section~\ref{sched}), with its \proc-shared ready-queue, has perfect load-balancing but poor affinity resulting in high communication across \procs.
 A MQMS scheduler, with its \proc-specific ready-queues, has poor load-balancing but perfect affinity often resulting in significantly reduced communication.
 However, implementing fairness for an MQMS scheduler is difficult, since fairness requires \procs to be aware of each other's ready-queue progress, \ie communicated knowledge.
-For balanced workloads with little or no data sharing (embarrassingly parallel), an MQMS scheduler, \eg a state-of-the-art work-stealing scheduler, is near optimal.
+For balanced workloads with little or no data sharing, \ie embarrassingly parallel, an MQMS scheduler is near optimal, \eg a state-of-the-art work-stealing scheduler.
 For these kinds of fair workloads, adding fairness must be low-cost to hide the communication costs needed for global ready-queue progress or performance suffers.
 While I was aware of these realities, I underestimated how little performance margin there is for communication.