Context Navigation

← Previous Change
Next Change →

actors.tex

Timestamp:

Apr 3, 2023, 1:34:02 PM (17 months ago)

Author:

caparsons <caparson@…>

Branches:

ADT, ast-experimental, master

Children:

1689ecf

Parents:

48fda7a

Message:

Big cleanup pass. Updated style to get rid of almost all macros. Reformated thesis to match current template. Added newlines at the end of all sentences. Reworked terminology and acronyms to fit new glossary format

File:

: 1 edited

doc/theses/colby_parsons_MMAth/text/actors.tex (modified) (24 diffs)

Legend:

: Unmodified
: Added
: Removed

doc/theses/colby_parsons_MMAth/text/actors.tex

-                      r48fda7a
+                      r9a5a2cd
 % C_TODO: add citations throughout chapter
+Actors are a concurrent feature that abstracts threading away from a user, and instead provides \newterm{actors} and \newterm{messages} as building blocks for concurrency. Actors are another message passing concurrency feature, similar to channels, but with more abstraction. Actors enter the realm of what is called \newterm{implicit concurrency}, where programmers can write concurrent code without having to worry about explicit thread synchronization and mutual exclusion. The study of actors can be broken into two concepts, the \newterm{actor model}, which describes the model of computation and the \newterm{actor system}, which refers to the implementation of the model in practice. Before discussing \CFA's actor system in detail, it is important to first describe the actor model, and the classic approach to implementing an actor system.
+Actors are a concurrent feature that abstracts threading away from a user, and instead provides \gls{actor}s and messages as building blocks for concurrency.
+Actors are another message passing concurrency feature, similar to channels, but with more abstraction.
+Actors enter the realm of what is called \gls{impl_concurrency}, where programmers can write concurrent code without having to worry about explicit thread synchronization and mutual exclusion.
+The study of actors can be broken into two concepts, the \gls{actor_model}, which describes the model of computation and the \gls{actor_system}, which refers to the implementation of the model in practice.
+Before discussing \CFA's actor system in detail, it is important to first describe the actor model, and the classic approach to implementing an actor system.
 \section{The Actor Model}
+The actor model is a paradigm of concurrent computation, where tasks are broken into units of work that are distributed to actors in the form of messages \cite{Hewitt73}. Actors execute asynchronously upon receiving a message and can modify their own state, make decisions, spawn more actors, and send messages to other actors. The actor model is an implicit model of concurrency. As such, one strength of the actor model is that it abstracts away many considerations that are needed in other paradigms of concurrent computation. Mutual exclusion, and locking are rarely relevant concepts to users of an actor model, as actors typically operate on local state.
+The actor model is a paradigm of concurrent computation, where tasks are broken into units of work that are distributed to actors in the form of messages \cite{Hewitt73}.
+Actors execute asynchronously upon receiving a message and can modify their own state, make decisions, spawn more actors, and send messages to other actors.
+The actor model is an implicit model of concurrency.
+As such, one strength of the actor model is that it abstracts away many considerations that are needed in other paradigms of concurrent computation.
+Mutual exclusion, and locking are rarely relevant concepts to users of an actor model, as actors typically operate on local state.
 \section{Classic Actor System}
+An implementation of the actor model with a community of actors is called an actor system. Actor systems largely follow the actor model, but differ in some ways. While the definition of the actor model provides no restrictions on message ordering, actor systems tend to guarantee that messages sent from a given actor $i$ to actor $j$ will arrive at actor $j$ in the order they were sent. Another way an actor system varies from the model is that actors are often allowed to access non-local state. When this occurs it can complicate the implementation as this will break any mutual exclusion guarantees given by accessing only local state.
+An implementation of the actor model with a community of actors is called an actor system.
+Actor systems largely follow the actor model, but differ in some ways.
+While the definition of the actor model provides no restrictions on message ordering, actor systems tend to guarantee that messages sent from a given actor $i$ to actor $j$ will arrive at actor $j$ in the order they were sent.
+Another way an actor system varies from the model is that actors are often allowed to access non-local state.
+When this occurs it can complicate the implementation as this will break any mutual exclusion guarantees given by accessing only local state.
 \begin{figure}
 …
 \section{\CFA Actors}
+Actor systems \cite{} have often been implemented as an actor-centric system. As such they are constructed as a set of actors that are scheduled and run on some underlying threads. Each actor has their own queue for receiving messages, sometimes called a mailbox. When they receive messages in their mailbox, actors are moved from idle to ready queues and then scheduled on a thread to run their unit of work. This approach can be implemented with a global queue of actors, but is often implemented as each worker thread owning a queue of actors. This is known as sharding the actor queue, which is done to decrease contention across worker threads. A diagram of an actor-centric system with a sharded actor queue is shown in Figure \ref{f:standard_actor}.
+Actor systems \cite{} have often been implemented as an actor-centric system.
+As such they are constructed as a set of actors that are scheduled and run on some underlying threads.
+Each actor has their own queue for receiving messages, sometimes called a mailbox.
+When they receive messages in their mailbox, actors are moved from idle to ready queues and then scheduled on a thread to run their unit of work.
+This approach can be implemented with a global queue of actors, but is often implemented as each worker thread owning a queue of actors.
+This is known as sharding the actor queue, which is done to decrease contention across worker threads.
+A diagram of an actor-centric system with a sharded actor queue is shown in Figure \ref{f:standard_actor}.
 % cite parallel theatre and our paper
+The actor system in \CFA is instead message-centric, an uses what is called an inverted actor system \cite{}. In this inverted actor system instead of each worker thread owning a queue of actors, they each own a queue of messages. This system is called inverted since in this scheme, actors belong to a message queue, whereas in the classic approach a message queue belongs to each actor. Since multiple actors belong to each message queue, messages to each actor are interleaved in the queue. In this scheme work is consumed from their queue and executed by underlying threads. In High-Performance Extended Actors \cite{} this inverted model is taken a step further and the message queues are sharded, so that each worker now instead owns a set of queues. A diagram of an inverted actor scheme with a sharded message queue is shown in Figure \ref{f:inverted_actor}. The arrows from the message queues to the actors in the diagram indicate interleaved messages addressed to each actor.
+The actor system in \CFA is instead message-centric, an uses what is called an inverted actor system \cite{}.
+In this inverted actor system instead of each worker thread owning a queue of actors, they each own a queue of messages.
+This system is called inverted since in this scheme, actors belong to a message queue, whereas in the classic approach a message queue belongs to each actor.
+Since multiple actors belong to each message queue, messages to each actor are interleaved in the queue.
+In this scheme work is consumed from their queue and executed by underlying threads.
+In High-Performance Extended Actors \cite{} this inverted model is taken a step further and the message queues are sharded, so that each worker now instead owns a set of queues.
+A diagram of an inverted actor scheme with a sharded message queue is shown in Figure \ref{f:inverted_actor}.
+The arrows from the message queues to the actors in the diagram indicate interleaved messages addressed to each actor.
 The actor system in \CFA builds on top of the architecture laid out in High-Performance Extended Actors \cite{} and adds the following contributions:
 …
 \begin{enumerate}[topsep=5pt,itemsep=3pt,parsep=0pt]
 \item
+Provides insight into the impact of envelope allocation in actor systems. In all actor systems dynamic allocation is needed to ensure that the lifetime of a unit of work persists from its creation until the unit of work is executed. This allocation is often called an envelope as it "packages" the information needed to run the unit of work, alongside any other information needed to send the unit of work, such as an actor's address or link fields for a list. This dynamic allocation occurs once per message sent. This is a large source of contention on the memory allocator since all these allocations occur concurrently. A novel data structure is used to consolidate allocations to improve performance by minimizing contention on the allocator.
+\item
+Introduces work stealing in the inverted actor system. Work stealing in actor-centric systems tends to involve stealing one or more actors. In the inverted system the notion of stealing queues is introduced. The queue stealing is implemented such that the act of stealing work does not contend with non-stealing actors that are saturated with work.
+Provides insight into the impact of envelope allocation in actor systems.
+In all actor systems dynamic allocation is needed to ensure that the lifetime of a unit of work persists from its creation until the unit of work is executed.
+This allocation is often called an envelope as it "packages" the information needed to run the unit of work, alongside any other information needed to send the unit of work, such as an actor's address or link fields for a list.
+This dynamic allocation occurs once per message sent.
+This is a large source of contention on the memory allocator since all these allocations occur concurrently.
+A novel data structure is used to consolidate allocations to improve performance by minimizing contention on the allocator.
+\item
+Introduces work stealing in the inverted actor system.
+Work stealing in actor-centric systems tends to involve stealing one or more actors.
+In the inverted system the notion of stealing queues is introduced.
+The queue stealing is implemented such that the act of stealing work does not contend with non-stealing actors that are saturated with work.
 \item
 …
 \section{\CFA Actor Syntax}
