HadrienG2
commented
1 month ago 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:
- The functionality is not essential to the target application.
- You have a good chance of landing on the optional dependency by chance.
- The dependency cannot be easily bundled with the application (it's big, has an annoying redistribution license, etc).
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://github.com/Cldfire/nvml-wrapper/tree/main/nvml-wrapper-sys#type-of-bindings https://github.com/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.