Fixed bundled oneTBB builds with recent libc++, which no longer includes
<algorithm> transitively. tbb/concurrent_queue.h uses std::equal but
did not include it, giving "no member named 'equal' in namespace 'std'" when
compiling concurrent_bounded_queue.cpp, as seen on CRAN's clang-trunk
checks. (#280)
Fixed bundled oneTBB builds and downstream compilation with Clang and libc++ when targeting macOS 10.12 or earlier, where C++17 aligned allocation is not available. (#219)
Fixed a failure to install with toolchains that accept -std=c++20 but
provide a pre-C++20 standard library, with errors of the form "no member
named 'random_access_iterator' in namespace 'std'" from
tbb/parallel_for_each.h. The bundled oneTBB selected its concepts-based
iterator dispatch on a macro testing only the language standard, rather than
the __TBB_CPP20_CONCEPTS_PRESENT used elsewhere in that same header. This
affected RcppParallel's own compilation, as well as any package including
the header; CRAN's macOS x86_64 machines, which pair Apple clang 14 with the
macOS 11.3 SDK, are one such toolchain. (#268)
On Windows, RcppParallel now builds the bundled oneTBB as a shared library
and links against it, shipping tbb.dll and tbbmalloc.dll alongside the
package -- the same arrangement already used on every other platform.
Previously it linked the static TBB provided by Rtools directly into
RcppParallel.dll, which meant the TBB version (and ABI) depended on the
user's toolchain, and left downstream packages with no TBB library to link
against. Rtools42 in particular provides Intel TBB 2017, whose headers
downstream packages cannot build against: StanHeaders uses
tbb::this_task_arena::isolate, which that release still gates behind
TBB_PREVIEW_TASK_ISOLATION and does not export from its library, so rstan
could no longer be built on R 4.2 for Windows. Building TBB ourselves gives
every platform the same oneTBB and makes the ABI a property of RcppParallel
rather than of the toolchain. TBB_LIB / TBB_INC are still honoured for
anyone supplying their own build. (#269, #274)
Building RcppParallel now requires cmake (>= 3.5) on all platforms, as
SystemRequirements has always declared. Previously a missing or unusable
cmake was fatal everywhere except Windows, where it instead produced a
package with no TBB backend at all -- a silently degraded install that was
easy to end up with and hard to notice. TBB is now always enabled. Rtools has
shipped cmake since Rtools42, so this should not affect Windows users in
practice. Note that the tinythread backend remains selectable at runtime via
RCPP_PARALLEL_BACKEND=tinythread; it is only no longer a build outcome.
(#275)
As a consequence, RcppParallel::RcppParallelLibs() now emits -ltbb and
-ltbbmalloc on Windows, in addition to -lRcppParallel (which remains
necessary there for the entry points RcppParallel compiles itself, such as
isProcessForkedChild). Packages that previously resolved TBB symbols out of
RcppParallel.dll, or the tbbmalloc API via -lRcppParallel alone, should
rebuild against these flags.
The tbb.dll compatibility stub is gone. It existed to publish the
pre-oneTBB task_scheduler_observer entry point on top of a statically
linked runtime, but because it linked the TBB archives itself it amounted to
a second, independent copy of the oneTBB scheduler living in the same
process. That entry point is now exported by the real tbb.dll, as it
already was by the shared libraries on other platforms, so binaries built
against RcppParallel 5.1.11 and earlier continue to resolve it.
On macOS, RcppParallel::LdFlags() now also emits an -rpath entry for the
directory containing the TBB libraries. The libraries record an
@rpath-relative install name, so packages linking against them previously
produced binaries with no runtime search path for TBB; those binaries could
only be loaded when RcppParallel (and hence TBB) already happened to be
loaded into the process, and failed with "Library not loaded:
@rpath/libtbb.dylib" otherwise. (#209, #271)
Fixed RcppParallel::tbbLibraryPath() returning NULL on Windows, and
tbbRoot() reporting a directory that need not exist on the machine running
the package -- for a pre-built binary, the Rtools tree of the machine that
built it. Both now describe the installation actually in use. (#270, #273)
Fixed an issue where building the bundled oneTBB could fail when CXX
(or CC) was configured with a leading compiler launcher such as ccache
(e.g. CXX = "ccache g++"). The launcher is now forwarded to cmake via
CMAKE_<LANG>_COMPILER_LAUNCHER instead of being mistaken for the compiler
itself. (#267)
Fixed an issue where package installation could fail if cmake was not
available on the PATH, even when it was discoverable at another known
location (e.g. /Applications/CMake.app/Contents/bin/cmake on macOS).
This caused installation failures on CRAN's macOS machines, where cmake
is not on the PATH by default.
Removed vestigial compiler / flag detection code from the configure
script. This code has been unused since the switch to a cmake-driven
build of the bundled oneTBB, and probed R CMD config variables that
are defunct in R (>= 4.6.0).
RcppParallel now provides isProcessForkedChild() (R) and
RcppParallel::isProcessForkedChild() (C++), which return TRUE when the
current process is a fork() of the process in which RcppParallel was
loaded.
Packages dispatching parallel work from within parallel::mclapply() (or
similar) should consult this and fall back to a serial path, as TBB does
not support use after fork. (#243, #244)
The TBB backend is now enabled by default on musl-based Linux distributions, such as Alpine Linux. Previously, TBB was only enabled by default with glibc-based toolchains on Linux. (#231, #263)
The mingw cpuid guard applied to TBB's _machine.h header during
installation is now logged, and a warning is emitted if the header does
not have the expected form and the guard cannot be applied. (#265)
On Linux, the bundled TBB libraries are once again installed with versioned
names (e.g. libtbb.so.2) plus an unversioned libtbb.so symlink, matching
the layout shipped by RcppParallel 5.1.11 and earlier. The oneTBB cmake build
produces only unversioned libraries on Linux, so binaries compiled against
those releases (which recorded a load-time dependency on libtbb.so.2) would
otherwise fail to load after an upgrade with "libtbb.so.2: cannot open shared
object file". (#260)
Fixed linking of downstream packages using the TBB scalable allocator
on Windows, e.g. via RcppArmadillo's ARMA_USE_TBB_ALLOC. RcppParallel
now links the whole Rtools tbbmalloc archive into RcppParallel.dll
and re-exports its API, so that scalable_malloc, scalable_free, and
friends can be resolved by packages linking with -lRcppParallel. (#262)
Fixed installation on Windows toolchains providing an older (non-oneTBB) copy of TBB, e.g. Rtools42: the tbb stub library is now built by re-exporting the static TBB library, rather than wrapping the oneTBB runtime (which is unavailable there). In addition, stale stub build artifacts from a different toolchain are no longer reused. (#258)
Fixed installation on Windows systems whose Rtools does not provide TBB (R < 4.2.0): configure no longer requires cmake there, and the tbb stub library is no longer built when the TBB backend is disabled. (#257)
RcppParallel now reports which TBB headers and libraries are installed
with the package, and from where, during package installation. In
addition, setting the VERBOSE environment variable to a value other
than 0 enables diagnostics describing how TBB libraries are resolved
and loaded when the package is loaded. (#256, #259)
On Windows, RcppParallel once again loads its compatibility stub library
(tbb.dll) when the package is loaded. Packages linking with -ltbb
(e.g. via StanHeaders) record a load-time dependency on tbb.dll, which
can only be resolved if RcppParallel has already loaded it; with
RcppParallel 6.0.0, such packages would fail to load with "LoadLibrary
failure: The specified module could not be found". (#249, #250)
The TBB headers installed with RcppParallel (whether from Rtools or from
the bundled copy of oneTBB) now guard against GCC's <cpuid.h> being
included before <intrin.h> on Windows (mingw). Previously, translation
units including <cpuid.h> before any TBB header would fail to compile,
as the __cpuid macro from <cpuid.h> conflicts with the __cpuid()
function declared by mingw's <intrin.h>. (#248, #253)
When building the bundled copy of oneTBB, RcppParallel no longer searches for hwloc, and so no longer tries to build the optional 'tbbbind' library. This fixes build failures on machines where a static hwloc library is discoverable via pkg-config, as on the CRAN macOS machines. (#247)
On macOS, the bundled copy of oneTBB is now built with
__TBB_RESUMABLE_TASKS_USE_THREADS, avoiding use of the deprecated
ucontext APIs (getcontext, swapcontext, makecontext). (#247)
RcppParallel no longer includes tbb headers as part of the RcppParallel/TBB.h header, and instead only exposes its TBB-specific APIs for parallel work.
RcppParallel now bundles oneTBB 2022.0.0. Note that the TBB ABI has changed; packages which depend on RcppParallel may need to be rebuilt.
On Windows, RcppParallel now uses the copy of TBB provided by Rtools. If TBB is not available, RcppParallel will use only the fallback 'tinythread' implementation. In practice, this implies that RcppParallel will now only provide a TBB backend with R (>= 4.2.0).
Fixed builds under wasm/webR. (#237; @andrjohns)
Fixed compilation with clang-19 on Windows aarch64. (#235, #236; @andrjohns)
Fixed TBB library lookup on Windows, and removed the obsolete
TBB_USE_GCC_BUILTINS flag for Windows ARM64. TBB is statically linked
on Windows, so the package no longer tries to load TBB libraries there
at load time. (#241; @andrjohns)
-rpath when building / linking on Windows.
This fixes build issues when building RcppParallel when using the LLVM
linker on Windows. (@kalibera)Patch for TBB to allow compilation with gcc-13.
Fixed a memory leak that could occur when using TinyThread on POSIX systems. (#185; @dipertix and and @kevinushey)
Patches to ensure compatibility with the R 4.2.0 UCRT toolchain on Windows, adapted from patches contributed by Tomas Kalibera.
Fixed an issue where setting TBB_ROOT (or TBB_INC / TBB_LIB) would
copy rather than symlink the associated libraries. (#161)
Fixed an issue that prevented compilation of RcppParallel with R (< 4.0.0) of R on Windows.
The RCPP_PARALLEL_USE_TBBMALLOC_PROXY environment variable can now be used
to control whether RcppParallel loads the tbbmalloc_proxy library on load.
See https://www.threadingbuildingblocks.org/docs/help/tbb_userguide/Automically_Replacing_malloc.html
for more information.
RcppParallel gains the tbbLibraryPath() function, to be used when attempting
to query the location of the TBB libraries that RcppParallel has been
configured to use. This may be useful for R packages which wish to explicitly
use, or link to, these libraries.Updated bundled version of TBB (Intel TBB 2019 Update 8).
RcppParallel can now be configured to use an external copy of TBB, via the
TBB_LIB and TBB_INC environment variables. These should be set to the
directories containing the TBB libraries and headers, respectively.
Added support for the latest versions of Intel oneAPI TBB / oneTBB.
Updated TBB functionality for the new interface.
Falling back to building TBB from local source code.
Backward TBB compatibility based on __TBB_tbb_stddef_H.
Resolved conflicts between system and local TBB headers.
Fixed URLs, used HTTPS, and minor cleanups.
Updated package DESCRIPTION and bumped version.
setThreadOptions(...) can again be called multiple times per session.
The requested number of threads will be used for invocations to parallelFor()
and parallelReduce() that don't explicitly request a specific number of threads.
The parallelFor() and parallelReduce() functions gain the numThreads
argument, allowing one to limit the number of threads used for a
particular computation.
setThreadOptions(...) can now only be called once per session, to avoid
segfaults when compiling RcppParallel / TBB with gcc 10.1. Subsequent
calls to setThreadOptions(...) are ignored.Fixed compilation issue on OpenSUSE Tumbleweed with -flto=auto
Fixed compilation when CPPFLAGS = -I/usr/local/include and a version of libtbb is installed there
RcppParallel backend can now be customized with RCPP_PARALLEL_BACKEND environment variable (supported values are 'tbb' and 'tinythread')
Fixed issue when compiling RcppParallel on macOS Catalina
Fixed issue when compiling RcppParallel with Rtools40
Suppress gcc-9 warnings related -Wclass-memaccess
Added TBB headers for serial TBB operations (#90, @mikejiang)
Fixed compilation on FreeBSD
Suppress gcc-8 warnings related to -Wclass-memaccess
Use PKG_CXXFLAGS rather than PKG_CPPFLAGS
Remove unused dependency on the BH package
Ensure user-specified R configuration passed to TBB
Work around warnings emitted by gcc 8
Respect user-defined compiler settings (e.g. from ~/.R/Makevars).
Remove TBB's attempts to suppress compiler diagnostics.
Allow setting the number of threads to use via RCPP_PARALLEL_NUM_THREADS environment variable.
Update to TBB 2018 Update 1.
Add native registration of compiled functions.
Add support for TBB on Solaris
Fix failure to compile on OS X Snow Leopard R toolchain
Add const and non-const operator[] for RMatrix class
Add tbbmalloc library
Correctly pass clang to TBB configure when R is using clang
Update to TBB 4.3 (fixes clang compilation error in platform.h)
Forward CXX to TBB Makefile