New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nnet3- update CachingOptimizingCompiler to store a configurable number of computations. #69
Comments
@naxingyu , you might want to try this. |
I'll see what I can do. On 09/01/2015 09:48 AM, Daniel Povey wrote:
|
My guess is
Is it correct? And how would you like the key defined? I see we have On 09/01/2015 09:48 AM, Daniel Povey wrote:
|
This is not really right, it needs to be a map from something like Actually, a map may not even be necessary (or necessarily the most Dan
|
This is not really right, it needs to be a map from something like Actually, a map may not even be necessary (or not even necessarily the most Dan
|
By the way, if I understand Dan's requirements correctly, the search term to use in Google could be something like "LRU cache C++" ... |
Came up with another plan after Googling around... // The most recently accessed ComputationRequest appears at time_stemp.end()-1,
// The key is a request, the value is a pair of a pointer to the computation
// caching capacity, should be const
// This function would be called within Compile() before returning computation.
Does it make sense? |
Hi Xingyu, I haven't coded much in C++ recently, so I'm a bit rusty, and I don't know the nnet3 code, but I think that you are headed in the right direction. I think that you can get some idea about the implementation of the operations from simple examples like e.g. this one. Your code will have the advantage of using the standard unordered_map and list classes, so it could be even more succinct. I think that in addition to the hasher class you will also have to provide an implementation for the key equality operation, as explained for example in this SO answer. Perhaps, it would be good to make this code generic, i.e. template-based, if Dan thinks it might be useful in future. You could place the implementation under src/util/. Maybe something like src/util/lru-cache.h; perhaps you can borrow ideas about the structure of the code from util/hash-list.h. A minor nitpick: I think that the name "time_stamp_" is a bit misleading, because we are not keeping explicit times there- only the access order. Maybe it would be better to call it access_queue_, lru_queue_ or some such. |
I'm not sure that Xingyu is the right person to create a generic version of this thing- let's focus on the specific case for now. |
@naxingyu did this, so closing issue. |
Would require adding a hashing object for class ComputationRequest, so we can do fast lookup in a hash.
Idea is to cache the n most recently accessed Computations. Probably a reasonable default is to cache around 20 computations.
The text was updated successfully, but these errors were encountered: