Changeset fb6691a for doc/theses/mubeen_zulfiqar_MMath/benchmarks.tex

Timestamp:

May 20, 2022, 2:48:24 PM (2 years ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

ADT, ast-experimental, master, pthread-emulation, qualifiedEnum

Children:

598dc68

Parents:

25fa20a

Message:

final proofread of Mubeen's MMath thesis

File:

• doc/theses/mubeen_zulfiqar_MMath/benchmarks.tex (modified) (6 diffs)

doc/theses/mubeen_zulfiqar_MMath/benchmarks.tex

@@ -48 +48 @@
 There is no interaction among threads, \ie no object sharing.
 Each thread repeatedly allocates 100,000 \emph{8-byte} objects then deallocates them in the order they were allocated.
-\PAB{Execution time of the benchmark evaluates its efficiency.}
+The execution time of the benchmark evaluates its efficiency.
 
 
@@ -75 +75 @@
 \label{s:ChurnBenchmark}
 
-The churn benchmark measures the runtime speed of an allocator in a multi-threaded scenerio, where each thread extensively allocates and frees dynamic memory.
+The churn benchmark measures the runtime speed of an allocator in a multi-threaded scenario, where each thread extensively allocates and frees dynamic memory.
 Only @malloc@ and @free@ are used to eliminate any extra cost, such as @memcpy@ in @calloc@ or @realloc@.
 Churn simulates a memory intensive program and can be tuned to create different scenarios.
@@ -133 +133 @@
 When threads share a cache line, frequent reads/writes to their cache-line object causes cache misses, which cause escalating delays as cache distance increases.
 
-Cache thrash tries to create a scenerio that leads to false sharing, if the underlying memory allocator is allocating dynamic memory to multiple threads on the same cache lines.
+Cache thrash tries to create a scenario that leads to false sharing, if the underlying memory allocator is allocating dynamic memory to multiple threads on the same cache lines.
 Ideally, a memory allocator should distance the dynamic memory region of one thread from another.
 Having multiple threads allocating small objects simultaneously can cause a memory allocator to allocate objects on the same cache line, if its not distancing the memory among different threads.
@@ -201 +201 @@
 Cache scratch tries to create a scenario that leads to false sharing and should make the memory allocator preserve the program-induced false sharing, if it does not return a freed object to its owner thread and, instead, re-uses it instantly.
 An allocator using object ownership, as described in section \VRef{s:Ownership}, is less susceptible to allocator-induced passive false-sharing.
-\PAB{If the object is returned to the thread that owns it, then the new object that the thread gets is less likely to be on the same cache line.}
+If the object is returned to the thread that owns it, then the new object that the thread gets is less likely to be on the same cache line.
 
 \VRef[Figure]{fig:benchScratchFig} shows the pseudo code for the cache-scratch micro-benchmark.
@@ -245 +245 @@
 
 Similar to benchmark cache thrash in section \VRef{sec:benchThrashSec}, different cache access scenarios can be created using the following command-line arguments.
-\begin{description}[itemsep=0pt,parsep=0pt]
+\begin{description}[topsep=0pt,itemsep=0pt,parsep=0pt]
 \item[threads:]
 number of threads (K).
@@ -259 +259 @@
 \subsection{Speed Micro-Benchmark}
 \label{s:SpeedMicroBenchmark}
+\vspace*{-4pt}
 
 The speed benchmark measures the runtime speed of individual and sequences of memory allocation routines:
-\begin{enumerate}[itemsep=0pt,parsep=0pt]
+\begin{enumerate}[topsep=-5pt,itemsep=0pt,parsep=0pt]
 \item malloc
 \item realloc