Closed GoogleCodeExporter closed 9 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
Hola de nuevo! Estuve de viaje, por eso no he respondido antes.
Adiviné que hablabas español porque además de informático soy mentalista ;D
Veo que te sigue yendo muy despacio el test_random ¿Estás compilando en
"debug mode"? A lo mejor es eso :-S Esto es lo que me sale a mi:
[...]
- 9557 blobs and 119213 pixels: 36 miliseconds elapsed.
- 9411 blobs and 119597 pixels: 35 miliseconds elapsed.
- 9441 blobs and 119608 pixels: 35 miliseconds elapsed.
- 9540 blobs and 119652 pixels: 35 miliseconds elapsed.
- 9472 blobs and 119326 pixels: 36 miliseconds elapsed.
- 9535 blobs and 119281 pixels: 36 miliseconds elapsed.
- 9515 blobs and 119498 pixels: 35 miliseconds elapsed.
- 9368 blobs and 119214 pixels: 35 miliseconds elapsed.
- 9549 blobs and 119231 pixels: 36 miliseconds elapsed.
- 9489 blobs and 119149 pixels: 35 miliseconds elapsed.
- 9556 blobs and 119362 pixels: 35 miliseconds elapsed.
- 9586 blobs and 119903 pixels: 35 miliseconds elapsed.
- 9311 blobs and 119940 pixels: 35 miliseconds elapsed.
- 9456 blobs and 119338 pixels: 36 miliseconds elapsed.
- 9370 blobs and 119644 pixels: 36 miliseconds elapsed.
- 9452 blobs and 119756 pixels: 36 miliseconds elapsed.
- 9468 blobs and 119692 pixels: 35 miliseconds elapsed.
- 9657 blobs and 119720 pixels: 47 miliseconds elapsed.
- 9446 blobs and 119642 pixels: 36 miliseconds elapsed.
- 9342 blobs and 119417 pixels: 36 miliseconds elapsed.
100 iterations.
Average cvLabel time: 35.99 miliseconds.
Es muy raro que te vaya tan lento. Quizás sea el ordenador, yo uso un
portátil con un Intel Core Duo a 1.73GHz.
Un saludo!
Original comment by grendel....@gmail.com
on 29 Nov 2010 at 12:27
Creo que realmente eres mentalista porque si estaba compilando en debug mode ;).
Sin embargo compilando en release mode opencv y cvblob cambia muy poco el
tiempo de ejecución. No creo que sea mi ordenador, uso un pc de escritorio con
un Intel i7 a 2.67Ghz ...
Estas utilizando TBB ?
Y de nuevo felicidades por tu biblioteca esta bastante completa !
Original comment by recastro...@gmail.com
on 1 Dec 2010 at 10:11
Listo, cambié de compilador ( a mingw ) y ahora el tiempo promedio es de 22 ms
:D.
Creo que hay un problema con las optimizaciones de opencv y el compilador de
visual studio.
Original comment by recastro...@gmail.com
on 1 Dec 2010 at 12:08
Hola de nuevo,
Veo que hay problemas con Visual Studio :-S Me alegro de que funcione mejor con
MinGW! He añadido al repositorio la solución para la portabilidad en el
test_random.cpp y dentro de poco sacaré un nuevo paquete, así que voy a
cerrar este "issue".
Muchas gracias por la ayuda!
Original comment by grendel....@gmail.com
on 9 Dec 2010 at 11:24
I couldn't test your changes before, there's still a small bug : the #include
should be either <ctime> or <time.h>
Otherwise it works perfectly !
BTW have you tried compiling your lib with the latest 2.2 opencv version ?
Original comment by recastro...@gmail.com
on 17 Dec 2010 at 10:00
Fixed! Thanks again :D
I don't remember if I have compiled cvBlob using 2.2, 2.1 or both. I do know it
works with 2.1 for sure.
Original comment by grendel....@gmail.com
on 20 Dec 2010 at 9:13
Original issue reported on code.google.com by
recastro...@gmail.com
on 21 Nov 2010 at 7:14Attachments: