1 files changed, 36 insertions, 33 deletions
diff --git a/thesis/parts/implementation.tex b/thesis/parts/implementation.tex
index 1c131ed..cd7b4b7 100644
--- a/thesis/parts/implementation.tex
+++ b/thesis/parts/implementation.tex
@@ -1,4 +1,5 @@
-\todo{Introduction}
+This chapter elaborates on some implementation details glossed over in the previous chapter.
+With reference to the source code, we explain the structure of our system's implementation, and highlight areas with difficulties.
 
 \section{Modifications to Primrose}
 
@@ -14,7 +15,29 @@ Operations on mapping implementations can be modelled and checked against constr
 They are modelled in Rosette as a list of key-value pairs.
 \code{src/crates/library/src/hashmap.rs} shows how mapping container types can be declared, and operations on them modelled.
 
-\todo{add and list library types}
+Table \ref{table:library} shows the library of container types we used.
+Most come from the Rust standard library, with the exceptions of \code{SortedVec} and \code{SortedUniqueVec}, which use \code{Vec} internally.
+The library source can be found in \code{src/crates/library}.
+
+\todo{This might be expanded}
+
+\begin{table}[h]
+  \centering
+  \begin{tabular}{|c|c|c|}
+    Implementation & Description \\
+    \hline
+    \code{LinkedList} & Doubly-linked list \\
+    \code{Vec} & Contiguous growable array \\
+    \code{SortedVec} & Vec kept in sorted order \\
+    \code{SortedUniqueVec} & Vec kept in sorted order, with no duplicates \\
+    \code{HashMap} & Hash map with quadratic probing \\
+    \code{HashSet} & Hash map with empty values \\
+    \code{BTreeMap} & B-Tree\parencite{bayer_organization_1970} map with linear search. \\
+    \code{BTreeSet} & B-Tree map with empty values \\
+  \end{tabular}
+  \caption{Implementations in our library}
+  \label{table:library}
+\end{table}
 
 We also added new syntax to the language to support defining properties that only make sense for mappings (\code{dictProperty}), however this was unused.
 
@@ -39,39 +62,38 @@ When benchmarks need to be run for an implementation, we dynamically generate a
 As Rust's generics are monomorphised, our generic code is compiled as if we were using the concrete type in our code, so we don't need to worry about affecting the benchmark results.
 
 Each benchmark is run in a 'warmup' loop for a fixed amount of time (currently 500ms), then runs for a fixed number of iterations (currently 50).
-This is important because we use every observation when fitting our cost models, so varying our number of iterations would change our curve's fit.
-We repeat each benchmark at a range of $n$ values, ranging from $64$ to $65,536$.
+This is important because we use every observation when fitting our cost models, so varying the number of iterations would change our curve's fit.
+We repeat each benchmark at a range of $n$ values, ranging from $10$ to $60,000$.
 
 Each benchmark we run corresponds to one container operation.
-For most operations, we prepare a container of size $n$ and run the operation once per iteration.
+For most operations, we insert $n$ random values to a new container, then run the operation once per iteration.
 For certain operations which are commonly amortized (\code{insert}, \code{push}, and \code{pop}), we instead run the operation itself $n$ times and divide all data points by $n$.
 
-Our benchmarker crate outputs every observation in a similar format to Criterion (a popular benchmarking crate for Rust).
-We then parse this from our main program, and use least squares to fit a polynomial to our data.
-We initially tried other approaches to fitting a curve to our data, however we found that they all overfitted, resulting in more sensitivity to benchmarking noise.
+We use least squares to fit a polynomial to all of our data.
 As operations on most common data structures are polynomial or logarithmic complexity, we believe that least squares fitting is good enough to capture the cost of most operations.
-
-\todo{variable coefficients, which ones we tried}
+We originally experimented with coefficients up to $x^3$, but found that this led to bad overfitting.
 
 \section{Profiling}
 
-We implement profiling by using a \code{ProfilerWrapper} type (\code{src/crates/library/src/profiler.rs}), which takes as a type parameter the 'inner' container implementation.
+We implement profiling by using a \code{ProfilerWrapper} type (\code{src/crates/library/src/profiler.rs}), which takes as type parameters the 'inner' container implementation and an index later used to identify what type the profiling info corresponds to.
 We then implement any primrose traits that the inner container implements, counting the number of times each operation is called.
 We also check the length of the container after each insertion operation, and track the maximum.
 
 This tracking is done per-instance, and recorded when the instance goes out of scope and its \code{Drop} implementation is called.
-We write the counts of each operation and maximum size of the collection to a location specified by an environment variable, and a constant generic parameter which allows us to match up container types to their profiler outputs.
+We write the counts of each operation and maximum size of the collection to a location specified by an environment variable.
 
 When we want to profile a program, we pick any valid inner implementation for each selection site, and use that candidate with our profiling wrapper as the concrete implementation for that site.
 
 This approach has the advantage of giving us information on each individual collection allocated, rather than only statistics for the type as a whole.
 For example, if one instance of a container type is used in a very different way from the rest, we will be able to see it more clearly than a normal profiling tool would allow us to.
-Although it has some amount of overhead, it's not important as we aren't measuring the program's execution time when profiling.
+
+Although there is noticeable overhead in our current implementation, it's not important as we aren't measuring the program's execution time when profiling.
+Future work could likely improve the overhead by batching file outputs, however this wasn't necessary for us.
 
 \section{Selection and Codegen}
 
 %% Selection Algorithm incl Adaptiv
-Selection is done per container site.
+Selection is done per container type.
 For each candidate implementation, we calculate its cost on each partition in the profiler output, then sum these values to get the total estimated cost for each implementation.
 This provides us with estimates for each singular candidate.
 
@@ -144,22 +166,3 @@ fn _StackCon<S: PartialEq + Ord + std::hash::Hash>() -> StackCon<S> {
 }
 \end{lstlisting}
 \end{figure}
-
-\section{Miscellaneous concerns}
-
-In this section, we highlight some other design decisions we made, and justify them.
-
-\todo{Explain cargo's role in rust projects \& how it is integrated}
-
-%% get project metadata from cargo
-%% available benchmarks and source directories
-%% works with most projects
-%% could be expanded to run as cargo command
-
-\todo{Caching and stuff}
-
-\todo{Ease of use}
-
-%% parse minimal amount of information from criterion benchmark
-%% most common benchmarking tool, closest there is to a standard
-%% should be easy to adapt if/when cargo ships proper benchmarking support