diff options
| -rw-r--r-- | thesis/parts/design.tex | 26 | ||||
| -rw-r--r-- | thesis/parts/implementation.tex | 4 |
2 files changed, 22 insertions, 8 deletions
diff --git a/thesis/parts/design.tex b/thesis/parts/design.tex index ce7fa8e..0a93836 100644 --- a/thesis/parts/design.tex +++ b/thesis/parts/design.tex @@ -27,10 +27,8 @@ This method works well for many operations and structures, although has notable For example, the container implementation \code{LazySortedVec} (provided by Primrose) inserts new elements at the end by default, and only sorts them when an operation that relies on the order is called. -This means that operations which are performed on a full container will appear much worse than they should, since they must do work 'deferred' by the benchmarking setup. -To prevent this, we perform some untimed 'warmup' operations. - -\todo{No the fuck we don't} +were unable to work around this, although a potential later solution could be to perform untimed 'warmup' operations before each operation. +this is complex because it requires some understanding of what operations will have deferred work for them. Once we have the data, we fit a polynomial to the data. Whilst we could use a more complex technique, in practice this is good enough: Very few common operations are above $O(n^3)$, and factors such as logarithms are usually 'close enough'. @@ -44,7 +42,27 @@ As mentioned above, the ordering of operations can have a large effect on contai Unfortunately, tracking every container operation in order quickly becomes unfeasible, so we settle for tracking the count of each operation, and the size of the collection. Every instance of the collection is tracked separately, and results are collated after profiling. +results with a close enough n value get sorted into partitions, where each partition has the average amount of each operation, and a weight indicating how common results in that partition were. +this is done to compress the data, and also to allow searching for adaptive containers later + +\todo{deal with not taking into account 'preparatory' operations during benchmarks} \todo{Combining} +\subsection{Adaptive Containers} + +adaptive containers are implemented using const generics, and a wrapper class. + +they are detected by finding the best implementation for each partition, sorting by n, and seeing if we can split the partitions in half where a different implementation is best on each side + +we then check if the cost saving is greater than the cost of a clear operation and n insert operations + +\subsection{Associative Collections for Primrose} + +We add a new mapping trait to primrose to express KV maps + +\todo{add and list library types} + +the constraint solver has been updated to allow properties on dicts (dictproperty), but this was unused. + \todo{Summary} diff --git a/thesis/parts/implementation.tex b/thesis/parts/implementation.tex index 884f675..f5d8d1f 100644 --- a/thesis/parts/implementation.tex +++ b/thesis/parts/implementation.tex @@ -34,13 +34,9 @@ on drop, creates new file in folder specified by env variable primrose results generated in \code{primrose::codegen}, which is called in \code{candelabra::profiler} picks the first valid candidate - performance doesn't really matter for this case each drop generates a file, so we get details of every individual collection allocated -\todo{immediately aggregate these into summary statistics, for speed} -\todo{mention benchmark repetition} estimate a cost for each candidate: op(avg\_n) * op\_times for each op pick the smallest one -\todo{update for nsplit stuff} -\todo{mention difficulties with lazy vecs} \todo{Caching} \todo{Other implementation details?} |