-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic loading #136
Comments
I'm not sure if the argument that was made for using this more complex loading procedure in the case of NVML, at the expense of reduced compile-time error checking and higher maintenance costs, also applies in the case of hwloc. In my mind, dynamic loading makes sense when three conditions are met:
Outside of professional systems with high performance requirements, locality optimizations certainly meet the first criterion. But is hwloc installed often enough on non-professional systems for the second criterion to be met? Especially knowing that hwloc is small and easy to build, which makes it a good candidate for vendoring inside of consumer apps? Contrast this with NVML, and you will see that the situation is quite different. Every system with an NVidia GPU driver comes with NVML, so you have a good chance of landing on it by chance. Every system without an NVidia GPU cannot have an NVML install, so the dependency must be optional. And NVML a pain to redistribute, so vendoring is not an option. Hence dynamic loading becomes the obvious choice. Do you agree with this assessment, or is there some important consideration that I am missing? |
Have you considered dynamically loading the hwloc shared library?
Something similar to this:
https:/Cldfire/nvml-wrapper/tree/main/nvml-wrapper-sys#type-of-bindings
https:/Cldfire/nvml-wrapper/blob/main/nvml-wrapper/src/lib.rs#L232-L246
Not sure if this makes sense, but it would allow you to error on init if hwloc was not installed.
The text was updated successfully, but these errors were encountered: