diff options
| -rw-r--r-- | thesis/parts/background.tex | 2 | ||||
| -rw-r--r-- | thesis/parts/design.tex | 34 | ||||
| -rw-r--r-- | thesis/parts/introduction.tex | 2 |
3 files changed, 30 insertions, 8 deletions
diff --git a/thesis/parts/background.tex b/thesis/parts/background.tex index 38cadac..a4383bc 100644 --- a/thesis/parts/background.tex +++ b/thesis/parts/background.tex @@ -1,4 +1,4 @@ -In this chapter we provide an overview of the problem of container selection and its effect on program correctness and performance. +In this chapter, we provide an overview of the problem of container selection and its effect on program correctness and performance. We then provide an overview of approaches from modern programming languages and existing literature. Finally, we explain how our system is novel, and the weaknesses in existing literature it solves. diff --git a/thesis/parts/design.tex b/thesis/parts/design.tex index 6886c9c..9b8ebce 100644 --- a/thesis/parts/design.tex +++ b/thesis/parts/design.tex @@ -1,26 +1,33 @@ -This chapter outlines the design of our container selection system (Candelabra), and the justification behind these design decisions. +This chapter outlines the design of our container selection system (Candelabra), and justifies our design decisions. We first describe our aims and priorities for the system, and illustrate its usage with an example. We then provide an overview of the container selection process, and each part in it. +We leave detailed discussion of implementation for chapter \ref{chap:implementation}. + \section{Aims \& Usage} -We aim to create a program for container selection that can select based on both functional and non-functional requirements. +As mentioned previously, we aim to create an all-in-one solution for container selection that can select based on both functional and non-functional requirements. Flexibility is a high priority: It should be easy to add new container implementations, and to integrate our system into existing applications. Our system should also be able to scale to larger programs, and remain convenient for developers to use. We chose to implement our system as a Rust CLI, and to work on programs also written in Rust. +We chose Rust both for the expressivity of its type system, and its focus on speed and low-level control. +However, most of the techniques we use are not tied to Rust in particular, and so should be possible to generalise to other languages. + We require the user to provide their own benchmarks, which should be representative of a typical application run - without this, we have no consistent way to evaluate speed. -Users can specify their functional requirements by listing the required traits, and specifying properties that must always hold in a lisp-like language. +Users specify their functional requirements by listing the required traits and properties they need for a given container type. +Traits are Rust's primary method of abstraction, and are similar to interfaces in object-oriented languages, or typeclasses in functional languages. +Properties are specified in a lisp-like DSL as a predicate on a model of the container. For example, Listing \ref{lst:selection_example} shows code from our test case based on the sieve of Eratosthenes (\code{src/tests/prime_sieve} in the source artifacts). Here we request two container types: \code{Sieve} and \code{Primes}. The first must implement the \code{Container} and \code{Stack} traits, and must satisfy the \code{lifo} property. This property is defined at the top as only being applicable to \code{Stack}s, and requires that for any \code{x}, pushing \code{x} then popping from the container returns \code{x}. The second container type, \code{Primes}, must only implement the \code{Container} trait, and must satisfy the \code{ascending} property. -This property requires that at any point, for all consecutive \code{x, y} pairs in the container, \code{x <= y}. +This property requires that for all consecutive \code{x, y} pairs in the container, \code{x <= y}. \begin{figure} \begin{lstlisting}[caption=Container type definitions for prime\_sieve,label={lst:selection_example}] @@ -40,9 +47,24 @@ type Primes<S> = {c impl (Container) | (ascending c)} \end{lstlisting} \end{figure} -Once we've specified our functional requirements and provided a benchmark (\code{src/tests/prime_sieve/benches/main.rs}), we can simply run candelabra to select a container: +Once we've specified our functional requirements and provided a benchmark (\code{src/tests/prime_sieve/benches/main.rs}), we can simply run Candelabra to select a container: \code{candelabra-cli -p prime_sieve select}. +This command outputs something like Table \ref{table:selection_output}, and saves the best combination of container types to be used the next time the program is run. +Here, the code generated uses \code{Vec} as the implementation for \code{Sieve}, and \code{HashSet} as the implementation for \code{Primes}. -\todo{Show selection process} +\begin{table}[h] + \centering + \begin{tabular}{|c|c|c|c|} + Name & Implementation & Estimated Cost \\ + \hline + Sieve & std::vec::Vec & 159040493883 \\ + Sieve & std::collections::LinkedList & 564583506434 \\ + Primes & primrose\_library::SortedVec & 414991320 \\ + Primes & std::collections::BTreeSet & 355962089 \\ + Primes & std::collections::HashSet & 309638677 \\ + \end{tabular} + \caption{Example output from selection command} + \label{table:selection_output} +\end{table} \section{Overview of process} diff --git a/thesis/parts/introduction.tex b/thesis/parts/introduction.tex index 6886f35..068b1a5 100644 --- a/thesis/parts/introduction.tex +++ b/thesis/parts/introduction.tex @@ -16,6 +16,7 @@ The underlying implementation of container types which function the same can hav %% *** Motivate w/ effectiveness claims We propose a system, Candelabra, for the automatic selection of container implementations, based on both user-specified requirements and inferred requirements for performance. +From our testing, we are able to select the best performing containers for a program, in significantly less time than brute force. %% *** Overview of aims & approach %% **** Ease of adding new container types @@ -30,4 +31,3 @@ Our system is also able to suggest adaptive containers --- containers which swit %% *** Overview of results \todo{Overview of results} - |