[mlpack] Introduction of ExecutionPolicy

Ankit Aggarwal ankit.ankit.aggarwal at gmail.com
Tue May 16 13:57:05 EDT 2017


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,

I don't think just doing "omp_set_num_threads" will leads to optimal
execution. I don't think openMP is NUMA aware (I never dig that much deeper
in openMP). I think it maybe better to use simple std::thread along with
hwloc for NUMA awareness or pthread(they provide more control support).

Ankit Aggarwal

On Tue, May 16, 2017 at 11:03 PM, Ankit Aggarwal <
ankit.ankit.aggarwal at gmail.com> wrote:

> """Thanks for the tip, Ankit.
>
> I measured, but couldn't find a large difference on my machine. My
> benchmark.
> <https://gist.github.com/shikharbhardwaj/6f5a48075ae964c294b775a6c153a6bd>
>
> Anyways, this is just a rough indicator of the execution time, not a
> benchmark for measuring the performance."""
>
> Attached is the code showing the difference between the execution, also
> note the time difference is in microseconds.
>
> @Ryan I have emailed you an idea on how to implement the Fast k-centre
> algorithm.Please do have a look on that so that I can approach forward on
> the implementation phase.
>
> Ankit Aggarwal
>
>
>
> On Tue, May 16, 2017 at 10:52 PM, Ryan Curtin <ryan at ratml.org> wrote:
>
>> 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_c
>> lock::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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://knife.lugatgt.org/pipermail/mlpack/attachments/20170516/aa8d94bf/attachment-0001.html>


More information about the mlpack mailing list