diff options
author | Aria <me@aria.rip> | 2023-09-25 16:55:51 +0100 |
---|---|---|
committer | Aria <me@aria.rip> | 2023-09-25 16:55:51 +0100 |
commit | 7a2f28991311efe268be40a2fe4ae92f4c1c4a45 (patch) | |
tree | 86f3016e480ca756621ceb261e9f08d48ca03c67 | |
parent | 747029c9313f5b79d0ef19f9cddee79ae555dcdc (diff) |
add tasks file
-rw-r--r-- | Tasks.org | 52 |
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 |