[mlpack] Introduction of ExecutionPolicy

Ankit Aggarwal ankit.ankit.aggarwal at gmail.com
Tue May 16 12:00:52 EDT 2017


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.

Ankit Aggarwal

On Tue, May 16, 2017 at 8:52 PM, Shikhar Bhardwaj <
shikharbhardwaj68 at gmail.com> wrote:

> Hello everyone,
>
> Yannis and I were discussing about the introduction of an ExecutionPolicy policy parameter in algorithms implemented by mlpack to provide parallel overloads of the algorithms as template specializations.
>
> This approach is a bit similar to C++'s planned support for "Extensions of Parallelism" <http://en.cppreference.com/w/cpp/experimental/parallelism>, describing 3 types of execution policies and overloads of various std algorithms with these execution policies.
>
> In addition to describing the type of execution(parallel/sequential etc), this parameter can also be used to describe other characteristics of the execution, the number of threads used during the execution being an example.
>
> A rough demo of how the interface would look from the user's perspective is here. <https://gist.github.com/shikharbhardwaj/ff7e35ae7085881588f3ca254ce887ac>
>
> We wanted to have further discussion about this design. A few existing issues include the current interface, which is quite crude. For example, we need to hardcode the value of the number of threads in the parallel execution policy, instead of taking it directly from somewhere like std::thread::hardware_concurrency.
>
> Would this design be a good one?
>
> Any thoughts?
>
> Thanks
>
> --
> Shikhar Bhardwaj
>
> _______________________________________________
> mlpack mailing list
> mlpack at lists.mlpack.org
> http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://knife.lugatgt.org/pipermail/mlpack/attachments/20170516/dac2e9f1/attachment.html>


More information about the mlpack mailing list