test_random.cpp is not cross-platform

Question

test_random.cpp is not cross-platform

GoogleCodeExporter opened this issue 9 years ago · 12 comments

GoogleCodeExporter commented 9 years ago

What steps will reproduce the problem?
1. Compile test_random.cpp under windows.

What is the expected output? What do you see instead?
The problems is the methods defined in #include <sys/time.h> are linux only.

What version of the product are you using? On what operating system?
Revision 273 from SVN. VS2010. Windows 7.

Please provide any additional information below.
The solution is to use a more cross-platfrom header <ctime> and replace de old 
method calls :

    ...
    clock_t t1 = clock();
    unsigned int result = cvLabel(randomBinImg, labelImg, blobs);
    clock_t t2 = clock();

    double elapsedTime = double (t2 - t1) / CLOCKS_PER_SEC * 1000.0;
    cout << elapsedTime << " miliseconds elapsed." << endl;

    iter++;
    averTime = (1. - 1/((double)iter))*averTime + (1/((double)iter))*elapsedTime;
    ...

I attach my test_random.cpp file.

Original issue reported on code.google.com by recastro...@gmail.com on 21 Nov 2010 at 7:14

Attachments:

test_random.cpp

Answer 1 · 2016-02-09T13:54:54.000Z

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

Changed state: Started
Added labels: OpSys-Windows

Answer 2 · 2016-02-09T13:54:54.000Z

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

Answer 3 · 2016-02-09T13:54:55.000Z

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

Answer 4 · 2016-02-09T13:54:55.000Z

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

Answer 5 · 2016-02-09T13:54:55.000Z

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

Answer 6 · 2016-02-09T13:54:55.000Z

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

Answer 7 · 2016-02-09T13:54:55.000Z

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

Answer 8 · 2016-02-09T13:54:55.000Z

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

Answer 9 · 2016-02-09T13:54:55.000Z

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

Answer 10 · 2016-02-09T13:54:55.000Z

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

Changed state: Fixed

Answer 11 · 2016-02-09T13:54:56.000Z

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

Answer 12 · 2016-02-09T13:54:56.000Z

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