Simple progress output for parallelFor

[andrewmarx]

Putting this here in case anyone else finds it helpful (and for future me).

std::atomic<int> progress{0};

std::vector<int> x(10000);
int sz = x.size();

Rcpp::Rcout << "Calculating..."

parallelFor(0, sz, [&x, &sz] (unsigned int i) {
  x[i] = i;

  progress++;
  if(progress % 100 == 0){
    RcppThread::Rcout << "\rCalculating... " <<  progress << "/" << sz << "               ";
    RcppThread::checkUserInterrupt();
  }
});

Rcpp::Rcout << "Calculating... Complete                                                             \n";

Key things:

• Use an atomic variable and atomic incrementation to make keeping track of the progress thread safe
• I use a carriage return \r to overwrite/update the output text rather than have a barrage of scrolling text
• Use an if statement with modulus to limit how often the text is updated. Important because the console output can be a significant source of overhead if the loop iterations are completing fast enough. If iterations of the loop are really slow, then it might not be worth worrying about.
• Same with checking for user interrupts, but I'm not sure if the overhead for it is as extreme as the console output
• Between the time the progress variable is incremented and it is outputted, other threads can change it, so you might not see it printing out increments that exactly match the modulus
• Disclaimer: most of my C++ experience does not entail use of the standard library, threading, or lambda functions, so if there are issues, hopefully someone more experienced with these topics will point them out

[tnagler]

Hm, considering adding something like this as a feature to the library. Should be a fairly common use case. Your example could look something like this:

std::vector<int> x(10000);
RcppThread::progressCounter progress(x.size(), 1);  // '1' means: print update in increments of 1%
parallelFor(0, x.size(), [&x] (unsigned int i) {
  x[i] = i;
  progress++;
});
progress.end();

Could also have related classes like progressTimer() or progressBar().

P.S: Overhead for interruption check should be negligible compared to console printing.

[andrewmarx]

I would definitely use it. The one thing I would consider is having it so that users can specify a time interval in seconds for the update, rather than percent. I think it's more intuitive and doesn't require users to have to try and dynamically adjust the percent input when the duration their code runs varies depending on the inputs. This is probably what I'm going to end up doing myself using std::chrono, which is what I assume you would use with progressTimer() anyway

[andrewmarx]

Here's my crude attempt at a progressCounter class that updates every x seconds (really slow iterations may not be able to call it that often).

class progressCounter {
public:
  progressCounter(size_t sz, double f) :
    lastTime(std::chrono::steady_clock::now()),
    startTime(std::chrono::steady_clock::now()),
    size(sz),
    freq(f) {}

  void operator++(int) {
    progress++;

    auto currentTime = std::chrono::steady_clock::now();
    double deltaTime = std::chrono::duration<double>(currentTime - lastTime).count();

    std::lock_guard<std::mutex> lock(mutex); // A lock is needed for updating lastTime. Maybe move into the if() statement.
    if(deltaTime > 5.0) {
      lastTime = currentTime;

      double t = ((double)(std::chrono::duration<double>(currentTime - startTime).count() / progress) * (double)(size - progress));

      std::string units = " seconds";

      if (t > 86400) {
        t = t / 86400;
        units = " days";
      } else if (t > 3600) {
        t = t / 3600;
        units = " hours";
      } else if (t > 60) {
        t = t / 60;
        units = " minutes";
      }

      RcppThread::Rcout << "\r" << progress << "/" << size << " : " << t << units << " remaining                              ";
    }
  }

private:
  std::mutex mutex;
  std::atomic<size_t> progress{0};
  std::size_t size;
  double freq;

  std::chrono::time_point<std::chrono::steady_clock> lastTime;
  std::chrono::time_point<std::chrono::steady_clock> startTime;
};

[tnagler]

I started working on this last week and then got distracted. This was a welcome reminder to continue ;)

I opened a draft PR

• classes for progress tracking #49

that is quite similar to what you have. Just a few things where I was more careful:

• It should be a bit more efficient because there are no locks.
• Made sure that progress messages are never mingled (that can happen when doing Rcout << .. << ... << with multiple <<).
• Made sure that final line always reads .... (done).

Example usage:

RcppThread::ProgressCounter cnt(20, 1);
RcppThread::parallelFor(0, 20, [&] (int i) {
    std::this_thread::sleep_for(std::chrono::milliseconds(500));
    cnt++;
});

...
Computing: 25% (~1s remaining)
...
Computing: 100% (done)

RcppThread::ProgressBar bar(20, 1);  // 20 iterations, update every 1 sec
RcppThread::parallelFor(0, 20, [&] (int i) {
    std::this_thread::sleep_for(std::chrono::milliseconds(500));
    ++bar;
});

...
Computing: [==========================              ] 65% (~1s remaining)       
...
Computing: [========================================] 100% (done) 

Remaining time is currently printed in the format (1d12h33m2s), but I consider using your variant of just showing the leading unit.

Any comments?

[andrewmarx]

I like yours more stylistically. The main thing is whether it's worth trying to display out to seconds when it's still days away from finishing. Maybe something more middle ground where only the two largest relevant units are shown, e.g.: 1d12h, 3hr40m, 19m27s, 12s.

And yes, my C++ definitely leaves a bit to be desired. I stopped really using it 10 yrs ago before C++11, and only picked it up again for my package, so there's a lot of new standard features and best practices I'm totally oblivious to.

[tnagler]

Great idea! I'll use the two leading units.

[tnagler]

done

• classes for progress tracking #49

[andrewmarx]

Hi again! Any plans to push this to CRAN? Just looking forward to the day when I can rip out my ad hoc solution and use this instead.

[tnagler]

Yeah some time this month!