[Proposal] API tuning for use_cudnn in LSTM/other layers about keras HOT 5 OPEN

Right now you're basically not supposed to pass use_cudnn in the general case -- just pass nothing, and cuDNN will be used if it's feasible.

Passing use_cudnn=True is something you'd only do if you want to error out when cuDNN isn't available, as opposed to falling back to a non-cuDNN implementation.

I propose to alleviate this we always provide a reason why cudnn was not used.

Definitely, this is a good call. There are multiple user-facing factors at play, like recurrent dropout, masking (which will actually give you a targeted error message), activations, etc. And of course availability of cuDNN in your environment.

from keras.

Right now you're basically not supposed to pass use_cudnn in the general case -- just pass nothing, and cuDNN will be used if it's feasible.

I guess what I'd be hoping to gain from an additional API here would be to express in code:

"I want to make sure that my Keras code is not the reason that we aren't using cudnn.
 If the backend/environment doesnt support it, that is alright - 
but I want to make sure I do not accidentally have the flags misconfigured"

though, perhaps just improving the error messages is sufficient

from keras.

Hey @LukeWood ,

I want to make sure that my Keras code is not the reason that we aren't using cudnn

That's how I look at the use_cudnn argument. It really means "fail if you can't use cudnn".

though, perhaps just improving the error messages is sufficient

I think that's the right call. Are you willing to contribute on this?

from keras.

yes happy to contribute!

It really means "fail if you can't use cudnn".

I think the key difference is that to me there are actually two intentions users may want to express. One is "fail if you can't use cudnn, regardless of cause" - one is "fail if I can't use cudnn, due to my own configuration of the RNN layer". I think they're nuancedly different, but that the difference is actually meaningful. Perhaps what I mean here would be clarified via code, but I think there is a meaningful difference between these two intentions.

Regardless, happy to contribute error message improvements.

from keras.

Regardless, happy to contribute error message improvements.

Sure, please open a PR if you're able. We probably need to make two backend functions, is_config_cudnn_compatible and is_cudnn_available -- or maybe pass appropriate info in the NotImplementedError exception message.

from keras.