+\CFA is not an object oriented language and it does not have run-time type information (RTTI). As such all message sends and receives between actors occur using exact type matching. To use actors in \CFA you must \code{\#include <actors.hfa>}. To create an actor type one must define a struct which inherits from the base \code{actor} struct via the \code{inline} keyword. This is the Plan-9 C-style nominal inheritance discussed in Section \ref{s:poly}. Similarly to create a message type a user must define a struct which \code{inline}'s the base \code{message} struct.
+\CFA is not an object oriented language and it does not have run-time type information (RTTI).
+As such all message sends and receives between actors occur using exact type matching.
+To use actors in \CFA you must \code{\#include <actors.hfa>}.
+To create an actor type one must define a struct which inherits from the base \code{actor} struct via the \code{inline} keyword.
+This is the Plan-9 C-style nominal inheritance discussed in Section \ref{s:poly}.
+Similarly to create a message type a user must define a struct which \code{inline}'s the base \code{message} struct.
 \begin{cfacode}
 …
 \end{cfacode}
+The above code is a simple actor program in \CFA. There is one derived actor type and one derived message type. A single message containing a string is sent from the program main to an actor. Key things to highlight include the \code{receive} signature, and calls to \code{start_actor_system}, and \code{stop_actor_system}. To define a behaviour for some derived actor and derived message type, one must declare a routine with the signature:
+The above code is a simple actor program in \CFA.
+There is one derived actor type and one derived message type.
+A single message containing a string is sent from the program main to an actor.
+Key things to highlight include the \code{receive} signature, and calls to \code{start_actor_system}, and \code{stop_actor_system}.
+To define a behaviour for some derived actor and derived message type, one must declare a routine with the signature:
 \begin{cfacode}
 Allocation receive( derived_actor & receiver, derived_msg & msg )
 \end{cfacode}
+Where \code{derived_actor} and \code{derived_msg} can be any derived actor and derived message types respectively. The return value of \code{receive} must be a value from the \code{Allocation} enum:
+Where \code{derived_actor} and \code{derived_msg} can be any derived actor and derived message types respectively.
+The return value of \code{receive} must be a value from the \code{Allocation} enum:
 \begin{cfacode}
 enum Allocation { Nodelete, Delete, Destroy, Finished };
 \end{cfacode}
+The \code{Allocation} enum is a set of actions that dictate what the executor should do with a message or actor after a given behaviour has been completed. In the case of an actor, the \code{receive} routine returns the \code{Allocation} status to the executor which sets the status on the actor and takes the appropriate action. For messages, they either default to \code{Nodelete}, or they can be passed an \code{Allocation} via the \code{message} constructor. Message state can be updated via a call to:
+The \code{Allocation} enum is a set of actions that dictate what the executor should do with a message or actor after a given behaviour has been completed.
+In the case of an actor, the \code{receive} routine returns the \code{Allocation} status to the executor which sets the status on the actor and takes the appropriate action.
+For messages, they either default to \code{Nodelete}, or they can be passed an \code{Allocation} via the \code{message} constructor.
+Message state can be updated via a call to:
 \begin{cfacode}
 void set_allocation( message & this, Allocation state )
 …
 \begin{description}
 \item[\LstBasicStyle{\textbf{Nodelete}}]
+tells the executor that no action is to be taken with regard to a message or actor with this status. This indicates that the actor will receive future behaviours, and that a message may be reused.
+tells the executor that no action is to be taken with regard to a message or actor with this status.
+This indicates that the actor will receive future behaviours, and that a message may be reused.
 \item[\LstBasicStyle{\textbf{Delete}}]
+tells the executor to call the appropriate destructor and then deallocate the respective actor or message. This status is typically used with dynamically allocated actors and messages.
+tells the executor to call the appropriate destructor and then deallocate the respective actor or message.
+This status is typically used with dynamically allocated actors and messages.
 \item[\LstBasicStyle{\textbf{Destroy}}]
+tells the executor to call the object's destructor. The executor will not deallocate the respective actor or message. This status is typically used with dynamically allocated actors and messages whose storage will be reused.
+tells the executor to call the object's destructor.
+The executor will not deallocate the respective actor or message.
+This status is typically used with dynamically allocated actors and messages whose storage will be reused.
 \item[\LstBasicStyle{\textbf{Finished}}]
+tells the executor to mark the respective actor as being finished executing. In this case the executor will not call any destructors or deallocate any objects. This status is used when the actors are stack allocated or if the user wants to manage deallocation of actors themselves. In the case of messages, \code{Finished} is no different than \code{Nodelete} since the executor does not need to track if messages are done work. As such \code{Finished} is not supported for messages and is used internally by the executor to track if messages have been used for debugging purposes.
+tells the executor to mark the respective actor as being finished executing.
+In this case the executor will not call any destructors or deallocate any objects.
+This status is used when the actors are stack allocated or if the user wants to manage deallocation of actors themselves.
+In the case of messages, \code{Finished} is no different than \code{Nodelete} since the executor does not need to track if messages are done work.
+As such \code{Finished} is not supported for messages and is used internally by the executor to track if messages have been used for debugging purposes.
 \end{description}
+For the actor system to gracefully terminate, all actors must have returned a status other than \code{Nodelete}. Once an actor's allocation status has been set to something other than \code{Nodelete}, it is erroneous for the actor to receive a message. Similarly messages cannot be safely reused after their related behaviour if their status is not \code{Nodelete}. Note, it is safe to construct a message with a non-\code{Nodelete} status since the executor will only take the appropriate allocation action after a message has been delivered.
+The calls to \code{start_actor_system}, and \code{stop_actor_system} mark the start and end of a \CFA actor system. The call to \code{start_actor_system} sets up the executor and worker threads for the actor system. \code{start_actor_system} has three overloaded signatures which all start the actor system, but vary in executor configuration:
+For the actor system to gracefully terminate, all actors must have returned a status other than \code{Nodelete}.
+Once an actor's allocation status has been set to something other than \code{Nodelete}, it is erroneous for the actor to receive a message.
+Similarly messages cannot be safely reused after their related behaviour if their status is not \code{Nodelete}.
+Note, it is safe to construct a message with a non-\code{Nodelete} status since the executor will only take the appropriate allocation action after a message has been delivered.
+The calls to \code{start_actor_system}, and \code{stop_actor_system} mark the start and end of a \CFA actor system.
+The call to \code{start_actor_system} sets up the executor and worker threads for the actor system.
+\code{start_actor_system} has three overloaded signatures which all start the actor system, but vary in executor configuration:
 \noindent\code{void start_actor_system()} configures the executor with one underlying worker thread and processor.
+\noindent\code{void start_actor_system( size_t num_thds )} configures the executor with \code{num_thds} underlying processors and \code{num_thds} worker threads. It chooses amount of queue sharding as a function of \code{num_thds}.
+\noindent\code{void start_actor_system( executor & this )} allows the user to allocate, configure, and pass an executor so that they have full control of executor parameterization. Executor configuration options include number of worker threads, number of queues, number of processors, and a few other toggles.
+\noindent\code{void start_actor_system( size_t num_thds )} configures the executor with \code{num_thds} underlying processors and \code{num_thds} worker threads.
+It chooses amount of queue sharding as a function of \code{num_thds}.
+\noindent\code{void start_actor_system( executor & this )} allows the user to allocate, configure, and pass an executor so that they have full control of executor parameterization.
+Executor configuration options include number of worker threads, number of queues, number of processors, and a few other toggles.
 All actors must be created after calling \code{start_actor_system} so that the executor can keep track of the number of actors that have been allocated but have not yet terminated.
+All message sends are done using the left shift operater, \ie <<, similar to the syntax of \CC's output. The signature of the left shift operator is:
+All message sends are done using the left shift operater, \ie <<, similar to the syntax of \CC's output.
+The signature of the left shift operator is:
 \begin{cfacode}
 Allocation ?<<?( derived_actor & receiver, derived_msg & msg )
 \end{cfacode}
+An astute eye will notice that this is the same signature as the \code{receive} routine which is no coincidence. The \CFA compiler generates a \code{?<<?} routine definition and forward declaration for each \code{receive} routine that has the appropriate signature. The generated routine packages the message and actor in an \hyperref[s:envelope]{envelope} and adds it to the executor's queues via an executor routine. As part of packaging the envelope, the \code{?<<?} routine sets a function pointer in the envelope to point to the appropriate receive routine for given actor and message types.
+An astute eye will notice that this is the same signature as the \code{receive} routine which is no coincidence.
+The \CFA compiler generates a \code{?<<?} routine definition and forward declaration for each \code{receive} routine that has the appropriate signature.
+The generated routine packages the message and actor in an \hyperref[s:envelope]{envelope} and adds it to the executor's queues via an executor routine.
+As part of packaging the envelope, the \code{?<<?} routine sets a function pointer in the envelope to point to the appropriate receive routine for given actor and message types.
 \section{\CFA Executor}\label{s:executor}
+This section will describe the basic architecture of the \CFA executor. Any discussion of work stealing is omitted until Section \ref{s:steal}. The executor of an actor system is the scheduler that organizes where actors behaviours are run and how messages are sent and delivered. In \CFA the executor lays out actors across the sharded message queues in round robin order as they are created. The message queues are split across worker threads in equal chunks, or as equal as possible if the number of message queues is not divisible by the number of workers threads.
+This section will describe the basic architecture of the \CFA executor.
+Any discussion of work stealing is omitted until Section \ref{s:steal}.
+The executor of an actor system is the scheduler that organizes where actors behaviours are run and how messages are sent and delivered.
+In \CFA the executor lays out actors across the sharded message queues in round robin order as they are created.
+The message queues are split across worker threads in equal chunks, or as equal as possible if the number of message queues is not divisible by the number of workers threads.
 \begin{figure}
 …
 \end{figure}
+Each worker thread iterates over its own message queues until it finds one that contains messages. At this point the worker thread \newterm{gulps} the queue. A \newterm{gulp} is a term for consuming the contents of message queue and transferring them to the local queue of worker thread. After the gulp is done atomically, this allows the worker thread to process the queue locally without any need for atomicity until the next gulp. Messages can be added to the queue that was gulped in parallel with the processing of the local queue. Additionally, prior to each gulp, the worker non-atomically checks if a queue is empty before attempting to gulp it. Between this and the gulp, the worker avoids many potentially costly lock acquisitions. An example of the queue gulping operation is shown in Figure \ref{f:gulp} where a worker thread gulps queue 0 and begins to process it locally.
+To process its local queue, a worker thread takes each unit of work off the queue and executes it. Since all messages to a given actor will be in the same queue, this guarantees atomicity across behaviours of that actor since it can only execute on one thread at a time. After running behaviour, the worker thread looks at the returned allocation status and takes the corresponding action. Once all actors have marked themselves as being finished the executor initiates shutdown by inserting a sentinel value into the message queues. Once a worker thread sees a sentinel it stops running. After all workers stop running the actor system shutdown is complete.
+Each worker thread iterates over its own message queues until it finds one that contains messages.
+At this point the worker thread \textbf{gulps} the queue.
+A \textbf{gulp} is a term for consuming the contents of message queue and transferring them to the local queue of worker thread.
+After the gulp is done atomically, this allows the worker thread to process the queue locally without any need for atomicity until the next gulp.
+Messages can be added to the queue that was gulped in parallel with the processing of the local queue.
+Additionally, prior to each gulp, the worker non-atomically checks if a queue is empty before attempting to gulp it.
+Between this and the gulp, the worker avoids many potentially costly lock acquisitions.
+An example of the queue gulping operation is shown in Figure \ref{f:gulp} where a worker thread gulps queue 0 and begins to process it locally.
+To process its local queue, a worker thread takes each unit of work off the queue and executes it.
+Since all messages to a given actor will be in the same queue, this guarantees atomicity across behaviours of that actor since it can only execute on one thread at a time.
+After running behaviour, the worker thread looks at the returned allocation status and takes the corresponding action.
+Once all actors have marked themselves as being finished the executor initiates shutdown by inserting a sentinel value into the message queues.
+Once a worker thread sees a sentinel it stops running.
+After all workers stop running the actor system shutdown is complete.
 \section{Envelopes}\label{s:envelope}
+In actor systems messages are sent and received by actors. When a actor receives a message it  executes its behaviour that is associated with that message type. However the unit of work that stores the message, the receiving actor's address, and other pertinent information needs to persist between send and the receive. Furthermore the unit of work needs to be able to be stored in some fashion, usually in a queue, until it is executed by an actor. All these requirements are fulfilled by a construct called an envelope. The envelope wraps up the unit of work and also stores any information needed by data structures such as link fields. To meet the persistence requirement the envelope is dynamically allocated and cleaned up after it has been delivered and its payload has run.
+One may ask, "Could the link fields and other information be stored in the message?". This is a good question to ask since messages also need to have a lifetime that persists beyond the work it delivers. However, if one were to use messages as envelopes then a message would not be able to be sent to multiple actors at a time. Therefore this approach would just push the allocation into another location, and require the user to dynamically allocate a message for every send, or require careful ordering to allow for message reuse.
+This frequent allocation of envelopes with each message send between actors results in heavy contention on the memory allocator. As such, a way to alleviate contention on the memory allocator could result in performance improvement. Contention was reduced using a novel data structure that called a \newterm{copy queue}.
+In actor systems messages are sent and received by actors.
+When a actor receives a message it  executes its behaviour that is associated with that message type.
+However the unit of work that stores the message, the receiving actor's address, and other pertinent information needs to persist between send and the receive.
+Furthermore the unit of work needs to be able to be stored in some fashion, usually in a queue, until it is executed by an actor.
+All these requirements are fulfilled by a construct called an envelope.
+The envelope wraps up the unit of work and also stores any information needed by data structures such as link fields.
+To meet the persistence requirement the envelope is dynamically allocated and cleaned up after it has been delivered and its payload has run.
+One may ask, "Could the link fields and other information be stored in the message?".
+This is a good question to ask since messages also need to have a lifetime that persists beyond the work it delivers.
+However, if one were to use messages as envelopes then a message would not be able to be sent to multiple actors at a time.
+Therefore this approach would just push the allocation into another location, and require the user to dynamically allocate a message for every send, or require careful ordering to allow for message reuse.
+This frequent allocation of envelopes with each message send between actors results in heavy contention on the memory allocator.
+As such, a way to alleviate contention on the memory allocator could result in performance improvement.
+Contention was reduced using a novel data structure that is called a copy queue.
 \subsection{The Copy Queue}\label{s:copyQueue}
+The copy queue is a thin layer over a dynamically sized array that is designed with the envelope use case in mind. A copy queue supports the typical queue operations of push/pop but in a different way than a typical array based queue. The copy queue is designed to take advantage of the \hyperref[s:executor]{gulping} pattern. As such the amortized rutime cost of each push/pop operation for the copy queue is $O(1)$. In contrast, a naive array based queue often has either push or pop cost $O(n)$ and the other cost $O(1)$ since for at least one of the operations all the elements of the queue have to be shifted over. Since the worker threads gulp each queue to operate on locally, this creates a usage pattern of the queue where all elements are popped from the copy queue without any interleaved pushes. As such, during pop operations there is no need to shift array elements. An index is stored in the copy queue data structure which keeps track of which element to pop next allowing pop to be $O(1)$. Push operations are amortized $O(1)$ since pushes may cause doubling reallocations of the underlying dynamic sized array.
+The copy queue is a thin layer over a dynamically sized array that is designed with the envelope use case in mind.
+A copy queue supports the typical queue operations of push/pop but in a different way than a typical array based queue.
+The copy queue is designed to take advantage of the \hyperref[s:executor]{gulping} pattern.
+As such the amortized rutime cost of each push/pop operation for the copy queue is $O(1)$.
+In contrast, a naive array based queue often has either push or pop cost $O(n)$ and the other cost $O(1)$ since for at least one of the operations all the elements of the queue have to be shifted over.
+Since the worker threads gulp each queue to operate on locally, this creates a usage pattern of the queue where all elements are popped from the copy queue without any interleaved pushes.
+As such, during pop operations there is no need to shift array elements.
+An index is stored in the copy queue data structure which keeps track of which element to pop next allowing pop to be $O(1)$.
+Push operations are amortized $O(1)$ since pushes may cause doubling reallocations of the underlying dynamic sized array.
 % C_TODO: maybe make copy_queue diagram
+Since the copy queue is an array, envelopes are allocated first on the stack and then copied into the copy queue to persist until they are no longer needed. For a fixed message throughput workload, once the copy queues grow in size to facilitate the number of messages in flight, there are no longer any dynamic allocations occuring in the actor system. One problem that arises with this approach is that this array based approach will often allocate more storage than what is needed. Comparitively the individual envelope allocations of a list based queue mean that the actor system will always use the minimum amount of heap space needed and will clean up eagerly. Additionally, a workload with variable message throughput could cause copy queues to allocate large amounts of space to accomodate the peaks of the throughput, even if most of that storage is not needed for the rest of the workload's execution.
+To mitigate this a memory reclamation scheme was introduced. Initially the memory reclamation naively reclaimed one index of the array per gulp if the array size was above a low fixed threshold. This approach had a problem. The high memory usage watermark nearly doubled with this change! The issue with this approach can easily be highlighted with an example. Say that there is a fixed throughput workload where a queue never has more than 19 messages at a time. If the copy queue starts with a size of 10, it will end up doubling at some point to size 20 to accomodate 19 messages. However, after 2 gulps and subsequent reclamations the array would be size 18. The next time 19 messages are enqueued, the array size is doubled to 36! To avoid this issue a second check was added to reclamation. Each copy queue started tracking the utilization of their array size. Reclamation would only occur if less than half of the array was being utilized. In doing this the reclamation scheme was able to achieve a lower high watermark and a lower overall memory utilization when compared to the non-reclamation copy queues. However, the use of copy queues still incurs a higher memory cost than the list based queueing. With the inclusion of a memory reclamation scheme the increase in memory usage is reasonable considering the performance gains and will be discussed further in Section \ref{s:actor_perf}.
+Since the copy queue is an array, envelopes are allocated first on the stack and then copied into the copy queue to persist until they are no longer needed.
+For a fixed message throughput workload, once the copy queues grow in size to facilitate the number of messages in flight, there are no longer any dynamic allocations occuring in the actor system.
+One problem that arises with this approach is that this array based approach will often allocate more storage than what is needed.
+Comparitively the individual envelope allocations of a list based queue mean that the actor system will always use the minimum amount of heap space needed and will clean up eagerly.
+Additionally, a workload with variable message throughput could cause copy queues to allocate large amounts of space to accomodate the peaks of the throughput, even if most of that storage is not needed for the rest of the workload's execution.
+To mitigate this a memory reclamation scheme was introduced.
+Initially the memory reclamation naively reclaimed one index of the array per gulp if the array size was above a low fixed threshold.
+This approach had a problem.
+The high memory usage watermark nearly doubled with this change! The issue with this approach can easily be highlighted with an example.
+Say that there is a fixed throughput workload where a queue never has more than 19 messages at a time.
+If the copy queue starts with a size of 10, it will end up doubling at some point to size 20 to accomodate 19 messages.
+However, after 2 gulps and subsequent reclamations the array would be size 18.
+The next time 19 messages are enqueued, the array size is doubled to 36! To avoid this issue a second check was added to reclamation.
+Each copy queue started tracking the utilization of their array size.
+Reclamation would only occur if less than half of the array was being utilized.
+In doing this the reclamation scheme was able to achieve a lower high watermark and a lower overall memory utilization when compared to the non-reclamation copy queues.
+However, the use of copy queues still incurs a higher memory cost than the list based queueing.
+With the inclusion of a memory reclamation scheme the increase in memory usage is reasonable considering the performance gains and will be discussed further in Section \ref{s:actor_perf}.
 \section{Work Stealing}\label{s:steal}
+Work stealing is a scheduling strategy that attempts to load balance, and increase resource untilization by having idle threads steal work. There are many parts that make up a work stealing actor scheduler, but the two that will be highlighted in this work are the stealing mechanism and victim selection.
+Work stealing is a scheduling strategy that attempts to load balance, and increase resource untilization by having idle threads steal work.
+There are many parts that make up a work stealing actor scheduler, but the two that will be highlighted in this work are the stealing mechanism and victim selection.
 % C_TODO enter citation for langs
 \subsection{Stealing Mechanism}
+In this discussion of work stealing the worker being stolen from will be referred to as the \newterm{victim} and the worker stealing work will be called the \newterm{thief}. The stealing mechanism presented here differs from existing work stealing actor systems due the inverted actor system. Other actor systems such as Akka \cite{} and CAF \cite{} have work stealing, but since they use an classic actor system that is actor-centric, stealing work is the act of stealing an actor from a dequeue. As an example, in CAF, the sharded actor queue is a set of double ended queues (dequeues). Whenever an actor is moved to a ready queue, it is inserted into a worker's dequeue. Workers then consume actors from the dequeue and execute their behaviours. To steal work, thieves take one or more actors from a victim's dequeue. This action creates contention on the dequeue, which can slow down the throughput of the victim. The notion of which end of the dequeue is used for stealing, consuming, and inserting is not discussed since it isn't relevant. By the pigeon hole principle there are three dequeue operations (push/victim pop/thief pop) that can occur concurrently and only two ends to a dequeue, so work stealing being present in a dequeue based system will always result in a potential increase in contention on the dequeues.
+In this discussion of work stealing the worker being stolen from will be referred to as the \textbf{victim} and the worker stealing work will be called the \textbf{thief}.
+The stealing mechanism presented here differs from existing work stealing actor systems due the inverted actor system.
+Other actor systems such as Akka \cite{} and CAF \cite{} have work stealing, but since they use an classic actor system that is actor-centric, stealing work is the act of stealing an actor from a dequeue.
+As an example, in CAF, the sharded actor queue is a set of double ended queues (dequeues).
+Whenever an actor is moved to a ready queue, it is inserted into a worker's dequeue.
+Workers then consume actors from the dequeue and execute their behaviours.
+To steal work, thieves take one or more actors from a victim's dequeue.
+This action creates contention on the dequeue, which can slow down the throughput of the victim.
+The notion of which end of the dequeue is used for stealing, consuming, and inserting is not discussed since it isn't relevant.
+By the pigeon hole principle there are three dequeue operations (push/victim pop/thief pop) that can occur concurrently and only two ends to a dequeue, so work stealing being present in a dequeue based system will always result in a potential increase in contention on the dequeues.
 % C_TODO: maybe insert stealing diagram
+In \CFA, the actor work stealing implementation is unique. While other systems are concerned with stealing actors, the \CFA actor system steals queues. This is a result of \CFA's use of the inverted actor system.  The goal of the \CFA actor work stealing mechanism is to have a zero-victim-cost stealing mechanism. This does not means that stealing has no cost. This goal is to ensure that stealing work does not impact the performance of victim workers. This means that thieves can not contend with victims, and that victims should perform no stealing related work unless they become a thief. In theory this goal is not achieved, but results will be presented that show the goal is achieved in practice. In \CFA's actor system workers own a set of sharded queues which they iterate over and gulp. If a worker has iterated over the queues they own twice without finding any work, they try to steal a queue from another worker. Stealing a queue is done wait-free with a few atomic instructions that can only create contention with other stealing workers. To steal a queue a worker does the following:
+In \CFA, the actor work stealing implementation is unique.
+While other systems are concerned with stealing actors, the \CFA actor system steals queues.
+This is a result of \CFA's use of the inverted actor system.
+ The goal of the \CFA actor work stealing mechanism is to have a zero-victim-cost stealing mechanism.
+This does not means that stealing has no cost.
+This goal is to ensure that stealing work does not impact the performance of victim workers.
+This means that thieves can not contend with victims, and that victims should perform no stealing related work unless they become a thief.
+In theory this goal is not achieved, but results will be presented that show the goal is achieved in practice.
+In \CFA's actor system workers own a set of sharded queues which they iterate over and gulp.
+If a worker has iterated over the queues they own twice without finding any work, they try to steal a queue from another worker.
+Stealing a queue is done wait-free with a few atomic instructions that can only create contention with other stealing workers.
+To steal a queue a worker does the following:
 \begin{enumerate}[topsep=5pt,itemsep=3pt,parsep=0pt]
 \item
 …
 \item
+The thief starts at a random index in the array of the victim's queues and searches for a candidate queue. A candidate queue is any queue that is not empty, is not being stolen by another thief, and is not being processed by the victim. These are not strictly enforced rules. The candidate is identified non-atomically and as such queues that do not satisfy these rules may be stolen. However, steals that do not meet these requirements do not affect correctness so they are allowed and do not constitute failed steals as the queues will still be swapped.
+\item
+Once a candidate queue is chosen, the thief attempts a wait-free swap of the victim's queue and a random on of the thief's queues. This swap can fail. If the swap is successful the thief swaps the two queues. If the swap fails, another thief must have attempted to steal one of the two queues being swapped. Failing to steal is good in this case since stealing a queue that was just swapped would likely result in stealing an empty queue.
+The thief starts at a random index in the array of the victim's queues and searches for a candidate queue.
+A candidate queue is any queue that is not empty, is not being stolen by another thief, and is not being processed by the victim.
+These are not strictly enforced rules.
+The candidate is identified non-atomically and as such queues that do not satisfy these rules may be stolen.
+However, steals that do not meet these requirements do not affect correctness so they are allowed and do not constitute failed steals as the queues will still be swapped.
+\item
+Once a candidate queue is chosen, the thief attempts a wait-free swap of the victim's queue and a random on of the thief's queues.
+This swap can fail.
+If the swap is successful the thief swaps the two queues.
+If the swap fails, another thief must have attempted to steal one of the two queues being swapped.
+Failing to steal is good in this case since stealing a queue that was just swapped would likely result in stealing an empty queue.
 \end{enumerate}
+Once a thief fails or succeeds in stealing a queue, it goes back to its own set of queues and iterates over them again. It will only try to steal again once it has completed two consecutive iterations over its owned queues without finding any work. The key to the stealing mechnism is that the queues can still be operated on while they are being swapped. This elimates any contention between thieves and victims. The first key to this is that actors and workers maintain two distinct arrays of references to queues. Actors will always receive messages via the same queues. Workers, on the other hand will swap the pointers to queues in their shared array and operate on queues in the range of that array that they own. Swapping queues is a matter of atomically swapping two pointers in the worker array. As such pushes to the queues can happen concurrently during the swap since pushes happen via the actor queue references.
+Gulping can also occur during queue swapping, but the implementation requires more nuance than the pushes. When a worker is not stealing it iterates across its own range of queues and gulps them one by one. When a worker operates on a queue it first copies the current pointer from the worker array of references to a local variable. It then uses that local variable for all queue operations until it moves to the next index of its range of the queue array. This ensures that any swaps do not interrupt gulping operations, however this introduces a correctness issue. If any behaviours from a queue are run by two workers at a time it violates both mutual exclusion and the actor ordering guarantees. As such this must be avoided. To avoid this each queue has a \code{being_processed} flag that is atomically set to \code{true} when a queue is gulped. The flag indicates that a queue is being processed locally and is set back to \code{false} once the local processing is finished. If a worker attempts to gulp a queue and finds that the \code{being_processed} flag is \code{true}, it does not gulp the queue and moves on to the next queue in its range. This is a source of contention between victims and thieves since a thief may steal a queue and set \code{being_processed} to \code{true} between a victim saving a pointer to a queue and gulping it. However, the window for this race is very small, making this contention rare. This is why the claim is made that this mechanism is zero-victim-cost in practice but not in theory. By collecting statistics on failed gulps due to the \code{being_processed} flag, it is found that this contention occurs ~0.05\% of the time when a gulp occurs. Hence, the claim is made that this stealing mechanism has zero-victim-cost in practice.
+Once a thief fails or succeeds in stealing a queue, it goes back to its own set of queues and iterates over them again.
+It will only try to steal again once it has completed two consecutive iterations over its owned queues without finding any work.
+The key to the stealing mechnism is that the queues can still be operated on while they are being swapped.
+This elimates any contention between thieves and victims.
+The first key to this is that actors and workers maintain two distinct arrays of references to queues.
+Actors will always receive messages via the same queues.
+Workers, on the other hand will swap the pointers to queues in their shared array and operate on queues in the range of that array that they own.
+Swapping queues is a matter of atomically swapping two pointers in the worker array.
+As such pushes to the queues can happen concurrently during the swap since pushes happen via the actor queue references.
+Gulping can also occur during queue swapping, but the implementation requires more nuance than the pushes.
+When a worker is not stealing it iterates across its own range of queues and gulps them one by one.
+When a worker operates on a queue it first copies the current pointer from the worker array of references to a local variable.
+It then uses that local variable for all queue operations until it moves to the next index of its range of the queue array.
+This ensures that any swaps do not interrupt gulping operations, however this introduces a correctness issue.
+If any behaviours from a queue are run by two workers at a time it violates both mutual exclusion and the actor ordering guarantees.
+As such this must be avoided.
+To avoid this each queue has a \code{being_processed} flag that is atomically set to \code{true} when a queue is gulped.
+The flag indicates that a queue is being processed locally and is set back to \code{false} once the local processing is finished.
+If a worker attempts to gulp a queue and finds that the \code{being_processed} flag is \code{true}, it does not gulp the queue and moves on to the next queue in its range.
+This is a source of contention between victims and thieves since a thief may steal a queue and set \code{being_processed} to \code{true} between a victim saving a pointer to a queue and gulping it.
+However, the window for this race is very small, making this contention rare.
+This is why the claim is made that this mechanism is zero-victim-cost in practice but not in theory.
+By collecting statistics on failed gulps due to the \code{being_processed} flag, it is found that this contention occurs ~0.05\% of the time when a gulp occurs.
+Hence, the claim is made that this stealing mechanism has zero-victim-cost in practice.
 \subsection{Queue Swap Correctness}
+Given the wait-free swap used is novel, it is important to show that it is correct. Firstly, it is clear to show that the swap is wait-free since all workers will fail or succeed in swapping the queues in a finite number of steps since there are no locks or looping. There is no retry mechanism in the case of a failed swap, since a failed swap either means the work was already stolen, or that work was stolen from the thief. In both cases it is apropos for a thief to given up on stealing. \CFA-style pseudocode for the queue swap is presented below. The swap uses compare-and-swap (\code{CAS}) which is just pseudocode for C's \code{__atomic_compare_exchange_n}. A pseudocode implementation of \code{CAS} is also shown below. The correctness of the wait-free swap will now be discussed in detail. To first verify sequential correctness, consider the equivalent sequential swap below:
+Given the wait-free swap used is novel, it is important to show that it is correct.
+Firstly, it is clear to show that the swap is wait-free since all workers will fail or succeed in swapping the queues in a finite number of steps since there are no locks or looping.
+There is no retry mechanism in the case of a failed swap, since a failed swap either means the work was already stolen, or that work was stolen from the thief.
+In both cases it is apropos for a thief to given up on stealing.
+\CFA-style pseudocode for the queue swap is presented below.
+The swap uses compare-and-swap (\code{CAS}) which is just pseudocode for C's \code{__atomic_compare_exchange_n}.
+A pseudocode implementation of \code{CAS} is also shown below.
+The correctness of the wait-free swap will now be discussed in detail.
+To first verify sequential correctness, consider the equivalent sequential swap below:
 \begin{cfacode}
 …
 \end{cfacode}
+Step 1 is missing in the sequential example since in only matter in the concurrent context presented later. By looking at the sequential swap it is easy to see that it is correct. Temporary copies of each pointer being swapped are stored, and then the original values of each pointer are set using the copy of the other pointer.
+Step 1 is missing in the sequential example since in only matter in the concurrent context presented later.
+By looking at the sequential swap it is easy to see that it is correct.
+Temporary copies of each pointer being swapped are stored, and then the original values of each pointer are set using the copy of the other pointer.
 \begin{cfacode}
 …
 Step 0 is the same as the sequential example, and the thief stores local copies of the two pointers to be swapped.
 \item
+Step 1 verifies that the stored copy of the victim queue pointer, \code{vic_queue}, is valid. If \code{vic_queue} is equal to \code{0p}, then the victim queue is part of another swap so the operation fails. No state has changed at this point so no fixups are needed. Note, \code{my_queue} can never be equal to \code{0p} at this point since thieves only set their own queues pointers to \code{0p} when stealing. At no other point will a queue pointer be set to \code{0p}. Since each worker owns a disjoint range of the queue array, it is impossible for \code{my_queue} to be \code{0p}.
+\item
+Step 2 attempts to set the thief's queue pointer to \code{0p} via \code{CAS}. The \code{CAS} will only fail if the thief's queue pointer is no longer equal to \code{my_queue}, which implies that this thief has become a victim and its queue has been stolen. At this point the thief-turned-victim will fail and since it has not changed any state it just fails and returns false. If the \code{CAS} succeeds then the thief's queue pointer will now be \code{0p}. Nulling the pointer is safe since only thieves look at other worker's queue ranges, and whenever thieves need to dereference a queue pointer they check for \code{0p}.
+\item
+Step 3 attempts to set the victim's queue pointer to be \code{my_queue} via \code{CAS}. If the \code{CAS} succeeds then the victim's queue pointer has been set and swap can no longer fail. If the \code{CAS} fails then the thief's queue pointer must be restored to its previous value before returning.
+Step 1 verifies that the stored copy of the victim queue pointer, \code{vic_queue}, is valid.
+If \code{vic_queue} is equal to \code{0p}, then the victim queue is part of another swap so the operation fails.
+No state has changed at this point so no fixups are needed.
+Note, \code{my_queue} can never be equal to \code{0p} at this point since thieves only set their own queues pointers to \code{0p} when stealing.
+At no other point will a queue pointer be set to \code{0p}.
+Since each worker owns a disjoint range of the queue array, it is impossible for \code{my_queue} to be \code{0p}.
+\item
+Step 2 attempts to set the thief's queue pointer to \code{0p} via \code{CAS}.
+The \code{CAS} will only fail if the thief's queue pointer is no longer equal to \code{my_queue}, which implies that this thief has become a victim and its queue has been stolen.
+At this point the thief-turned-victim will fail and since it has not changed any state it just fails and returns false.
+If the \code{CAS} succeeds then the thief's queue pointer will now be \code{0p}.
+Nulling the pointer is safe since only thieves look at other worker's queue ranges, and whenever thieves need to dereference a queue pointer they check for \code{0p}.
+\item
+Step 3 attempts to set the victim's queue pointer to be \code{my_queue} via \code{CAS}.
+If the \code{CAS} succeeds then the victim's queue pointer has been set and swap can no longer fail.
+If the \code{CAS} fails then the thief's queue pointer must be restored to its previous value before returning.
 \item
 Step 4 sets the thief's queue pointer to be \code{vic_queue} completing the swap.
 …
 \end{theorem}
+Correctness of the swap is shown through the existence of an invariant. The invariant is that when a queue pointer is set to \code{0p} by a thief, then the next write to the pointer can only be performed by the same thief. To show that this invariant holds, it is shown that it is true at each step of the swap. Step 0 and 1 do not write and as such they cannot invalidate the invariant of any other thieves. In step 2 a thief attempts to write \code{0p} to one of their queue pointers. This queue pointer cannot be \code{0p}. As stated above, \code{my_queue} is never equal to \code{0p} since thieves will only write \code{0p} to queue pointers from their own queue range and all worker's queue ranges are disjoint. As such step 2 upholds the invariant since in a failure case no write occurs, and in the success case, the value of the queue pointer is guaranteed to not be 0p. In step 3 the thief attempts to write \code{my_queue} to the victim's queue pointer. If the current value of the victim's queue pointer is \code{0p}, then the CAS will fail since \code{vic_queue} cannot be equal to \code{0p} because of the check in step 1. Therefore in the success case where the \code{CAS} succeeds, the value of the victim's queue pointer must not be \code{0p}. As such, the write will never overwrite a value of \code{0p}, hence the invariant is held in the \code{CAS} of step 3. The write back to the thief's queue pointer that happens in the failure case of step three and in step 4 hold the invariant since they are the subsequent write to a \code{0p} queue pointer and they are being set by the same thief that set the pointer to \code{0p}.
+Given this informal proof of invariance it can be shown that the successful swap is correct. Once a thief atomically sets their queue pointer to be \code{0p} in step 2, the invariant guarantees that pointer will not change. As such, in the success case step 3 it is known that the value of the victim's queue pointer that was overwritten must be \code{vic_queue} due to the use of \code{CAS}. Given that pointers all have unique memory locations, this first write of the successful swap is correct since it can only occur when the pointer has not changed. By the invariant the write back in the successful case is correct since no other worker can write to the \code{0p} pointer.
+In the failed case the outcome is correct in steps 1 and 2 since no writes have occured so the program state is unchanged. In the failed case of step 3 the program state is safely restored to its state it had prior to the \code{0p} write in step 2, thanks to the invariant that makes the write back to the \code{0p} pointer safe.
+Correctness of the swap is shown through the existence of an invariant.
+The invariant is that when a queue pointer is set to \code{0p} by a thief, then the next write to the pointer can only be performed by the same thief.
+To show that this invariant holds, it is shown that it is true at each step of the swap.
+Step 0 and 1 do not write and as such they cannot invalidate the invariant of any other thieves.
+In step 2 a thief attempts to write \code{0p} to one of their queue pointers.
+This queue pointer cannot be \code{0p}.
+As stated above, \code{my_queue} is never equal to \code{0p} since thieves will only write \code{0p} to queue pointers from their own queue range and all worker's queue ranges are disjoint.
+As such step 2 upholds the invariant since in a failure case no write occurs, and in the success case, the value of the queue pointer is guaranteed to not be 0p.
+In step 3 the thief attempts to write \code{my_queue} to the victim's queue pointer.
+If the current value of the victim's queue pointer is \code{0p}, then the CAS will fail since \code{vic_queue} cannot be equal to \code{0p} because of the check in step 1.
+Therefore in the success case where the \code{CAS} succeeds, the value of the victim's queue pointer must not be \code{0p}.
+As such, the write will never overwrite a value of \code{0p}, hence the invariant is held in the \code{CAS} of step 3.
+The write back to the thief's queue pointer that happens in the failure case of step three and in step 4 hold the invariant since they are the subsequent write to a \code{0p} queue pointer and they are being set by the same thief that set the pointer to \code{0p}.
+Given this informal proof of invariance it can be shown that the successful swap is correct.
+Once a thief atomically sets their queue pointer to be \code{0p} in step 2, the invariant guarantees that pointer will not change.
+As such, in the success case step 3 it is known that the value of the victim's queue pointer that was overwritten must be \code{vic_queue} due to the use of \code{CAS}.
+Given that pointers all have unique memory locations, this first write of the successful swap is correct since it can only occur when the pointer has not changed.
+By the invariant the write back in the successful case is correct since no other worker can write to the \code{0p} pointer.
+In the failed case the outcome is correct in steps 1 and 2 since no writes have occured so the program state is unchanged.
+In the failed case of step 3 the program state is safely restored to its state it had prior to the \code{0p} write in step 2, thanks to the invariant that makes the write back to the \code{0p} pointer safe.
 \subsection{Stealing Guarantees}
 % C_TODO insert graphs for each proof
+Given that the stealing operation can potentially fail, it is important to discuss the guarantees provided by the stealing implementation. Given a set of $N$ swaps a set of connected directed graphs can be constructed where each vertex is a queue and each edge is a swap directed from a thief queue to a victim queue. Since each thief can only steal from one victim at a time, each vertex can only have at most one outgoing edge. A corollary that can be drawn from this, is that there are at most $V$ edges in this constructed set of connected directed graphs, where $V$ is the total number of vertices.
+Given that the stealing operation can potentially fail, it is important to discuss the guarantees provided by the stealing implementation.
+Given a set of $N$ swaps a set of connected directed graphs can be constructed where each vertex is a queue and each edge is a swap directed from a thief queue to a victim queue.
+Since each thief can only steal from one victim at a time, each vertex can only have at most one outgoing edge.
+A corollary that can be drawn from this, is that there are at most $V$ edges in this constructed set of connected directed graphs, where $V$ is the total number of vertices.
 \begin{figure}
 …
 A graph of the $M$ thieves swapping with one victim discussed in this theorem is presented in Figure~\ref{f:M_one_swap}.
 \\
+First it is important to state that a thief will not attempt to steal from themselves. As such, the victim here is not also a thief. 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 \code{0p}. Similarly for all thieves step 2 will succeed since no one is stealing from any of the thieves. In step 3 the first thief to \code{CAS} will win the race and successfully swap the queue pointer. Since it is the first one to \code{CAS} and \code{CAS} is atomic, there is no way for the \code{CAS} to fail since no other thief could have written to the victim's queue pointer and the victim did not write to the pointer since they aren't stealing. Hence at least one swap is guaranteed to succeed in this case.
+First it is important to state that a thief will not attempt to steal from themselves.
+As such, the victim here is not also a thief.
+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 \code{0p}.
+Similarly for all thieves step 2 will succeed since no one is stealing from any of the thieves.
+In step 3 the first thief to \code{CAS} will win the race and successfully swap the queue pointer.
+Since it is the first one to \code{CAS} and \code{CAS} is atomic, there is no way for the \code{CAS} to fail since no other thief could have written to the victim's queue pointer and the victim did not write to the pointer since they aren't stealing.
+Hence at least one swap is guaranteed to succeed in this case.
 \begin{figure}
 …
 A graph of the chain of swaps discussed in this theorem is presented in Figure~\ref{f:chain_swap}.
 \\
+This is a proof by contradiction. Assume no swaps occur. Then all thieves must have failed at step 1, step 2 or step 3. For a given thief $b$ to fail at step 1, thief $b + 1$ must have succeded at step 2 before $b$ executes step 0. Hence, not all thieves can fail at step 1. Furthermore if a thief $b$ fails at step 1 it logically splits the chain into two subchains $0 <- b$ and $b + 1 <- M - 1$, where $b$ has become solely a victim since its swap has failed and it did not modify any state. There must exist at least one chain containing two or more queues after since it is impossible for a split to occur both before and after a thief, since that requires failing at step 1 and succeeding at step 2. Hence, without loss of generality, whether thieves succeed or fail at step 1, this proof can proceed inductively.
+For a given thief $i$ to fail at step 2, it means that another thief $j$ had to have written to $i$'s queue pointer between $i$'s step 0 and step 2. The only way for $j$ to write to $i$'s queue pointer would be if $j$ was stealing from $i$ and had successfully finished step 3. If $j$ finished step 3 then the at least one swap was successful. Therefore all thieves did not fail at step 2. Hence all thieves must successfully complete step 2 and fail at step 3. However, since the first worker, thief $0$, is solely a victim and not a thief, it does not change the state of any of its queue pointers. Hence, in this case thief $1$ will always succeed in step 3 if all thieves succeed in step 2. Thus, by contradiction with the earlier assumption that no swaps occur, at least one swap must succeed.
+This is a proof by contradiction.
+Assume no swaps occur.
+Then all thieves must have failed at step 1, step 2 or step 3.
+For a given thief $b$ to fail at step 1, thief $b + 1$ must have succeded at step 2 before $b$ executes step 0.
+Hence, not all thieves can fail at step 1.
+Furthermore if a thief $b$ fails at step 1 it logically splits the chain into two subchains $0 <- b$ and $b + 1 <- M - 1$, where $b$ has become solely a victim since its swap has failed and it did not modify any state.
+There must exist at least one chain containing two or more queues after since it is impossible for a split to occur both before and after a thief, since that requires failing at step 1 and succeeding at step 2.
+Hence, without loss of generality, whether thieves succeed or fail at step 1, this proof can proceed inductively.
+For a given thief $i$ to fail at step 2, it means that another thief $j$ had to have written to $i$'s queue pointer between $i$'s step 0 and step 2.
+The only way for $j$ to write to $i$'s queue pointer would be if $j$ was stealing from $i$ and had successfully finished step 3.
+If $j$ finished step 3 then the at least one swap was successful.
+Therefore all thieves did not fail at step 2.
+Hence all thieves must successfully complete step 2 and fail at step 3.
+However, since the first worker, thief $0$, is solely a victim and not a thief, it does not change the state of any of its queue pointers.
+Hence, in this case thief $1$ will always succeed in step 3 if all thieves succeed in step 2.
+Thus, by contradiction with the earlier assumption that no swaps occur, at least one swap must succeed.
 % \raisebox{.1\height}{}
 …
 \begin{theorem}
+Given a set of $M > 1$ swaps occuring that form a single directed connected graph. At least one swap is guaranteed to suceed if and only if the graph does not contain a cycle.
+Given a set of $M > 1$ swaps occuring that form a single directed connected graph.
+At least one swap is guaranteed to suceed if and only if the graph does not contain a cycle.
 \end{theorem}\label{t:vic_cycle}
 Representations of cyclic and acylic swap graphs discussed in this theorem are presented in Figures~\ref{f:cyclic_swap} and \ref{f:acyclic_swap}.
 \\
+First the reverse direction is proven. If the graph does not contain a cycle, then there must be at least one successful swap. Since the graph contains no cycles and is finite in size, then there must be a vertex $A$ with no outgoing edges. The graph can then be formulated as a tree with $A$ at the top since each node only has at most one outgoing edge and there are no cycles. The forward direction is proven by contradiction in a similar fashion to \ref{t:vic_chain}. Assume no swaps occur. Similar to \ref{t:vic_chain}, this graph can be inductively split into subgraphs of the same type by failure at step 1, so the proof proceeds without loss of generality. Similar to \ref{t:vic_chain} the conclusion is drawn that all thieves must successfully complete step 2 for no swaps to occur, since for step 2 to fail, a different thief has to successfully complete step 3, which would imply a successful swap. Hence, the only way forward is to assume all thieves successfully complete step 2. Hence for there to be no swaps all thieves must fail step 3. However, since $A$ has no outgoing edges, since the graph is connected there must be some $K$ such that $K < M - 1$ thieves are attempting to swap with $A$. Since all $K$ thieves have passed step 2, similar to \ref{t:one_vic} the first one of the $K$ thieves to attempt step 3 is guaranteed to succeed. Thus, by contradiction with the earlier assumption that no swaps occur, if the graph does not contain a cycle, at least one swap must succeed.
+The forward direction is proven by contrapositive. If the graph contains a cycle then there exists a situation where no swaps occur. This situation is constructed. Since all vertices have at most one outgoing edge the cycle must be directed. Furthermore, since the graph contains a cycle all vertices in the graph must have exactly one outgoing edge. This is shown through construction of an aribtrary cyclic graph. The graph contains a directed cycle by definition, so the construction starts with $T$ vertices in a directed cycle. Since the graph is connected, and each vertex has at most one outgoing edge, none of the vertices in the cycle have available outgoing edges to accomodate new vertices with no outgoing edges. Any vertices added to the graph must have an outgoing edge to connect, leaving the resulting graph with no available outgoing edges. Thus, by induction all vertices in the graph must have exactly one outgoing edge. Hence all vertices are thief queues. Now consider the case where all thieves successfully complete step 0-1, and then they all complete step 2. At this point all thieves are attempting to swap with a queue pointer whose value has changed to \code{0p}. If all thieves attempt the \code{CAS} before any write backs, then they will all fail. Thus, by contrapositive, if the graph contains a cycle then there exists a situation where no swaps occur. Hence, at least one swap is guaranteed to suceed if and only if the graph does not contain a cycle.
+First the reverse direction is proven.
+If the graph does not contain a cycle, then there must be at least one successful swap.
+Since the graph contains no cycles and is finite in size, then there must be a vertex $A$ with no outgoing edges.
+The graph can then be formulated as a tree with $A$ at the top since each node only has at most one outgoing edge and there are no cycles.
+The forward direction is proven by contradiction in a similar fashion to \ref{t:vic_chain}.
+Assume no swaps occur.
+Similar to \ref{t:vic_chain}, this graph can be inductively split into subgraphs of the same type by failure at step 1, so the proof proceeds without loss of generality.
+Similar to \ref{t:vic_chain} the conclusion is drawn that all thieves must successfully complete step 2 for no swaps to occur, since for step 2 to fail, a different thief has to successfully complete step 3, which would imply a successful swap.
+Hence, the only way forward is to assume all thieves successfully complete step 2.
+Hence for there to be no swaps all thieves must fail step 3.
+However, since $A$ has no outgoing edges, since the graph is connected there must be some $K$ such that $K < M - 1$ thieves are attempting to swap with $A$.
+Since all $K$ thieves have passed step 2, similar to \ref{t:one_vic} the first one of the $K$ thieves to attempt step 3 is guaranteed to succeed.
+Thus, by contradiction with the earlier assumption that no swaps occur, if the graph does not contain a cycle, at least one swap must succeed.
+The forward direction is proven by contrapositive.
+If the graph contains a cycle then there exists a situation where no swaps occur.
+This situation is constructed.
+Since all vertices have at most one outgoing edge the cycle must be directed.
+Furthermore, since the graph contains a cycle all vertices in the graph must have exactly one outgoing edge.
+This is shown through construction of an aribtrary cyclic graph.
+The graph contains a directed cycle by definition, so the construction starts with $T$ vertices in a directed cycle.
+Since the graph is connected, and each vertex has at most one outgoing edge, none of the vertices in the cycle have available outgoing edges to accomodate new vertices with no outgoing edges.
+Any vertices added to the graph must have an outgoing edge to connect, leaving the resulting graph with no available outgoing edges.
+Thus, by induction all vertices in the graph must have exactly one outgoing edge.
+Hence all vertices are thief queues.
+Now consider the case where all thieves successfully complete step 0-1, and then they all complete step 2.
+At this point all thieves are attempting to swap with a queue pointer whose value has changed to \code{0p}.
+If all thieves attempt the \code{CAS} before any write backs, then they will all fail.
+Thus, by contrapositive, if the graph contains a cycle then there exists a situation where no swaps occur.
+Hence, at least one swap is guaranteed to suceed if and only if the graph does not contain a cycle.
 % C_TODO: go through and use \paragraph to format to make it look nicer
 \subsection{Victim Selection}\label{s:victimSelect}
+In any work stealing algorithm thieves have some heuristic to determine which victim to choose from. Choosing this algorithm is difficult and can have implications on performance. There is no one selection heuristic that is known to be the best on all workloads. Recent work focuses on locality aware scheduling in actor systems\cite{barghi18}\cite{wolke17}. However, while locality aware scheduling provides good performance on some workloads, something as simple as randomized selection performs better on other workloads\cite{barghi18}. Since locality aware scheduling has been explored recently, this work introduces a heuristic called \newterm{longest victim} and compares it to randomized work stealing. The longest victim heuristic maintains a timestamp per worker thread that is updated every time a worker attempts to steal work. Thieves then attempt to steal from the thread with the oldest timestamp. This means that if two thieves look to steal at the same time, they likely will attempt to steal from the same victim. This does increase the chance at contention between thieves, however given that workers have multiple queues under them, often in the tens or hundreds of queues per worker it is rare for two queues to attempt so steal the same queue. Furthermore in the case they attempt to steal the same queue at least one of them is guaranteed to successfully steal the queue as shown in Theorem \ref{t:one_vic}. Additonally, the longest victim heuristic makes it very improbable that the no swap scenario presented in Theorem \ref{t:vic_cycle} manifests. Given the longest victim heuristic, for a cycle to manifest it would require all workers to attempt to steal in a short timeframe. This is the only way that more than one thief could choose another thief as a victim, since timestamps are only updated upon attempts to steal. In this case, the probability of lack of any successful swaps is a non issue, since it is likely that these steals were not important if all workers are trying to steal.
+In any work stealing algorithm thieves have some heuristic to determine which victim to choose from.
+Choosing this algorithm is difficult and can have implications on performance.
+There is no one selection heuristic that is known to be the best on all workloads.
+Recent work focuses on locality aware scheduling in actor systems\cite{barghi18}\cite{wolke17}.
+However, while locality aware scheduling provides good performance on some workloads, something as simple as randomized selection performs better on other workloads\cite{barghi18}.
+Since locality aware scheduling has been explored recently, this work introduces a heuristic called \textbf{longest victim} and compares it to randomized work stealing.
+The longest victim heuristic maintains a timestamp per worker thread that is updated every time a worker attempts to steal work.
+Thieves then attempt to steal from the thread with the oldest timestamp.
+This means that if two thieves look to steal at the same time, they likely will attempt to steal from the same victim.
+This does increase the chance at contention between thieves, however given that workers have multiple queues under them, often in the tens or hundreds of queues per worker it is rare for two queues to attempt so steal the same queue.
+Furthermore in the case they attempt to steal the same queue at least one of them is guaranteed to successfully steal the queue as shown in Theorem \ref{t:one_vic}.
+Additonally, the longest victim heuristic makes it very improbable that the no swap scenario presented in Theorem \ref{t:vic_cycle} manifests.
+Given the longest victim heuristic, for a cycle to manifest it would require all workers to attempt to steal in a short timeframe.
+This is the only way that more than one thief could choose another thief as a victim, since timestamps are only updated upon attempts to steal.
+In this case, the probability of lack of any successful swaps is a non issue, since it is likely that these steals were not important if all workers are trying to steal.
 \section{Safety and Productivity}
+\CFA's actor system comes with a suite of safety and productivity features. Most of these features are present in \CFA's debug mode, but are removed when code is compiled in nodebug mode. The suit of features include the following.
+\CFA's actor system comes with a suite of safety and productivity features.
+Most of these features are present in \CFA's debug mode, but are removed when code is compiled in nodebug mode.
+The suit of features include the following.
 \begin{itemize}
+\item Static-typed message sends. If an actor does not support receiving a given message type, the actor program is rejected at compile time, allowing unsupported messages to never be sent to actors.
+\item Detection of message sends to Finished/Destroyed/Deleted actors. All actors have a ticket that assigns them to a respective queue. The maximum integer value of the ticket is reserved to indicate that an actor is dead, and subsequent message sends result in an error.
+\item Actors made before the executor can result in undefined behaviour since an executor needs to be created beforehand so it can give out the tickets to actors. As such, this is detected and an error is printed.
+\item When an executor is created, the queues are handed out to worker threads in round robin order. If there are fewer queues than worker threads, then some workers will spin and never do any work. There is no reasonable use case for this behaviour so an error is printed if the number of queues is fewer than the number of worker threads.
+\item A warning is printed when messages are deallocated without being sent. Since the \code{Finished} allocation status is unused for messages, it is used internally to detect if a message has been sent. Deallocating a message without sending it could indicate to a user that they are touching freed memory later, or it could point out extra allocations that could be removed.
+\item Static-typed message sends.
+If an actor does not support receiving a given message type, the actor program is rejected at compile time, allowing unsupported messages to never be sent to actors.
+\item Detection of message sends to Finished/Destroyed/Deleted actors.
+All actors have a ticket that assigns them to a respective queue.
+The maximum integer value of the ticket is reserved to indicate that an actor is dead, and subsequent message sends result in an error.
+\item Actors made before the executor can result in undefined behaviour since an executor needs to be created beforehand so it can give out the tickets to actors.
+As such, this is detected and an error is printed.
+\item When an executor is created, the queues are handed out to worker threads in round robin order.
+If there are fewer queues than worker threads, then some workers will spin and never do any work.
+There is no reasonable use case for this behaviour so an error is printed if the number of queues is fewer than the number of worker threads.
+\item A warning is printed when messages are deallocated without being sent.
+Since the \code{Finished} allocation status is unused for messages, it is used internally to detect if a message has been sent.
+Deallocating a message without sending it could indicate to a user that they are touching freed memory later, or it could point out extra allocations that could be removed.
 \end{itemize}
+In addition to these features, \CFA's actor system comes with a suite of statistics that can be toggled on and off. These statistics have minimal impact on the actor system's performance since they are counted on a per worker thread basis. During shutdown of the actor system they are aggregated, ensuring that the only atomic instructions used by the statistics counting happen at shutdown. The statistics measured are as follows.
+In addition to these features, \CFA's actor system comes with a suite of statistics that can be toggled on and off.
+These statistics have minimal impact on the actor system's performance since they are counted on a per worker thread basis.
+During shutdown of the actor system they are aggregated, ensuring that the only atomic instructions used by the statistics counting happen at shutdown.
+The statistics measured are as follows.
 \begin{description}
 \item[\LstBasicStyle{\textbf{Actors Created}}]
+Actors created. Includes both actors made by the main and ones made by other actors.
+Actors created.
+Includes both actors made by the main and ones made by other actors.
 \item[\LstBasicStyle{\textbf{Messages Sent}}]
+Messages sent and received. Includes termination messages send to the worker threads.
+Messages sent and received.
+Includes termination messages send to the worker threads.
 \item[\LstBasicStyle{\textbf{Gulps}}]
 Gulps that occured across the worker threads.
 …
 \item[\LstBasicStyle{\textbf{Steal attempts}}]
 Worker threads attempts to steal work.
 \item[\LstBasicStyle{\textbf{Steal failures (no candidates)}}]
 Work stealing failures due to selected victim not having any non empty or non-being-processed queues.
 …
 \end{description}
+These statistics enable a user of \CFA's actor system to make informed choices about how to configure their executor, or how to structure their actor program. For example, if there is a lot of messages being stolen relative to the number of messages sent, it could indicate to a user that their workload is heavily imbalanced across worker threads. In another example, if the average gulp size is very high, it could indicate that the executor could use more queue sharding.
+These statistics enable a user of \CFA's actor system to make informed choices about how to configure their executor, or how to structure their actor program.
+For example, if there is a lot of messages being stolen relative to the number of messages sent, it could indicate to a user that their workload is heavily imbalanced across worker threads.
+In another example, if the average gulp size is very high, it could indicate that the executor could use more queue sharding.
 % C_TODO cite poison pill messages and add languages
+Another productivity feature that is included is a group of poison-pill messages. Poison-pill messages are common across actor systems, including Akka and ProtoActor \cite{}. Poison-pill messages inform an actor to terminate. In \CFA, due to the allocation of actors and lack of garbage collection, there needs to be a suite of poison-pills. The messages that \CFA provides are \code{DeleteMsg}, \code{DestroyMsg}, and \code{FinishedMsg}. These messages are supported on all actor types via inheritance and when sent to an actor, the actor takes the corresponding allocation action after receiving the message. Note that any pending messages to the actor will still be sent. It is still the user's responsibility to ensure that an actor does not receive any messages after termination.
+Another productivity feature that is included is a group of poison-pill messages.
+Poison-pill messages are common across actor systems, including Akka and ProtoActor \cite{}.
+Poison-pill messages inform an actor to terminate.
+In \CFA, due to the allocation of actors and lack of garbage collection, there needs to be a suite of poison-pills.
+The messages that \CFA provides are \code{DeleteMsg}, \code{DestroyMsg}, and \code{FinishedMsg}.
+These messages are supported on all actor types via inheritance and when sent to an actor, the actor takes the corresponding allocation action after receiving the message.
+Note that any pending messages to the actor will still be sent.
+It is still the user's responsibility to ensure that an actor does not receive any messages after termination.
 \section{Performance}\label{s:actor_perf}
 The performance of \CFA's actor system is tested using a suite of microbenchmarks, and compared with other actor systems.
+Most of the benchmarks are the same as those presented in \ref{}, with a few additions. % C_TODO cite actor paper
+At the time of this work the versions of the actor systems are as follows. \CFA 1.0, \uC 7.0.0, Akka Typed 2.7.0, CAF 0.18.6, and ProtoActor-Go v0.0.0-20220528090104-f567b547ea07. Akka Classic is omitted as Akka Typed is their newest version and seems to be the direction they are headed in.
+Most of the benchmarks are the same as those presented in \ref{}, with a few additions.
+% C_TODO cite actor paper
+At the time of this work the versions of the actor systems are as follows.
+\CFA 1.0, \uC 7.0.0, Akka Typed 2.7.0, CAF 0.18.6, and ProtoActor-Go v0.0.0-20220528090104-f567b547ea07.
+Akka Classic is omitted as Akka Typed is their newest version and seems to be the direction they are headed in.
 The experiments are run on
 \begin{list}{\arabic{enumi}.}{\usecounter{enumi}\topsep=5pt\parsep=5pt\itemsep=0pt}
 …
 \end{list}
+The benchmarks are run on up to 48 cores. On the Intel, when going beyond 24 cores there is the choice to either hop sockets or to use hyperthreads. Either choice will cause a blip in performance trends, which can be seen in the following performance figures. On the Intel the choice was made to hyperthread instead of hopping sockets for experiments with more than 24 cores.
+All benchmarks presented are run 5 times and the median is taken. Error bars showing the 95\% confidence intervals are drawn on each point on the graphs. If the confidence bars are small enough, they may be obscured by the point. In this section \uC will be compared to \CFA frequently, as the actor system in \CFA was heavily based off \uC's actor system. As such the peformance differences that arise are largely due to the contributions of this work.
+The benchmarks are run on up to 48 cores.
+On the Intel, when going beyond 24 cores there is the choice to either hop sockets or to use hyperthreads.
+Either choice will cause a blip in performance trends, which can be seen in the following performance figures.
+On the Intel the choice was made to hyperthread instead of hopping sockets for experiments with more than 24 cores.
+All benchmarks presented are run 5 times and the median is taken.
+Error bars showing the 95\% confidence intervals are drawn on each point on the graphs.
+If the confidence bars are small enough, they may be obscured by the point.
+In this section \uC will be compared to \CFA frequently, as the actor system in \CFA was heavily based off \uC's actor system.
+As such the peformance differences that arise are largely due to the contributions of this work.
 \begin{table}[t]
 …
 \subsection{Message Sends}
+Message sending is the key component of actor communication. As such latency of a single message send is the fundamental unit of fast-path performance for an actor system. The following two microbenchmarks evaluate the average latency for a static actor/message send and a dynamic actor/message send. Static and dynamic refer to the allocation of the message and actor. In the static send benchmark a message and actor are allocated once and then the message is sent to the same actor repeatedly until it has been sent 100 million (100M) times. The average latency per message send is then calculated by dividing the duration by the number of sends. This benchmark evaluates the cost of message sends in the actor use case where all actors and messages are allocated ahead of time and do not need to be created dynamically during execution. The CAF static send benchmark only sends a message 10M times to avoid extensively long run times.
+In the dynamic send benchmark the same experiment is performed, with the change that with each send a new actor and message is allocated. This evaluates the cost of message sends in the other common actor pattern where actors and message are created on the fly as the actor program tackles a workload of variable or unknown size. Since dynamic sends are more expensive, this benchmark repeats the actor/message creation and send 20M times (\uC, \CFA), or 2M times (Akka, CAF, ProtoActor), to give an appropriate benchmark duration.
+The results from the static/dynamic send benchmarks are shown in Figures~\ref{t:StaticActorMessagePerformance} and \ref{t:DynamicActorMessagePerformance} respectively. \CFA leads the charts in both benchmarks, largely due to the copy queue removing the majority of the envelope allocations. In the static send benchmark all systems except CAF have static send costs that are in the same ballpark, only varying by ~70ns. In the dynamic send benchmark all systems experience slower message sends, as expected due to the extra allocations. However,  Akka and ProtoActor, slow down by a more significant margin than the \uC and \CFA. This is likely a result of Akka and ProtoActor's garbage collection, which can suffer from hits in performance for allocation heavy workloads, whereas \uC and \CFA have explicit allocation/deallocation.
+Message sending is the key component of actor communication.
+As such latency of a single message send is the fundamental unit of fast-path performance for an actor system.
+The following two microbenchmarks evaluate the average latency for a static actor/message send and a dynamic actor/message send.
+Static and dynamic refer to the allocation of the message and actor.
+In the static send benchmark a message and actor are allocated once and then the message is sent to the same actor repeatedly until it has been sent 100 million (100M) times.
+The average latency per message send is then calculated by dividing the duration by the number of sends.
+This benchmark evaluates the cost of message sends in the actor use case where all actors and messages are allocated ahead of time and do not need to be created dynamically during execution.
+The CAF static send benchmark only sends a message 10M times to avoid extensively long run times.
+In the dynamic send benchmark the same experiment is performed, with the change that with each send a new actor and message is allocated.
+This evaluates the cost of message sends in the other common actor pattern where actors and message are created on the fly as the actor program tackles a workload of variable or unknown size.
+Since dynamic sends are more expensive, this benchmark repeats the actor/message creation and send 20M times (\uC, \CFA), or 2M times (Akka, CAF, ProtoActor), to give an appropriate benchmark duration.
+The results from the static/dynamic send benchmarks are shown in Figures~\ref{t:StaticActorMessagePerformance} and \ref{t:DynamicActorMessagePerformance} respectively.
+\CFA leads the charts in both benchmarks, largely due to the copy queue removing the majority of the envelope allocations.
+In the static send benchmark all systems except CAF have static send costs that are in the same ballpark, only varying by ~70ns.
+In the dynamic send benchmark all systems experience slower message sends, as expected due to the extra allocations.
+However,  Akka and ProtoActor, slow down by a more significant margin than the \uC and \CFA.
+This is likely a result of Akka and ProtoActor's garbage collection, which can suffer from hits in performance for allocation heavy workloads, whereas \uC and \CFA have explicit allocation/deallocation.
 \subsection{Work Stealing}
+\CFA's actor system has a work stealing mechanism which uses the longest victim heuristic, introduced in Section~ref{s:victimSelect}. In this performance section, \CFA with the longest victim heuristic is compared with other actor systems on the benchmark suite, and is separately compared with vanilla non-stealing \CFA and \CFA with randomized work stealing.
+\CFA's actor system has a work stealing mechanism which uses the longest victim heuristic, introduced in Section~ref{s:victimSelect}.
+In this performance section, \CFA with the longest victim heuristic is compared with other actor systems on the benchmark suite, and is separately compared with vanilla non-stealing \CFA and \CFA with randomized work stealing.
 \begin{figure}
 …
 \end{figure}
+There are two benchmarks in which \CFA's work stealing is solely evaluated. The main goal of introducing work stealing to \CFA's actor system is to eliminate the pathological unbalanced cases that can present themselves in a system without some form of load balancing. The following two microbenchmarks construct two such pathological cases, and compare the work stealing variations of \CFA. The balance benchmarks adversarily takes advantage of the round robin assignment of actors to load all actors that will do work on specific cores and create 'dummy' actors that terminate after a single message send on all other cores. The workload on the loaded cores is the same as the executor benchmark described in \ref{s:executorPerf}, but with fewer rounds. The balance-one benchmark loads all the work on a single core, whereas the balance-multi loads all the work on half the cores (every other core). Given this layout, one expects the ideal speedup of work stealing in the balance-one case to be $N / N - 1$ where $N$ is the number of threads. In the balance-multi case the ideal speedup is 0.5. Note that in the balance-one benchmark the workload is fixed so decreasing runtime is expected. In the balance-multi experiment, the workload increases with the number of cores so an increasing or constant runtime is expected.
+On both balance microbenchmarks slightly less than ideal speedup compared to the non stealing variation is achieved by both the random and longest victim stealing heuristics. On the balance-multi benchmark \ref{f:BalanceMultiAMD},\ref{f:BalanceMultiIntel} the random heuristic outperforms the longest victim. This is likely a result of the longest victim heuristic having a higher stealing cost as it needs to maintain timestamps and look at all timestamps before stealing. Additionally, a performance cost can be observed when hyperthreading kicks in in Figure~\ref{f:BalanceMultiIntel}.
+In the balance-one benchmark on AMD \ref{f:BalanceOneAMD}, the performance bottoms out at 32 cores onwards likely due to the amount of work becoming less than the cost to steal it and move it across cores and cache. On Intel \ref{f:BalanceOneIntel}, above 32 cores the performance gets worse for all variants due to hyperthreading. Note that the non stealing variation of balance-one will slow down marginally as the cores increase due to having to create more dummy actors on the inactive cores during startup.
+There are two benchmarks in which \CFA's work stealing is solely evaluated.
+The main goal of introducing work stealing to \CFA's actor system is to eliminate the pathological unbalanced cases that can present themselves in a system without some form of load balancing.
+The following two microbenchmarks construct two such pathological cases, and compare the work stealing variations of \CFA.
+The balance benchmarks adversarily takes advantage of the round robin assignment of actors to load all actors that will do work on specific cores and create 'dummy' actors that terminate after a single message send on all other cores.
+The workload on the loaded cores is the same as the executor benchmark described in \ref{s:executorPerf}, but with fewer rounds.
+The balance-one benchmark loads all the work on a single core, whereas the balance-multi loads all the work on half the cores (every other core).
+Given this layout, one expects the ideal speedup of work stealing in the balance-one case to be $N / N - 1$ where $N$ is the number of threads.
+In the balance-multi case the ideal speedup is 0.5.
+Note that in the balance-one benchmark the workload is fixed so decreasing runtime is expected.
+In the balance-multi experiment, the workload increases with the number of cores so an increasing or constant runtime is expected.
+On both balance microbenchmarks slightly less than ideal speedup compared to the non stealing variation is achieved by both the random and longest victim stealing heuristics.
+On the balance-multi benchmark \ref{f:BalanceMultiAMD},\ref{f:BalanceMultiIntel} the random heuristic outperforms the longest victim.
+This is likely a result of the longest victim heuristic having a higher stealing cost as it needs to maintain timestamps and look at all timestamps before stealing.
+Additionally, a performance cost can be observed when hyperthreading kicks in in Figure~\ref{f:BalanceMultiIntel}.
+In the balance-one benchmark on AMD \ref{f:BalanceOneAMD}, the performance bottoms out at 32 cores onwards likely due to the amount of work becoming less than the cost to steal it and move it across cores and cache.
+On Intel \ref{f:BalanceOneIntel}, above 32 cores the performance gets worse for all variants due to hyperthreading.
+Note that the non stealing variation of balance-one will slow down marginally as the cores increase due to having to create more dummy actors on the inactive cores during startup.
 \subsection{Executor}\label{s:executorPerf}
+The microbenchmarks in this section are designed to stress the executor. The executor is the scheduler of an actor system and is responsible for organizing the interaction of worker threads to service the needs of a workload. In the executor benchmark, 40'000 actors are created and assigned a group. Each group of actors is a group of 100 actors who send and receive 100 messages from all other actors in their group. Each time an actor completes all their sends and receives, they are done a round. After all groups have completed 400 rounds the system terminates. This microbenchmark is designed to flood the executor with a large number of messages flowing between actors. Given there is no work associated with each message, other than sending more messages, the intended bottleneck of this experiment is the executor message send process.
+The microbenchmarks in this section are designed to stress the executor.
+The executor is the scheduler of an actor system and is responsible for organizing the interaction of worker threads to service the needs of a workload.
+In the executor benchmark, 40'000 actors are created and assigned a group.
+Each group of actors is a group of 100 actors who send and receive 100 messages from all other actors in their group.
+Each time an actor completes all their sends and receives, they are done a round.
+After all groups have completed 400 rounds the system terminates.
+This microbenchmark is designed to flood the executor with a large number of messages flowing between actors.
+Given there is no work associated with each message, other than sending more messages, the intended bottleneck of this experiment is the executor message send process.
 \begin{figure}
 …
 \end{figure}
+The results of the executor benchmark in Figures~\ref{f:ExecutorIntel} and \ref{f:ExecutorAMD} show \CFA with the lowest runtime relative to its peers. The difference in runtime between \uC and \CFA is largely due to the usage of the copy queue described in Section~\ref{s:copyQueue}. The copy queue both reduces and consolidates allocations, heavily reducing contention on the memory allocator. Additionally, due to the static typing in \CFA's actor system, it is able to get rid of expensive dynamic casts that occur in \uC to disciminate messages by type. Note that dynamic casts are ususally not very expensive, but relative to the high performance of the rest of the implementation of the \uC actor system, the cost is significant.
+The results of the executor benchmark in Figures~\ref{f:ExecutorIntel} and \ref{f:ExecutorAMD} show \CFA with the lowest runtime relative to its peers.
+The difference in runtime between \uC and \CFA is largely due to the usage of the copy queue described in Section~\ref{s:copyQueue}.
+The copy queue both reduces and consolidates allocations, heavily reducing contention on the memory allocator.
+Additionally, due to the static typing in \CFA's actor system, it is able to get rid of expensive dynamic casts that occur in \uC to disciminate messages by type.
+Note that dynamic casts are ususally not very expensive, but relative to the high performance of the rest of the implementation of the \uC actor system, the cost is significant.
 \begin{figure}
 …
 \end{figure}
+The repeat microbenchmark also evaluates the executor. It stresses the executor's ability to withstand contention on queues, as it repeatedly fans out messages from a single client to 100000 servers who then all respond to the client. After this scatter and gather repeats 200 times the benchmark terminates. The messages from the servers to the client will likely all come in on the same queue, resulting in high contention. As such this benchmark will not scale with the number of processors, since more processors will result in higher contention. In Figure~\ref{f:RepeatAMD} we can see that \CFA performs well compared to \uC, however by less of a margin than the executor benchmark. One factor in this result is that the contention on the queues poses a significant bottleneck. As such the gains from using the copy queue are much less apparent.
+The repeat microbenchmark also evaluates the executor.
+It stresses the executor's ability to withstand contention on queues, as it repeatedly fans out messages from a single client to 100000 servers who then all respond to the client.
+After this scatter and gather repeats 200 times the benchmark terminates.
+The messages from the servers to the client will likely all come in on the same queue, resulting in high contention.
+As such this benchmark will not scale with the number of processors, since more processors will result in higher contention.
+In Figure~\ref{f:RepeatAMD} we can see that \CFA performs well compared to \uC, however by less of a margin than the executor benchmark.
+One factor in this result is that the contention on the queues poses a significant bottleneck.
+As such the gains from using the copy queue are much less apparent.
 \begin{figure}
 …
 In Figure~\ref{f:RepeatIntel} \uC and \CFA are very comparable.
+In comparison with the other systems \uC does well on the repeat benchmark since it does not have work stealing. The client of this experiment is long running and maintains a lot of state, as it needs to know the handles of all the servers. When stealing the client or its respective queue (in \CFA's inverted model), moving the client incurs a high cost due to cache invalidation. As such stealing the client can result in a hit in performance.
+In comparison with the other systems \uC does well on the repeat benchmark since it does not have work stealing.
+The client of this experiment is long running and maintains a lot of state, as it needs to know the handles of all the servers.
+When stealing the client or its respective queue (in \CFA's inverted model), moving the client incurs a high cost due to cache invalidation.
+As such stealing the client can result in a hit in performance.
 This result is shown in Figure~\ref{f:cfaRepeatAMD} and \ref{f:cfaRepeatIntel} where the no-stealing version of \CFA performs better than both stealing variations.
+In particular on the Intel machine in Figure~\ref{f:cfaRepeatIntel}, the cost of stealing is higher, which can be seen in the vertical shift of Akka, CAF and CFA results in Figure~\ref{f:RepeatIntel} (\uC and ProtoActor do not have work stealing). The shift for CAF is particularly large, which further supports the hypothesis that CAF's work stealing is particularly eager.
+In both the executor and the repeat benchmark CAF performs poorly. It is hypothesized that CAF has an aggressive work stealing algorithm, that eagerly attempts to steal. This results in poor performance in benchmarks with small messages containing little work per message. On the other hand, in \ref{f:MatrixAMD} CAF performs much better since each message has a large amount of work, and few messages are sent, so the eager work stealing allows for the clean up of loose ends to occur faster. This hypothesis stems from experimentation with \CFA. CAF uses a randomized work stealing heuristic. In \CFA if the system is tuned so that it steals work much more eagerly with a randomized it was able to replicate the results that CAF achieves in the matrix benchmark, but this tuning performed much worse on all other microbenchmarks that we present, since they all perform a small amount of work per message.
+In particular on the Intel machine in Figure~\ref{f:cfaRepeatIntel}, the cost of stealing is higher, which can be seen in the vertical shift of Akka, CAF and CFA results in Figure~\ref{f:RepeatIntel} (\uC and ProtoActor do not have work stealing).
+The shift for CAF is particularly large, which further supports the hypothesis that CAF's work stealing is particularly eager.
+In both the executor and the repeat benchmark CAF performs poorly.
+It is hypothesized that CAF has an aggressive work stealing algorithm, that eagerly attempts to steal.
+This results in poor performance in benchmarks with small messages containing little work per message.
+On the other hand, in \ref{f:MatrixAMD} CAF performs much better since each message has a large amount of work, and few messages are sent, so the eager work stealing allows for the clean up of loose ends to occur faster.
+This hypothesis stems from experimentation with \CFA.
+CAF uses a randomized work stealing heuristic.
+In \CFA if the system is tuned so that it steals work much more eagerly with a randomized it was able to replicate the results that CAF achieves in the matrix benchmark, but this tuning performed much worse on all other microbenchmarks that we present, since they all perform a small amount of work per message.
 \begin{table}[t]
 …
 \end{table}
+Figure~\ref{t:ExecutorMemory} shows the high memory watermark of the actor systems when running the executor benchmark on 48 cores. \CFA has a high watermark relative to the other non-garbage collected systems \uC, and CAF. This is a result of the copy queue data structure, as it will overallocate storage and not clean up eagerly, whereas the per envelope allocations will always allocate exactly the amount of storage needed.
+Figure~\ref{t:ExecutorMemory} shows the high memory watermark of the actor systems when running the executor benchmark on 48 cores.
+\CFA has a high watermark relative to the other non-garbage collected systems \uC, and CAF.
+This is a result of the copy queue data structure, as it will overallocate storage and not clean up eagerly, whereas the per envelope allocations will always allocate exactly the amount of storage needed.
 \subsection{Matrix Multiply}
+The matrix benchmark evaluates the actor systems in a practical application, where actors concurrently multiplies two matrices. The majority of the computation in this benchmark involves computing the final matrix, so this benchmark stresses the actor systems' ability to have actors run work, rather than stressing the executor or message sending system.
+The matrix benchmark evaluates the actor systems in a practical application, where actors concurrently multiplies two matrices.
+The majority of the computation in this benchmark involves computing the final matrix, so this benchmark stresses the actor systems' ability to have actors run work, rather than stressing the executor or message sending system.
 Given $Z_{m,r} = X_{m,n} \cdot Y_{n,r}$, the matrix multiply is defined as:
 …
 \end{displaymath}
+The benchmark uses input matrices $X$ and $Y$ that are both $3072$ by $3072$ in size. An actor is made for each row of $X$ and is passed via message the information needed to calculate a row of the result matrix $Z$.
+Given that the bottleneck of the benchmark is the computation of the result matrix, it follows that the results in Figures~\ref{f:MatrixAMD} and \ref{f:MatrixIntel} are clustered closer than other experiments. In Figure~\ref{f:MatrixAMD} \uC and \CFA have identical performance and in Figure~\ref{f:MatrixIntel} \uC pulls ahead og \CFA after 24 cores likely due to costs associated with work stealing while hyperthreading. As mentioned in \ref{s:executorPerf}, it is hypothesized that CAF performs better in this benchmark compared to others due to its eager work stealing implementation. In Figures~\ref{f:cfaMatrixAMD} and \ref{f:cfaMatrixIntel} there is little negligible performance difference across \CFA stealing heuristics.
+The benchmark uses input matrices $X$ and $Y$ that are both $3072$ by $3072$ in size.
+An actor is made for each row of $X$ and is passed via message the information needed to calculate a row of the result matrix $Z$.
+Given that the bottleneck of the benchmark is the computation of the result matrix, it follows that the results in Figures~\ref{f:MatrixAMD} and \ref{f:MatrixIntel} are clustered closer than other experiments.
+In Figure~\ref{f:MatrixAMD} \uC and \CFA have identical performance and in Figure~\ref{f:MatrixIntel} \uC pulls ahead og \CFA after 24 cores likely due to costs associated with work stealing while hyperthreading.
+As mentioned in \ref{s:executorPerf}, it is hypothesized that CAF performs better in this benchmark compared to others due to its eager work stealing implementation.
+In Figures~\ref{f:cfaMatrixAMD} and \ref{f:cfaMatrixIntel} there is little negligible performance difference across \CFA stealing heuristics.
 \begin{figure}

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 9a5a2cd for doc/theses/colby_parsons_MMAth/text/actors.tex

Legend:

doc/theses/colby_parsons_MMAth/text/actors.tex

Download in other formats: