What I meant by this was to make an empty implementation of random_r()
in a tiny dynamic lib. In this way you isolate if the problems come
from something glibc random_r() does, or if there is some terrible
problem with dynamic libs for that processor/compiler/compile environment.
Ok. Done. I have created a dynamic library called "libfakerand" which
code is this:
int fakerand(void) {
return 9999;
}
I have also created his corresponding header file libfakerand.h:
int fakerand(void);
And compiled it and installed it this way:
gcc -fPIC -c -W -Wall -pedantic -o libfakerand.o libfakerand.c
gcc -shared -fPIC -o libfakerand.so libfakerand.o
cp -f libfakerand.so /usr/local/lib/
ldconfig -v -l /usr/local/lib/libfakerand.so
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
Then I have created a reduced version of the test just to compare real
rand and fake rand functions this way:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include "libfakerand.h"
int main(void) {
int i, r, numero_ciclos, numero_ciclosM;
clock_t start, end;
numero_ciclos = 10000000; numero_ciclosM = numero_ciclos / 1E6;
start = clock();
for(i=0; i<numero_ciclos; i++) {
r = rand();
}
end = clock();
printf("%d M de rand() en %.3f s. (ejemplo.: %d)\n", numero_ciclosM,
(double)(end - start)/CLOCKS_PER_SEC, r);
start = clock();
for(i=0; i<numero_ciclos; i++) {
r = fakerand();
}
end = clock();
printf("%d M de fakerand() en %.3f s. (ejemplo.: %d)\n",
numero_ciclosM, (double)(end - start)/CLOCKS_PER_SEC, r);
return 0;
}
I have compiled it this way:
gcc -o libcliente libcliente.c -L. -lfakerand -W -Wall -pedantic
And test his link:
# ldd libcliente
linux-gate.so.1 => (0x005cf000)
libfakerand.so => /usr/local/lib/libfakerand.so (0x00db6000)
libc.so.6 => /lib/libc.so.6 (0x005ed000)
/lib/ld-linux.so.2 (0x005d0000)
I have run the test:
# ./libcliente
10 M de rand() en 47.170 s. (ejemplo.: 186687031)
10 M de fakerand() en 0.070 s. (ejemplo.: 9999)
So, it seems that dynamic function calling is not the cause for the
slowdown ... isn´t it?
I have also compiled is statically obtaining a good result:
# gcc -o libcliente libcliente.c -L. ./libfakerand.o -W -Wall -pedantic -static
# ./libcliente
10 M de rand() en 0.230 s. (ejemplo.: 186687031)
10 M de fakerand() en 0.050 s. (ejemplo.: 9999)
Just for testing, I have made this experiment with libfakerand.c:
#include <stdlib.h>
int fakerand(void) {
return rand();
}
Recompiling library and client application I obtain these results:
# ./libcliente
10 M de rand() en 46.930 s. (ejemplo.: 186687031)
10 M de fakerand() en 47.040 s. (ejemplo.: 1637401473)
Obviously, logical. fakerand() is slower than rand() because it is
just an intermediary function to rand(). This time not a fake one.
Conclusion: Everything points that the problem is located exactly at
glibc rand(), random() and random_r() functions, or at least related
to them in any way.
What is your opinion?
Thanks a lot.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
