cudnn_install.txt says:
“Extract the cuDNN archive to a directory of your choice, referred to below as .”
Then, for all three OSes it says to extend the path with , which, I think, pretty much misses the point.
E.g. for TensorFlow (and I guess for all other applications) CUDA is required and I think the cuDNN directories should be merged with the respective CUDA ones, using the CUDA path and obviating the need to set another path.
Greetings
G.
I don’t see the logic here. Many libraries depend on, and require, glibc. Placing all of them in the same directory as glibc doesn’t seem like a good idea. Directories which, eventually, accumulate thousands of files in them don’t make it easy for humans to find their way around, that’s why directory hierarchies were introduced in the first place.
Especially for products on different release cycles as CUDA (I think this applies to cuDNN?) sticking each product into a separate tree makes more sense to me and is a strategy followed my many products on many platforms in similar situations.
Thanks for your thoughts!
The logic is that there already is a huge assortment of libs in the CUDA install dir. (cuBLAS, cuFFT, cuSPARSE, you name it)
The reason that I cared to post: past problems with Windows PATH length limit
Greetings
G.
There’s nothing that prevents you from putting the cuDNN library where you wish, for example so as to avoid having to spell out another path.
If you look around on the interwebs, people regularly suggest putting it in /usr/local/cuda/lib64 or whatever is the equivalent location on windows.
For example, if you follow the instructions here:
[url]http://www.nvidia.com/object/gpu-accelerated-applications-tensorflow-installation.html[/url]
You will find that the cuDNN library ends up in the same place as all the other libs you are suggesting.
For general usage, there is no requirement or restriction that cuDNN must be in that location, of course.
So, didn´t I exactly suggest that?! And @njuffa sees no logic therein.
I asked for the install instructions to be enhanced. No sloppy “put it somewhere and add Yet Another path”.
Or better: cuDNN not only be a zip / tgz, but an .msi / .deb,… like the CUDA installer – with the proper defaults.
I started this to give everyone one less head-scratching.
I wanted to fit TensorFlow GPU and CNTK GPU on the same physical machine (no-go for GPU on a VM) and if that´s not enough prerequisites (exact version,…), then have a look at the dozen (or more) exact version and path requirements to compile CNTK – to give you the shivers.
But let´s stop it here, because it´s no bug and if you do it right, whatever way, it´ll work.
Regards
G.
I have done software development on Windows since version 3.1 (around 1992?). I have yet to run into a PATH limit, but checking relevant documentation right now it seems that under Windows 7 there is such a limit, and it is 2047 characters by default, and 4095 characters as maximum configurable length.
The obvious workaround would be to put different products into directories with short names. Only if that fails would I elect to put a bunch of libraries into a catch-all common directory (creates a disorderly “trash heap”, IMHO).
But the issue seems to be generic and not one caused by cuDNN in particular.
Yup, 2047 and I ran into it with all kinds of weird effects until I realized and in CNTK dev is a warning re XCOPY 256 char path expression limit and at the company with a coupla million line SVN repo and a coupla hundred devs you have to shorten file names before you can del some subtrees in Windoze.
I don’t know what CNTK is, and why it apparently requires oodles of paths to be added to PATH. PATH is for executables; LIB should be used for library locations and INCLUDE for header files locations.
I was aware of the 255 character limit for a single full path name, but I have never hit the PATH limit of 2047 characters. From what I understand now it can be expanded to 4095 characters, but this requires a reboot!
What can I say? It’s a shame what hoops Microsoft sometimes forces programmers to jump through. Systems with GB upon GB of system memory, but ridiculously tight limits on the length of environment variables? Someone ought to complain to the people in charge in Redmond.
I call it the “Windows tax”, and automatically add 30% effort to any project estimates that target Windows instead of Linux.
More PATH gotchas to top it off:
When you finally realize that a cut off PATH screws things up, the System control (that I guess hasn´t changed since Windows 95, but got wrapped in yet other control) lets you put in a longer PATH, but cuts it off behind your back when you save.
A big part of quick hack browser stupid text controls tell you when you exceed the char limit.
So much for Windows 7 (and earlier) “state-of-the-art” with 75% market share.
I wouldn´t want to try the claimed 4095 limit on 10 (and the possible hoops you have to jump through to make it happen) and the FUD on StackOverflow, cuz I´m afraid it would be another waste of time.
I know my way around with user path,…, so RIP.
And don´t tell me Linux or even OS-X is so much better, because I´ve had enough Shuttleworth et al trials and tribulations with startup and GUI,… to make me cringe. And don´t get me even started with Apple.
Something constructive for a change:
I appreciate Microsoft joining the circle with their CNTK deep learning framework (beat Google,… at MNIST 2015) and their opening up to Python with V2, but because of the effort the dev setup makes you shiver.
It´s literally around a dozen paths and versions to obey. The worst of it to litter your machine with I guess 20 GB of ancient Visual Studio 2013 and bet no way to co-exist with 2015 if you wanted another 20 to 40 GB.
Regards
G.