BankHacker wrote:
Ahaha, so if I understand you the strace output is huge for the dynamic one and smaller for the static one?Yes, but it is no huge, just a little bit bigger. Only several lines greater, those I wrote in the previous message.Can you post an example of one of the "10 million" syscalls that is present in the strace output for the dynamic case (if I understood you correctly)?There is no trace for individual syscalls (supposing rand() function is really a syscall ...) in the trace output.
I think the news is that rand() does not generate a syscall, or we should expect to see it in the output of strace. Jakub says it is just a call to a usermode function in libc too.
echo "0" >/proc/sys/kernel/randomize_va_space echo "0" >/proc/sys/kernel/exec-shieldI am afraid the problem is still present.
Oh well just a guess since the difference seems to hinge on whether the library is loaded in or not.
gcc test-cpu-2.c -o libm-test-cpu-2 /usr/lib/libm.a -lm -O3
10 M de rand() en 44.800 sec (example.: 3392997)
10 M de sqrt(i) en 0.180 sec (example.: 3162)
10 M de log(i) en 0.920 sec (example.: 16)
10 M de log10(i) en 0.950 sec (example.: 6)
...
So identical results in rand() but worst results in other mathematical
functions.
It seems that maybe we can just say the whole problem comes down to that rand() from dynamically linked libc.so.6 is slower to execute than what is supposed to be the same code statically linked.
Doing top meanwhile Fedora is executing (static/dynamic/libm)_test-cpu-2 gives always a load of 1.05 more or less. So the CPU is working at full throttle in every case.
If you can't get random_r() to work (see eg http://refspecs.freestandards.org/LSB_1.2.0/gLSB/baselib-random-r-3.html) I think what I would do here is open /dev/urandom and read stuff from it, see how that performs. Maybe you can read 4K bytes for example from it into a buffer to limit syscall overhead, and move an int * along the buffer.
-Andy
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
