Ignore:
Timestamp:
Jul 11, 2023, 9:25:01 AM (11 months ago)
Author:
caparsons <caparson@…>
Branches:
master
Children:
39e6309
Parents:
614868b
Message:

actor perf cleanup following reordering

Location:
doc/theses/colby_parsons_MMAth
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/colby_parsons_MMAth/local.bib

    r614868b rea1bb94  
    196196  year={2004}
    197197}
     198
     199@manual{IntelManual,
     200    keywords    = {Intel},
     201    title       = {Intel 64 and IA-32 Architectures Software Developer’s Manual},
     202    version = {Version 080},
     203    organization= {Intel},
     204    month       = March,
     205    year        = 2023,
     206}
  • doc/theses/colby_parsons_MMAth/text/actors.tex

    r614868b rea1bb94  
    752752The values swapped are never null pointers, so a null pointer can be used as an intermediate value during the swap.
    753753\end{enumerate}
    754 Figure~\ref{c:swap} shows the \CFA pseudocode for the \gls{dcasw}.
     754Figure~\ref{f:dcaswImpl} shows the \CFA pseudocode for the \gls{dcasw}.
    755755In detail, a thief performs the following steps to swap two pointers:
    756756\begin{enumerate}[start=0]
     
    765765Since each worker owns a disjoint range of the queue array, it is impossible for @my_queue@ to be null.
    766766Note, this algorithm is simplified due to each worker owning a disjoint range, allowing only the @vic_queue@ to be checked for null.
    767 This was not listed as a special case of this algorithm, since this requirement can be avoided by modifying Step 1 of Figure~\ref{c:swap} to also check @my_queue@ for null.
     767This was not listed as a special case of this algorithm, since this requirement can be avoided by modifying Step 1 of Figure~\ref{f:dcaswImpl} to also check @my_queue@ for null.
    768768Further discussion of this generalization is omitted since it is not needed for the presented application.
    769769\item
     
    811811\end{cfa}
    812812\caption{DCASW Concurrent}
    813 \label{c:swap}
     813\label{f:dcaswImpl}
    814814\end{figure}
    815815
     
    817817\gls{dcasw} is correct in both the success and failure cases.
    818818\end{theorem}
    819 To verify sequential correctness, Figure~\ref{s:swap} shows a simplified \gls{dcasw}.
     819To verify sequential correctness, Figure~\ref{f:seqSwap} shows a simplified \gls{dcasw}.
    820820Step 1 is missing in the sequential example since it only matters in the concurrent context.
    821821By inspection, the sequential swap copies each pointer being swapped, and then the original values of each pointer are reset using the copy of the other pointer.
     
    836836\end{cfa}
    837837\caption{DCASW Sequential}
    838 \label{s:swap}
     838\label{f:seqSwap}
    839839\end{figure}
    840840
     
    895895First it is important to state that a thief will not attempt to steal from themselves.
    896896As such, the victim here is not also a thief.
    897 Stepping through the code in \ref{c:swap}, for all thieves steps 0-1 succeed since the victim is not stealing and will have no queue pointers set to be @0p@.
     897Stepping through the code in \ref{f:dcaswImpl}, for all thieves steps 0-1 succeed since the victim is not stealing and will have no queue pointers set to be @0p@.
    898898Similarly for all thieves step 2 will succeed since no one is stealing from any of the thieves.
    899899In step 3 the first thief to @CAS@ will win the race and successfully swap the queue pointer.
     
    991991
    992992The longest-victim heuristic maintains a timestamp per executor thread that is updated every time a worker attempts to steal work.
    993 The timestamps are generated using @rdtsc@~\cite{} and are stored in a shared array, with one index per worker.
     993The timestamps are generated using @rdtsc@~\cite{IntelManual} and are stored in a shared array, with one index per worker.
    994994Thieves then attempt to steal from the worker with the oldest timestamp.
    995995The intuition behind this heuristic is that the slowest worker will receive help via work stealing until it becomes a thief, which indicates that it has caught up to the pace of the rest of the workers.
    996 This heuristic means that if two thieves look to steal at the same time, they likely attempt to steal from the same victim.
     996This heuristic should ideally result in lowered latency for message sends to victim workers that are overloaded with work.
     997However, a side-effect of this heuristic is that if two thieves look to steal at the same time, they likely attempt to steal from the same victim.
    997998This approach consequently does increase the chance at contention among thieves;
    998999however, given that workers have multiple queues, often in the tens or hundreds of queues, it is rare for two thieves to attempt stealing from the same queue.
Note: See TracChangeset for help on using the changeset viewer.