[mlpack] Introduction of ExecutionPolicy

Ryan Curtin ryan at ratml.org
Tue May 16 13:22:10 EDT 2017


On Tue, May 16, 2017 at 09:30:52PM +0530, Ankit Aggarwal wrote:
> Hi Shikhar
> 
> Just a tip
> 
> Please avoid using *"auto t0 = std::chrono::high_resolution_clock::now();*"
> and rather use* gettimeofday* for any kind of benchmarking as if you
> measure the performance of these two function you will find out that
> high_resolution_clock to be atleast 2-3x slower than gettimeofday.I know
> you are taking the difference but it will help if you require some kind of
> book-keeping of time events to avoid latency.

There's also Timer::Start() and Timer::Stop() which might be a little
more convenient, if you want to drag the rest of mlpack in too. :)
Personally I like to use those when I am benchmarking for simplicity.

It seems to me like the idea of the policy is to determine how many
cores to use, but I think maybe OpenMP already has some support for
this.  For instance, if I write an OpenMP-ized program called 'program',
I can specify the number of cores it should use as an environment
variable:

$ OMP_NUM_THREADS=2 ./program

By default the number of threads used will be the maximum on the
machine, but this environment variable gives the user some nice
standardized control over the way the programs are executed.  I think
most users who see software that's parallelized with OpenMP interpret
this as the standard way to control its behavior.

You can also use omp_set_num_threads(...):

// The number of cores we want to use.
#define N 4

int main()
{
  omp_set_num_threads(N);

  // the rest of the program
  // ...
}

So I think maybe some of the support you need is already there.  Let me
know what you think.

Thanks,

Ryan

-- 
Ryan Curtin    | "The mighty hand of vengeance, sent down to strike
ryan at ratml.org | the unroadworthy!"  - The Nightrider


More information about the mlpack mailing list