stan-dev
Headers (task_scheduler_init.h, tbb_stddef.h) removed from OneAPI TBB 2021.1
Summary:
task_scheduler_init.h is removed from OneAPI TBB 2021.1. The corresponding include should be removed from init_threadpool_tbb.hpp.
Description:
I am using a system TBB library (OneAPI TBB 2021.1). The RStan installation bug checks:
/Users/anirbanmukherjee/Library/R/4.0/library/StanHeaders/include/stan/math/prim/core/init_threadpool_tbb.hpp:12:10: fatal error:
'tbb/task_scheduler_init.h' file not found
#include <tbb/task_scheduler_init.h>
task_scheduler_init.h is unavailable as it has been removed from the latest TBB release. See: https://software.intel.com/content/www/us/en/develop/documentation/tbb-documentation/top/intel-threading-building-blocks-developer-reference/appendices/deprecated-features/outdated-and-redundant-api/taskschedulerinit-class.html. I have checked the folder and the header is not that there.
It should be safe to simply remove this include as the header was deprecated a while ago.
R Version:
> R.version
_
platform x86_64-apple-darwin20.3.0
arch x86_64
os darwin20.3.0
system x86_64, darwin20.3.0
status Patched
major 4
minor 0.4
year 2021
month 03
day 18
svn rev 80099
language R
version.string R version 4.0.4 Patched (2021-03-18 r80099)
nickname Lost Library Book
> sessionInfo()
R version 4.0.4 Patched (2021-03-18 r80099)
Platform: x86_64-apple-darwin20.3.0 (64-bit)
Running under: macOS Big Sur 10.16
Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.0.4 tools_4.0.4
The development version adds support for the new tbb interface. I did have to pass some flags but the following worked for me:
Sys.setenv(TBB_VERSION="2021.1.1")
Sys.setenv(TBB="/opt/intel/oneapi/tbb/2021.1.1")
Sys.setenv(TBB_INC="/opt/intel/oneapi/tbb/2021.1.1/include")
Sys.setenv(TBB_LIB="/opt/intel/oneapi/tbb/2021.1.1/lib")
Sys.setenv(TBB_INTERFACE_NEW ="true")
remotes::install_github("RcppCore/RcppParallel", force = TRUE)
remotes::install_github("hsbadr/rstan/StanHeaders@develop", force = TRUE)
remotes::install_github("hsbadr/rstan/rstan/rstan@develop", force = TRUE)
I was able to install rstan as described above but it bug checks with: fatal error: 'tbb/tbb_stddef.h' file not found#include <tbb/tbb_stddef.h>
see: https://github.com/opencv/opencv/issues/19358 for a similar problem and resolution.
Similar issue in Xcode(MacOS Mojave 10.14.6 ) 'tbb/tbb_stddef.h' file not found inside file stan/math/prim/core/init_threadpool_tbb.hpp
There is a 2.26.12 version as committed here
@hsbadr wanted to ask if this is ready for a release to CRAN? Actually, we have defaulted to oneTBB in debian and the support seems to be there at this version -- could you confirm is this would be usable?
This will get fixed in the upcoming release that we're preparing for submission to CRAB, hopefully soon (after fixing some reverse dependencies). We're currently testing v2.26 (potential release) as well as the experimental v2.30.
HI @hsbadr sorry for the ping again, but this is breaking a lot of packages in debian for a long time. We are not very far from making a release, and any quick release or even patch to settle the dust would be really appreciated.
Is there a reason not to use the version of tbb that comes with RcppParallel or cmdstan? Tbc I'm very very anti trying to support every version of our dependencies. It turns into a constant game of wack a mole that is tedious and imo not worth the time. We also only test with the version we come with so ymmv with alternative dependency versions
Tbc I'm very very anti trying to support every version of our dependencies. It turns into a constant game of wack a mole that is tedious and imo not worth the time.
I completely agree but oneTBB has been there for a while now. Even other distros (major players like Ubuntu, Fedora etc) have moved to OneTBB (newer libtbb as upstream re-branded), so IMHO it does make sense to support it, given that stanheaders has several reverse-depends.
Besides, as Hamada mentioned above some of the porting work is already done in 2.26 branch, so all I ask for is a release with the said work
@nileshpatra do you have a link for this?
I don't follow - link for what?
I see your point but:
- RcppParallel explicitly states that it works with both system TBB and the (older) TBB whose source comes with it. IMO it follows that a dependency of RcppParallel will need to work with either as at the time of installing RcppParallel, the user can specify either to use system TBB or install from the source that comes with it. Once installed everything then uses what was chosen at installation.
- This issue stems from Intels relicensing of TBB. The TBB whose source code is distributed with RcppParallel is out of date and unsupported. It cannot be updated due to licensing issues. The version is frozen. OneTBB is its successor. IMO it only makes sense for someone to setup RcppParallel with system TBB as developers would likely expect TBB to be up to date and bug fixed. The older TBB is untested with modern compilers, hardware, and OS. If you use it with circa 2022 hardware and software stack, it “should” work, but that’s totally untested. Given how fundamental this library is in the software stack, I would expect it to be increasingly buggy with changes in OS and compiler.
I honestly don’t have a horse in this race as I have changed my workflow. Above is my 2 pence FWIW and also the explanation for why I filed the original bug report.
On Sat, Aug 20, 2022 at 12:07:42PM -0700, anirban-mu wrote:
I see your point but:
- RcppParallel explicitly states [...]
Thanks Anirban for sharing your points. rcppparallel is doing well, and I am not concerned about it. I am talking about the rest R packages that depend on stanheaders. Doing a quick reverse-dep check, I find:
$ reverse-depends r-cran-stanheaders Reverse-Depends
- r-cran-openmx
- r-cran-prophet
- r-cran-rstan
- r-cran-rstanarm
And then each of those have other reverse deps, for instance:
$ reverse-depends r-cran-rstan
Reverse-Recommends
- r-cran-bayestestr
- r-cran-broom.mixed
- r-cran-rstantools
Reverse-Depends
- r-cran-brms
- r-cran-prophet [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
- r-cran-rstanarm [amd64 arm64 armel armhf i386 mips64el ppc64el s390x]
- r-cran-shinystan
And then each of them have more packages that depend on these.
So essentially there is an eventual reliance on stanheaders being compatible otherwise rstan and rstanarm wouldn't work.
Am Sat, Aug 20, 2022 at 12:23:20PM -0700 schrieb NILESH:
So essentially there is an eventual reliance on stanheaders being compatible otherwise rstan and rstanarm wouldn't work.
In short: We really need to get that fixed to prevent a lot of R packages becoming not included into the next Debian stable release. Kind regards, Andreas.
In short: We really need to get that fixed to prevent a lot of R packages becoming not included into the next Debian stable release.
Sorry if I wasn't clear earlier, I was asking if there is a link for the Debian project somewhere showing these packages are failing. I'm not really following why rstan and depending packages would not be included with the next version of Debian unless there was an active bug report showing failures. Though I also don't know much about the Debian packaging profess for stable so if you could clarify that for me I'd appreciate it
Sorry if I wasn't clear earlier, I was asking if there is a link for the Debian project somewhere showing these packages are failing. I'm not really following why rstan and depending packages would not be included with the next version of Debian unless there was an active bug report showing failures. Though I also don't know much about the Debian packaging profess for stable so if you could clarify that for me I'd appreciate it
Here are the current bug reports about different R packages which are all caused by the onetbb migration and which can be fixed TTBOMK by adapting stanheaders to onetbb
https://bugs.debian.org/1011222 https://bugs.debian.org/1012219 https://bugs.debian.org/1013415 https://bugs.debian.org/1011218 https://bugs.debian.org/1012143 https://bugs.debian.org/1012144
Hope this helps, Andreas.
This will get fixed in the upcoming release that we're preparing for submission to CRAB, hopefully soon (after fixing some reverse dependencies). We're currently testing v2.26 (potential release) as well as the experimental v2.30.
@hsbadr I've installed the development version of rstan v2.26.22 on my system and am still experiencing this issue when compiling my package. Any ideas?
