OpenMP vs alternatives

Over at the HEIR project, support for OpenMP has been a recurring obstacle for us. For exmaple, Google internally does not support OpenMP, nor does Apple clang, compiling with OpenMP in bazel breaks hermeticity, it complicates PyPI packaging, and contributors have different system setups that they can’t often get to work with OpenMP in ways I have not been able to help them debug.

I am curious to what extent you folks at OpenFHE have considered replacing OpenMP with something more standardized, like std::for_each? Since most of the places I see pragma omp in the codebase are straightforward parallel for, it seems like it wouldn’t be that difficult.

[edit] Using std::for_each with clang/gcc would also seem to require adding a tbb dependency for the parallel runtime, like GitHub - uxlfoundation/oneTBB: oneAPI Threading Building Blocks (oneTBB), but the benefit there is that it’s an explicit dependency managed by the build system, rather than implicit.

Hi @j2kun,

It is a great question. We have been discussing it internally for a while. In the past, we already added options to turn off OMP (using a CMake flag) so that STL threads could be used if desired for application-level parallelization. My current thought is to add STL threads parallelization as another option (instead of fully replacing it) not to break existing programs. We will get back to you on this.