You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 28, 2020. It is now read-only.
This is more apparent in memory hard algorithms.
The current way the slider is generated is too inflexible, it can cause the card to run out of max alloc size and cause a stop.
That shouldn't be the case: since I'm now data driven I can adapt in advance.
Protocol needs to be extended to provide fixed costs and linear sizes required.
What if we consume very little memory? What in the case of grsmyr, which consumes O(1) memory?
Upper bound could easily be numCU_4_64*N on GCN.
Similar for lower bound, but I might want to force that only for algorithms which are not memory-hard. How do I evaluate that property? Several possibilities. Be sure to not end up like in the beginning, when the upper bound eventually turned out to be too little.
This is more apparent in memory hard algorithms.
The current way the slider is generated is too inflexible, it can cause the card to run out of max alloc size and cause a stop.
That shouldn't be the case: since I'm now data driven I can adapt in advance.
Protocol needs to be extended to provide fixed costs and linear sizes required.
What if we consume very little memory? What in the case of grsmyr, which consumes O(1) memory?
Upper bound could easily be numCU_4_64*N on GCN.
Similar for lower bound, but I might want to force that only for algorithms which are not memory-hard. How do I evaluate that property? Several possibilities. Be sure to not end up like in the beginning, when the upper bound eventually turned out to be too little.
Interacts with #31.
The text was updated successfully, but these errors were encountered: