Yeah, maybe less magic and more standard threads is the right answer, it would certainly be more portable across platforms. I was disappointed to find that stock MacOS clang is built w/o openmp support, for example.
P > On Jul 28, 2021, at 4:37 AM, Daniel Baston <dbas...@gmail.com> wrote: > > I've always been a bit uneasy with the "magic" aspect of sticking #pragma > statements in the code, relative to alternatives like TBB or the parallel > algorithms in the C++ standard. But if it works and can be controlled at > runtime, sure? > > Dan > > On Tue, Jul 27, 2021 at 4:18 PM Paul Ramsey <pram...@cleverelephant.ca> wrote: > Interested in knowing what people's general reaction to OpenMP work is. > > https://github.com/libgeos/geos/pull/468 > > Going from PoC to something committable will involve a reasonable amount of > CMake twiddling to detect support on multiple platforms and get the right > linking info and so on. It can be flipped off as necessary. The biggest > implementation thing missing is some kind of run-time API to signal to OpenMP > the maximum number of cores to commit, since we'll want to at least wave our > hands at trying to avoid capping out server resources. > > On the one hand it's kind of cool. On the other there's limited places to put > it to work, and it adds complexity for certain. > > P. > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel