"""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 <[email protected]> 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_
> 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
> [email protected] | the unroadworthy!" - The Nightrider
>
#include <iostream>
#include <chrono>
#include <sys/time.h>
using namespace std;
int main(){
struct timeval t1 , t2;
struct timeval test_time;
gettimeofday(&t1 , 0);
//
//just a dummy creation of gettimeofday
gettimeofday(&test_time ,0);
gettimeofday(&t2 , 0);
std::cout << "Gettimeofday time=" << (t2.tv_sec-t1.tv_sec)*1000000 + t2.tv_usec-t1.tv_usec << std::endl;
gettimeofday(&t1 , 0);
//just a dummy creation of chrono
auto t0 = std::chrono::high_resolution_clock::now();
gettimeofday(&t2 , 0);
std::cout << "Chrono time=" << (t2.tv_sec-t1.tv_sec)*1000000 + t2.tv_usec-t1.tv_usec << std::endl;
return 0;
}
_______________________________________________
mlpack mailing list
[email protected]
http://knife.lugatgt.org/cgi-bin/mailman/listinfo/mlpack
