aboutsummaryrefslogtreecommitdiff
path: root/Tasks.org
diff options
context:
space:
mode:
authorAria <me@aria.rip>2023-09-25 16:55:51 +0100
committerAria <me@aria.rip>2023-09-25 16:55:51 +0100
commit7a2f28991311efe268be40a2fe4ae92f4c1c4a45 (patch)
tree86f3016e480ca756621ceb261e9f08d48ca03c67 /Tasks.org
parent747029c9313f5b79d0ef19f9cddee79ae555dcdc (diff)
add tasks file
Diffstat (limited to 'Tasks.org')
-rw-r--r--Tasks.org52
1 files changed, 52 insertions, 0 deletions
diff --git a/Tasks.org b/Tasks.org
new file mode 100644
index 0000000..18439de
--- /dev/null
+++ b/Tasks.org
@@ -0,0 +1,52 @@
+#+TITLE: Tasks
+
+* TODO Write background chapter
+DEADLINE: <2023-10-20 Fri>
+
+** TODO Problem Introduction
+
+- applications use many different container types
+- developers often only care about the functional requirements/semantics of these containers
+- however, they are usually forced to specify a concrete implementation (examples)
+
+** TODO Motivation
+
+ - justify performance benefit
+
+** TODO Look into Perflint
+
+https://ieeexplore.ieee.org/abstract/document/4907670
+
+** TODO Brainy
+
+ - uses ai model to predict based on target microarchitecture, and runtime behaviour
+ - uses access pattersn, etc.
+ - also assumes semantically identical set of candidates
+ - uses application generator for training data
+ - focuses on the performance difference between microarchitectures
+ - intended to be run at each install site
+
+** TODO Chameleon
+
+ - hooks into gc and uses collection twrapper to collect statistics like space utilisation and access patterns.
+ - then uses collection selection rules to suggest improvements.
+ - includes a mode for online replacement of implementation, and an automatic code modifier
+ - requires special knowledge of the concrete implementations used
+ - limited in the semantic classes it can deal with
+ - focused primarily on memory usage
+ - limited to java, and techniques used are tied to GC-based languages
+
+** TODO CollectionSwitch
+
+ - online selection - uses library so easier to integrate
+ - collects access patterns, size patterns, etc.
+ - performance model is built beforehand for each concrete implementation, with a cost model used to estimate the relative performance of each based on observed usage
+ - switches underlying implementation dynamically
+ - also able to decide size thresholds where the implementation should be changed and do this
+ - doesn't require specific knowledge of the implementations, although does still assume all are semantically equivalent
+
+** TODO Primrose
+
+- primrose allows specifying syntactic and semantic properties, and gives concrete implementations satisfying these properties
+- however, this only deals with the functional requirements for the program, and not non-functional requirements
+- it is still up to the developer to choose which of these performs the best, etc. or brute force it