Some OMP implemenations have a bug where if omp_get_max_threads() is called (which is what this function does), it sets something called thread affinity.
The upshot of that is that multiprocessing (i.e. not even just omp threading) is confined to a single hardware thread. Yeah, it's idiotic, but that seems to be the case. The only solution found by @erykoff, who looked into it pretty hard, is to set the env variable OMP_PROC_BIND to "false". This seems to stop the bad behavior.
So this PR adds that to the two functions that could potentially call omp_get_max_threads in the C++ layer.
Some OMP implemenations have a bug where if omp_get_max_threads() is called (which is what this function does), it sets something called thread affinity.
The upshot of that is that multiprocessing (i.e. not even just omp threading) is confined to a single hardware thread. Yeah, it's idiotic, but that seems to be the case. The only solution found by @erykoff, who looked into it pretty hard, is to set the env variable OMP_PROC_BIND to "false". This seems to stop the bad behavior.
So this PR adds that to the two functions that could potentially call omp_get_max_threads in the C++ layer.