chore: update tasks

1 files changed, 28 insertions, 21 deletions

diff --git a/Tasks.org b/Tasks.org
index 9453f77..efbcf05 100644
--- a/Tasks.org
+++ b/Tasks.org
@@ -3,27 +3,32 @@
 
 * Original design notes
 
-  - Based on design used by collectionswitch
-    - Least intervention required per implementation
-  - Integrate with primrose to get the candidate collections
-    - Ideally this would just be using the rust crate, or having a JSON interface to a CLI
-  - For each collection and for each 'critical operation', generate a cost estimate when the collection is a given size - $C_{op}(n)$
-    - Perform operation repeatedly at various n, and fit a polynomial to that
-    - Requires some trait constraints, and some annotation of traits to know what are 'critical operations'
-    - This step should only need to be run once per computer
-      - could be shared by default and run again for better accuracy
-  - Semantic Profiler
-    - For each allocated collection:
-      - Max size (in terms of items)
-      - # of each operation
-    - This should be aggregated by 'allocation site' (specified by last few bits of callstack).
-      - Not sure how to do this, maybe look at how tracing crate does it
-    - Requires user to write their own benchmarks
-      - criterion is popular for this, and might have hooks?
-    - doesn't need to be /super/ lightweight, just enough to not make things painful to run.
-  - Approximate a cost for each candidate as $\sum_{}op C_{op}(n) * #op/#total$.
-    - We could extend this to suggest different approaches if there is a spread of max n.
-  - If time allows, could attempt to create a 'wrapper type' that switches between collections as n changes, using rules decided by something similar to the above algorithm.
+  - Existing work: Primrose
+    - Deals with selecting the best container type (currently only for lists)
+    - Specify which pre-defined interfaces are required, and which semantic properties
+      - eg ascending order, uniqueness
+    - Library of premade implementations, with simplified models of their behaviour
+    - Outputs a list of implementations that meet the given requirements
+  - Problem: Picking which one of these implementations
+    - Number of possibilities is exponential in number of types to be selected
+    - Infeasible even for larger problems
+  - Assume we have some user-defined benchmarks that we want to run well
+  - Use approach similar to collectionswitch:
+    - Least intervention required per implementation, so should scale well
+    - For each collection and for each 'critical operation', generate a cost estimate when the collection is a given size - $C_{op}(n)$
+      - Perform operation repeatedly at various n, and fit a polynomial to that
+      - Requires some trait constraints, and some annotation of traits to know what are 'critical operations'
+      - This step should only need to be run once per computer
+        - could be shared by default and run again for better accuracy
+    - Semantic Profiler
+      - For each allocated collection:
+        - Max size (in terms of items)
+        - # of each operation
+      - This should be aggregated by 'allocation site' (specified by last few bits of callstack).
+      - doesn't need to be /super/ lightweight, just enough to not make things painful to run.
+    - Approximate a cost for each candidate as $\sum_{}op C_{op}(n) * #op/#total$.
+      - We could extend this to suggest different approaches if there is a spread of max n.
+    - If time allows, could attempt to create a 'wrapper type' that switches between collections as n changes, using rules decided by something similar to the above algorithm.
 
 * DONE Integrating with Primrose
 
@@ -130,3 +135,5 @@ We compare our results to the best possible result, and to using the standard li
   - Add nix build stuff for everything
   - Nixify the install of rosette
   - See if the ~linked_list_cursors~ feature / nightly compiler is actually necessary
+
+* TODO Some plan for time management