Negative timing results

[GoogleCodeExporter]

Some of the timings are giving negative numbers. Here is a simple example using 
the CPU sort:

crb002$ ./go
Platform[Apple] Device[Radeon HD 4850]

--------------- Brute force sort
Performance for data-set size[100000] time (ms): 15.426 KPS[6482561]
Performance for data-set size[200000] time (ms): 31.833 KPS[6282788]
Performance for data-set size[300000] time (ms): 49.592 KPS[6049363]
Performance for data-set size[400000] time (ms): 67.493 KPS[5926541]
Performance for data-set size[500000] time (ms): 85.211 KPS[5867787]
Performance for data-set size[600000] time (ms): 103.576 KPS[5792848]
Performance for data-set size[700000] time (ms): 122.051 KPS[5735307]
Performance for data-set size[800000] time (ms): -857.725 KPS[-932699]
Performance for data-set size[900000] time (ms): 159.314 KPS[5649221]
Performance for data-set size[1000000] time (ms): 178.237 KPS[5610507]

Original issue reported on code.google.com by crb...@gmail.com on 9 Jul 2011 at 11:09

[GoogleCodeExporter]

As a rule, for timings don't convert them to floats until you need to. By 
storing the raw clock ticks this problem should go away. Make start and end to 
be timeval structs.  There should be two GetElapsedTime() functions. One that 
returns clockticks, and one that returns it in double precision for 
microseconds.

#if defined(__linux__) || defined(__APPLE__)
    double start;
    double end;

    double ClockTime()
    {
        struct timeval t;
        gettimeofday(&t, 0);

        return t.tv_sec + t.tv_usec / 1000.0;
    }
#endif

Original comment by crb...@gmail.com on 9 Jul 2011 at 11:28

[GoogleCodeExporter]

My quick and dirty hack. Not tested, and for __APPLE__ we should be using the 
mach timer.

Original comment by crb...@gmail.com on 9 Jul 2011 at 11:51

Attachments:

• StopWatch.h
• StopWatch.cpp

[GoogleCodeExporter]

The change for this is done now.

Original comment by crb...@gmail.com on 25 Jul 2011 at 2:48

• Changed state: Fixed