Multithread Variable Input Size Fix

[jonathanasdf]

Use the same instance of iSize to fix #155

After fixing this for SpatialConvolution, I went ahead and made the the same changes to other modules. Are there any tests that I can run to make sure this did not break anything?

[fmassa]

Nice!
I think that it could break saved models that haven't the iSize field (i.e., when you save a model before ever forwarding it).
Wouldn't it be better to simply lazily-initialize self.iSize = self.iSize or torch.LongTensor(4):zero() in createIODescriptors ?

[soumith]

i think we never save a model before forwarding it, it seems reasonable as a change. the lazy initialization wont work with the threading issue here.

[fmassa]

@soumith that happened at least once in the past with me torch/nn#712 (comment) , but I'd say it's a fair enough change :)

[jonathanasdf]

I kept both the explicit initialization in the constructor and the lazy initialization in createIODescriptors.

The explicit initialization is needed so that the threads share the same tensor - if there were only the lazy initialization, then each thread would create its own copy of iSize, but they still end up using the same descriptors, which leads to the problem of descriptors sometimes not being the right size.

But, when a model is created with nn modules and converted using cudnn.convert, __init is not called so iSize is not initialized. I left the lazy initialization in so this does not crash, but in that case the original bug would still exist..

[jonathanasdf]

Removed lazy initialization of iSize based on discussion above and added some hacky code to convert. It seems to still work fine based on my tests on AlexNet. Please let me know if there is a better way, or if you would prefer not to merge this change.

[borisfom]

A month ago I have taken a stab at refactoring Convolution classes : a very outdated version is here https://github.com/borisfom/cudnn.torch/tree/R5_exp (FullConvolution changed fundamentally since then). However, it may give you some ideas. The most ROI on reuse I believe can be achieved extracting the part that uses cudnnFind functons: this can be generalized across most classes, not just convolutions. Also, the selection of algo/workspace can be further improved by using new CUDNN FindEx functions.

[borisfom]

I found some neat examples of taking advantage of Lua binding of C functions by name in the new RNN class contributed by NVidia folks here: https://github.com/borisfom/cudnn.torch/blob/R5/RNN.lua (createDescriptors etc).