Thank you for developing JCuda! I’m setting up an HPC workstation for neural net development, and I want to use Java for development under Windows. I’d like to buy the gtx 1080 for its speed advantage, but it might have compatibility issues with Cuda tools 7.5. Cuda Toolkit 8 RC is out which supports the 1080, but understandably JCuda is not yet compiled for it. I’d like to start developing within a few weeks, but I’m wondering if I should start by picking up an older, cheaper card that will work with JCuda first, then get the 1080 when JCuda for version 8 is available. Does anybody have any thoughts on this, or has anybody used JCuda on a 1080 yet?
Admittedly, I wasn’t aware of the specific limitations and incompatibilties regarding the GTX 1080 and CUDA 7.5. Websearches bring some related threads, e.g. https://devtalk.nvidia.com/default/topic/948997/is-cuda-toolkit-8-0rc-mandatory-for-gtx-1080-/ , but you likely found these already. I can’t imagine that the 1080 is so “non-backward-compatible” that it’s really worth to buy a different card to only use it a few weeks, but maybe I overlooked some caveat here. It’s a new CC version, but usually, there is no problem with running CC 2.0 programs even on CC 5.2 cards - at least, after a recompilation.
Right now, I can’t give a profound advice here. I can only try to schedule the update for CUDA 8 RC ASAP. (The 8 RC has been out for quite a while, and usually, I try to start the update of JCuda based on the RC, but haven’t looked at the 8 RC yet - sorry about that). There are several other tasks in the queue, but IF there haven’t been too many changes, it might not take so long.
Thanks very much for your response. Yes - it was that link that raised this concern for me. For a Cuda beginner, the possible necessity to build my code with PTX that can be forward JIT-compiled is a bit daunting, knowing nothing about it. Maybe the best thing for me to do is get the 1080, along with the K620 I’m going to get anyway to drive the display, and try running cuda on the 1080. If that doesn’t work, I can just use the 1080 as the display driver and run Cuda on the K620 until the new JCuda is ready. Thanks again!
I was delayed due to a medical emergency, but I’m starting work with JCuda now. I noticed there are no .dlls with the version 8 release, so I just copied the .dlls from the previous release. When I do this, I get an unsatisfied link error when I run the JCudaRuntimeTest: ‘Error while loading native library “JCudaRuntime-0.8.0RC-windows-x86_64”’. The .dll file names don’t include any version information, so to workaround this I just changed the name of the .dll file from the previous release to include the version information, and it worked. Can I just do this with the other .dlls as well, or did the .dlls change with the new version?
First of all: The current version of JCuda, 0.8.0RC, is for the CUDA 8 Release Candidate. I wonder whether you really have this, because it is/was only available for NVIDIA registered developers.
CUDA 8 (final) was released a few days ago. The corresponding update of JCuda is on the way, and should be available soon.
So which CUDA version do you currently use?
Regardless of that, here is why there seem to be no DLLs in JCuda 0.8.0RC:
Starting with JCuda 0.8.0RC, the DLLs are contained in the JAR files. The purpose of this is to
Prepare everything to bring JCuda into Maven Central
Simplify the deployment and “installation” in general
So with the future JCuda versions, it is no longer necessary to copy the DLLs manually. One just has to add all JARs to the classpath (including the ones that are named “jcublas-natives-0.8.0RC-windows-x86_64.jar”, which contain the DLLs). The DLLs will then be unpacked at runtime (into the TEMP directory), and loaded from there - transparently for the user. It should just “feel” like it was a pure Java library that only consists of some JARs.
You’re right - although I am an NVIDIA registered developer, by the time I downloaded CUDA the RC version had been replaced with 8.0, so I downloaded that without thinking much about it.
I suspected that the DLLs were included within the jars - I probably should have just asked about that right away rather than blundering forward, but I wanted to see how far I could get with it.
The github page sheds light on the situation - thanks.
So for right now, do you think the best approach is for me to go back and download the CUDA RC version to use with JCuda RC?
That depends on several factors, and there are several options - I’m not sure which one is most appropriate for you.
You could try whether you can use JCuda 0.8.0RC together with CUDA 8.0 (final). I don’t know what they changed between the “RC” and the “final” version. It might just work, if there have been no “structural” changes. In any case, it’s worth a try, because it can’t do any harm except for throwing an UnsatisfiedLinkError saying ~“can’t find dependent libraries”
Assuming that you still have CUDA 7.5 installed, it should be possible to still use JCuda 0.7.5b (maybe you’ll have to adjust your PATH environment variable to not point to some “CUDA/8.0/” directory, but to “CUDA/7.5/” instead)
I don’t know how “urgently” you need to start. I should be able to do the update to CUDA 8.0 (final) by the end of next week, but there are some unknowns involved, and I can not promise it.
If it’s urgent, and if it has to be the latest CUDA/JCuda version, then you may consider installing CUDA 8.0 RC, but
I’m not sure how well a “downgrade” from 8.0 to 8.0RC works: The NVIDIA installer uses the same directory name, “8.0”, for both versions. So to install the RC “cleanly”, it might be necessary to uninstall 8.0 (final) first
Thanks very much. I think I will try 1) first, then 4) (after uninstalling 8.0) then 2) if necessary.
I don’t have any strict deadlines to meet, although I do want to move along as quickly as I can (delayed as it happens by surgeries last month and again hopefully in six weeks or so). The work is to evaluate what initial single-threaded testing suggests is a useful new form of regularization for feedforward/backprop NNs, and this was just a natural time to start parallelizing, as I’ve just completed conversion of the baseline algorithm to matrix form. But there’s still more to do with algorithm coding, so if neither of the above steps work, I can occupy myself with that until JCuda 8 is up.
Yes - once I’ve got a basic handle on CUDA/JCuda and have sped up the algorithm using simple vector/matrix kernels, I plan to look at the accelerated libraries to see what they can do and whether/how I might integrate them into testing.
Thank you! So far I’ve been able to write and run a matrix multiplication kernel that yields very large accelerations over the computations done on the CPU. I’d like to try cublas too, though, to see if it can do better, but so far I haven’t got that to work. I’ll download the new final version and set that up.
I get an unsatisfied link error for the JCublas dll. It may well be a version incompatibility issue between CUDA and JCuda, because although I did download CUDA 8.0.27 (RC) to use with JCuda RC, for whatever reason I wasn’t able to get the two RC versions working together. But I could get JCuda RC working with the CUDA 8 release version for the purposes of writing my own kernels (CUBLAS gives me the error though). So it may well be that just downloading JCuda 8 final will resolve the issue.
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
Sorry - “version incompatibility issue” wasn’t a precise way of putting it - I think the problem is caused by the fact that I basically hacked the JCuda/Cuda installation using bits of different versions. As I recall, JCuda RC includes the dlls inside the jars but I couldn’t get that to work (even after regressing my CUDA version to 8.0.27 RC), so for plain jcuda I just downloaded the version 7.5 dll and inserted the “0.8.0RC” version number into the file name and it worked. But when I tried the same trick with the CUBLAS dll it didn’t work, giving the above error.
So my installation is obviously a mess right now. But it has allowed me to write and test the kernels that I need!
I will now work on installing things properly, and everything should work (though I may have another question or two).
By the way, thank you for solving my out-of-memory error on stackoverflow! After casting the last cuMalloc argument to long, I can now access the full memory on the card. I didn’t ask you directly because I didn’t know if the problem was caused by CUDA, JCuda, or just java, and I didn’t want to bother you with it on this forum.
OK, after manually messing around with library names, this is not sooo surprising.
(The reason why it worked for CUDA is likely that the library name here is „nvcuda.dll“, which, in contrast tu CUBLAS, does not have a version number).
If you still encounter problems with the 0.8.0+ versions (with the DLL-in-JAR approach), I’d really like to know about this, because there still wasn’t much feedback about this. (It could have some additional caveats on MacOS, but there don’t seem to be so many MacOS+CUDA-users out there…)
That’s what the forum is for! Many people at stackoverflow have very specific constaints for what they consider as a „good“ question. The downvote of the question is thus not unusual or unexpected, but … seemed a bit inappropriate, though.