[BUG?] HardwareContext and default program options

[philippremy]

During my work to enable macOS builds again I noticed a (presumably) bug in the use of boost::program_options and the HardwareContext helper class:
When setting the default values for --maxMemoryAvailable and --maxCoresAvailable in CmdLine::execute(), they are set to _hContext.getUserMaxMemoryAvailable() and _hContext.getUserMaxCoresAvailable() respectively. The default constructor of HardwareContext sets these to std::numeric_limits<size_t>::max() and std::numeric_limits<unsigned int>::max() and this is what is returned by the functions. In turn, the executables all print out the following:

Hardware parameters:
  --maxMemoryAvailable arg (=18446744073709551615) User specified available RAM
  --maxCoresAvailable arg (=4294967295) User specified available number of cores

Does that make sense? Reasonable defaults would be to use the system hardware capabilities, no? HardwareContext even has the appropriate functions for this: getMaxMemory() and getMaxThreads()... if I use these, I get sensible default values¹:

Hardware parameters:
  --maxMemoryAvailable arg (=3312189440) User specified available RAM
  --maxCoresAvailable arg (=12) User specified available number of cores

Feel free to just close this if the current implementation is intended that way. Otherwise, I am happy to provide a PR for that :).

Footnotes

1. Ignore the memory. On macOS, we calculate the available memory very conservatively, especially considering that macOS likes to keep a lot of memory in cache (which is therefore 'used', but not really actually...). This is something I would change in my macOS PR anyway. ↩

[natowi]

I guess this is meant meant to be a placeholder/fallback value(?) to include all values if none are "user specified":
0xFFFFFFFF = 4294967295
0xFFFFFFFFFFFFFFFF = 18446744073709551615

Not sure though if this is supposed to return the values in your case or not.

[philippremy]

I guess this is meant meant to be a placeholder/fallback value(?) to include all values if none are "user specified":
0xFFFFFFFF = 4294967295
0xFFFFFFFFFFFFFFFF = 18446744073709551615

Not sure though if this is supposed to return the values in your case or not.

I totally agree, yes. And the values you are providing are correct (for any system where size_t is a 64 bit value and unsigned int is a 32 bit value; which is the case on my machine).

And whilst technically possible to have these values, I don't think it makes sense to expose them to the end-user. At least I wouldn't care what the max values for the data types are.

If I had implemented that bit, I would limit it to the maximum hardware available (i.e, number of logical cores and maximum physical memory available to the OS). This could still reach to the maximum values obviously, if some HPC system actually reaches them.

But as I said, there might very well be a reason for these defaults that I am just completely missing here 😅.