RC 1.0.5

[EmilHvitfeldt]

to close #250

[aitap]

Your CPU time problems are likely caused by text2vec using parallel::mcparallel in addition to data.table. This definitely needs to be reported to the text2vec maintainer because of their default of parallel::detectCores(), which CRAN doesn't like any more. As a workaround, you can set options(text2vec.mc.cores=...) for the duration of the example.

[EmilHvitfeldt]

Hello @aitap! Thanks for looking into this!

I tried that a while ago a7458a3

I don't think they are the issue as parallel::mcparallel is only enabled when using 20itoken_parallel which I don't do in this package https://github.com/search?q=repo:tidymodels/textrecipes%20itoken_parallel&type=code

Unless I need to do that in addition to the data.table stuff. let me try that

[aitap]

I'm sorry it didn't help. I see you're using library(text2vec) and only then options("text2vec.mc.cores" = 1). This is the most careful way (text2vec:::.onLoad resets the option!); if text2vec.mc.cores was the culprit, your fix would have worked. Another option I tried was to patch parallel::detectCores() to always return a large number and then run R CMD check on your package with the _R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD_=2 environment variable and the --timings flag set. I couldn't reproduce it either. I do get CPU time ~1.3 times elapsed time for the step_dummy_hash example, but (1) only because I have parallel OpenBLAS installed and (2) 1.3 times is too low to trigger the NOTE.

[aitap]

I've set a breakpoint on pthread_create in gdb and ran example(step_dummy_hash). The breakpoint fired multiple times; the unexpected hits were in rsparse's omp_thread_count() [1] where it eventually set options(rsparse_omp_threads) [2] to the number of logical processors on my virtual machine. I think that rsparse:::.onLoad gets to run (and decide to use the whole CPU) before you set OMP_THREAD_LIMIT because rlang::is_installed calls requireNamespace. Putting the Sys.setenv() call above the call to rlang::is_installed() should circumvent the problem. [1] https://github.com/rexyai/rsparse/blob/873db8474c09e6974404e65868a712af8d834fb0/src/utils.cpp#L80-L91 [2] https://github.com/rexyai/rsparse/blob/873db8474c09e6974404e65868a712af8d834fb0/R/zzz.R#L27

[EmilHvitfeldt]

@aitap Thank you so much for looking into this! Would you be able to teach me what you did to gain those insights? I'm fine if you don't, you already helped me so much!

[aitap]

My first idea was that if something takes too much CPU time, it ought to show up in the CPU profiler. Writing R Extensions mentions a few profiling techniques. I've heard good things about Intel's VTune profiler (on both GNU/Linux and Windows) and Very Sleepy on Windows. The section on profiling in Algorithmica is a bit terse but contains useful pointers. I'm using perf on GNU/Linux because it's easy to install and doesn't require any instrumentation of the executables besides compiling with -g (which R already does). In the end, the traces I got for system.time(replicate(100, example(step_dummy_hash))) didn't give any obvious pointers, but I did consistently see 1.3 times of CPU time consumed per unit of real time. The CRAN machine has a different processor; maybe threads are more expensive in their circumstances?

I'm using an accelerated BLAS that can start threads on its own, so I was ready to blame OpenBLAS for the threads, but even with the environment variable OPENBLAS_NUM_THREADS=1 set I could see more than 100% of one CPU core being used (as measured by system.time).

If threads do evidently consume extra CPU time, perhaps some information could be gained by seeing who creates them? The OpenMP specification is not 100% precise on this, but it makes sense for a program to start new threads when it encounters a #pragma omp parallel directive and stop them when they are done. I've read Butenhof, 1997 and decided to set a breakpoint on pthread_create, the function used to start threads on POSIX-compatible operating systems. The OpenMP runtime implementors could have used a system-specific call (e.g. clone(2) on Linux), but they did use pthread_create, so the breakpoints fired in appropriate places.

The omp_thread_count() function was surprising because it looks like an OpenMP API but is not. The author could have used omp_get_thread_limit instead of creating a parallel section just to run omp_get_num_threads or counting threads one by one. The involvement of rsparse was not 100% conclusive (maybe there's a third package that also creates threads that I haven't noticed yet?), but it was definitely worth trying to limit the number of threads used by this package.

[github-actions]

This pull request has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue.