Include CUB info in show_config
See original GitHub issueIt would be useful to include info about the CUB build in cupy.show_config()
. In particular was it enabled and what version/commit were used if so.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Standalone Sitecore ShowConfig - XCentium
We have all used the show config to take a look at the current Sitecore configuration, and validate that things are setup as...
Read more >Installation Manual - NVIDIA Bright Cluster Manager Support
(including, but not limited to, loss of data, incorrect processing of data, ... Show config: allows any already loaded configuration file to be...
Read more >showconfig - Moab
The showconfig command shows the current scheduler version and the settings of all 'in memory' parameters. These parameters are set via internal defaults, ......
Read more >StorCLI command line tool (For Windows) - Lenovo Support US
StorCLI command line tool (For Windows)
Read more >Océ|User manual
data printers e.g. to enable traces or to drive non Océ printers. ... data/prt), which contain printer specific files, e.g. resources for ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@jakirkham @emcastillo Catching up with this issue. Apparently, NVIDIA has added a version string to CUB starting v1.9.9 (not released yet), see this commit: https://github.com/thrust/cub/commit/629f01ec7b4f660d293899ab84680fb7819ece42. (Note CUB is taken over from NVLabs to Thrust.) So, if the bundled version is v1.9.9+, getting a version string from the source code wouldn’t be a problem. We won’t need to parse the git tag records.
No worries. Happy to poke around this as well. Just figured it might be handy when debugging issues 🙂