Closed ekg closed 6 years ago
We really should get clang support, if only because every other library on OS X demands to build things using Clang (and some things people might want to depend on in parallel to libvg ship C++ builds done using Clang).
The build of hal2vg, for example, is broken because of https://github.com/ComparativeGenomicsToolkit/hal2vg/issues/3 which appears to be because the HDF5 compiler wrappers and the sonLib code both super want to use Clang. If you force them not to (and hack the HDF5 wrapper to not pass clang-only options), you get object files that can't link against the Clang-built C++ binaries that the HDF5 library from Macports gives you.
From my point of view, the main issue with Clang is multithreaded sorting. GCSA2 construction gets much slower without it. GCC has multithreaded quicksort in the libstdc++ parallel mode, while there is nothing comparable in the Clang standard library.
C++17 execution policies would be the standard alternative to the parallel mode, but nobody really supports them at the moment. Meanwhile, if we are willing to require C++14, we could use https://github.com/SaschaWitt/ips4o instead.
It looks like right now GCSA2 doesn't use libstdc++ parallel mode; there's no "_GLIBCXX_PARALLEL" in the repo according to Github search.
I'm only using it explicitly in a few places, such as https://github.com/jltsiren/gcsa2/blob/master/include/gcsa/utils.h#L273 Defining _GLIBCXX_PARALLEL
is generally a bad idea. Many STL algorithms are parallelized automatically, and the threshold for parallelization is quite low. If you have tens of CPU threads, the parallelization overhead can make things several times slower, if you call STL functions with small or medium inputs.
https://clang-omp.github.io/
We might consider fully supporting our build using it.