diff options
| -rw-r--r-- | Tasks.org | 49 |
1 files changed, 28 insertions, 21 deletions
@@ -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 |