Closed GoogleCodeExporter closed 8 years ago
I didn't realize that that was not portable :-S
In the other hand, I have an issue with `clock()`. In the test it always
returns:
{{{
40 miliseconds elapsed.
30 miliseconds elapsed.
40 miliseconds elapsed.
40 miliseconds elapsed.
40 miliseconds elapsed.
30 miliseconds elapsed.
...
}}}
But with my previous implementation it returns:
{{{
37 miliseconds elapsed.
43 miliseconds elapsed.
36 miliseconds elapsed.
40 miliseconds elapsed.
38 miliseconds elapsed.
36 miliseconds elapsed.
39 miliseconds elapsed.
36 miliseconds elapsed.
...
}}}
I don't know if that is a problem with precision of `clock()` or my
`gettimeofday()` is giving me some trash. Can you tell me what kind of values
you watch with your implementation?
In any case I could use `#ifdef WIN32` if necessary.
Thank you very much for your help!!
Original comment by grendel....@gmail.com
on 23 Nov 2010 at 10:06
It seems you're loosing precision. Try doing the multiplication first:
double elapsedTime = double (t2 - t1) * 1000.0 / CLOCKS_PER_SEC;
By the way, my elapsed times are huge! I'm getting the following values: 393,
599, 867, 1094 and up to 1605, with an average of 1256.29 ms and 24 iterations.
I'll test the code in a linux virtual machine later in the day and I'll post
here my results.
Original comment by recastro...@gmail.com
on 23 Nov 2010 at 10:39
Same results ¿? :-S
Anyway, searching on Google I have reached to this:
{{{
#ifndef _WIN32
#include <sys/time.h>
#else
#include <windows.h>
int gettimeofday (struct timeval *tv, void* tz)
{
union {
long long ns100; /*time since 1 Jan 1601 in 100ns units */
FILETIME ft;
} now;
GetSystemTimeAsFileTime (&now.ft);
tv->tv_usec = (long) ((now.ns100 / 10LL) % 1000000LL);
tv->tv_sec = (long) ((now.ns100 - 116444736000000000LL) / 10000000LL);
return (0);
}
#endif
}}}
Can you test it in my version of `test_random.cpp` on Windows?
Thank you very much!
Original comment by grendel....@gmail.com
on 23 Nov 2010 at 11:19
It seems that `clock()` returns how much CPU time the process has used, not how
much wall-clock time has passed. And perhaps Linux gives 10 ms to each process,
I don't know... In that case, `clock()` will have the "real" CPU time that
`cvLabel` is using...
Also, the elapsed times you are getting are very high. What `size` and
`numPixels` are you using?
PS: Are you spanish? Because I am :D
Original comment by grendel....@gmail.com
on 23 Nov 2010 at 11:42
I found this page that compares clock() and gettimeofday() and even proposes
something else, although I think their solution is Intel only :
http://software.intel.com/en-us/articles/best-timing-function-for-measuring-ipp-
api-timing/
Anyway, I'll test your version later in the day and I'll tell you if it works.
I'm not Spanish, but you weren't that far. I'm Mexican :D.
What made you think I speak spanish ? :P
Original comment by recastro...@gmail.com
on 23 Nov 2010 at 12:53
I've just tested your version in windows and it works!! (Still, I'm not very
fund of macros). There's just a small bug : you forgot to add <ctime>.
I keep having the same huge elapsedTimes. I didn't change the default values :
size = 500 and numPixels = 100000 and I'm pretty sure my computer is not that
slow ...
Maybe my random method is too random ?? :P
Here are the results of my test :
Nb blobs : 9482 and 119230 pixels :: 387 miliseconds elapsed.
Nb blobs : 9583 and 119338 pixels :: 598 miliseconds elapsed.
Nb blobs : 9440 and 119402 pixels :: 1035 miliseconds elapsed.
Nb blobs : 9558 and 119129 pixels :: 1226 miliseconds elapsed.
Nb blobs : 9600 and 119559 pixels :: 1319 miliseconds elapsed.
Nb blobs : 9384 and 119468 pixels :: 999 miliseconds elapsed.
Nb blobs : 9478 and 119504 pixels :: 1213 miliseconds elapsed.
Nb blobs : 9614 and 119305 pixels :: 1278 miliseconds elapsed.
Nb blobs : 9386 and 119534 pixels :: 1029 miliseconds elapsed.
Nb blobs : 9738 and 119188 pixels :: 1458 miliseconds elapsed.
Nb blobs : 9519 and 119702 pixels :: 1250 miliseconds elapsed.
How many blobs are you getting ?
Original comment by recastro...@gmail.com
on 23 Nov 2010 at 9:05
Original issue reported on code.google.com by
recastro...@gmail.com
on 21 Nov 2010 at 7:14Attachments: