I saw another topic that suggested that the library is not fully supported with nvc++ yet - is that the reason for this segfault?
If so, is there another way that I can use the library with nvc++? I’d rather stick with standard C++ for my current use case and not use CUDA if possible.
Correct that I don’t believe we’ve added support for random number generation in device code, however the compiler shouldn’t segv. Hence I added a problem report, TPR #30999, and sent it to engineering for further investigation.
Note that the segv only occurs at -O2 and above. At -O1, the compiler gives an error:
% nvc++ test.cpp -stdpar -V21.9 -O0 --c++17
NVC+±F-0155-Compiler failed to translate accelerator region (see -Minfo messages): Unsupported statement operator (test.cpp: 1)
NVC++/x86-64 Linux 21.9-0: compilation aborted
In 22.5, our engineers fixed the compiler segv. The problem had to do with the mishandling of “long double” which is used by the random number generator and isn’t supported in device. Hence the compiler now gives the following error message:
% nvc++ test.cpp -stdpar -V22.5 -O2 --c++17
NVC++-S-1207-Long double in GPU code is unsupported (test.cpp: 1791)
NVC++-F-0155-Compiler failed to translate accelerator region (see -Minfo messages): Long double in GPU code is unsupported (test.cpp: 1)
NVC++/x86-64 Linux 22.5-0: compilation aborted
Does this mean that if the random number generator implementation didn’t use long double then it might work on device? Or is there some other reason why the <random> header isn’t yet ready for stdpar?
On a separate note, it would be nice if nvc++ provided clearer error messages when an unsupported standard library type is being used in device code. It’s not clear to me that the Long double in GPU code is unsupported message is because of an included standard library header, and it masks the real issue, which is that <random> is not yet supported on device. In this situation I think it would help if nvc++ emitted an error message like <header> is not supported on device instead.
Lastly, is there any update on when <random> will be available on device? I’m still very interested in having this available with stdpar and would be glad to help test it out if possible.
Sorry, I don’t know but would suspect there’s more to it. My experience with other RNGs, given they need to maintain state, they can be tricky to implement in a parallel context.
Lastly, is there any update on when <random> will be available on device?
I asked one of our engineers about this. Our long term goal is to provide our own complete device capable STL called libnv++. Though it’s an ambitious project so taking much longer to implement than hoped. It’s still a goal, but likely to change from what Bryce originally proposed in his GTC talk. Though, priority-wise, std::random would low on the list.
Though the implementation is agnostic to the parallization method so might work here as well. Granted, I haven’t tried so can’t say for sure.
On a separate note, it would be nice if nvc++ provided clearer error messages when an unsupported standard library type is being used in device code.
I’ll ask, but it might not be easy to detect given these at templates so by the time the compiler sees the code, it’s difficult to know that it’s coming from “random”.
I’d use “-P” so all the header file info is included in the post-processed file, and then find the new line number
That’s a good idea, thanks!
For people who don’t know the -P trick, I still think it would be helpful if nvc++ printed out the full source code line in question, or at least the name of the header file being included in addition to the line number. Would you be able to raise this request to the engineering team for me?