[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Extremely poor performance crunching random numbers under PIV-FC5



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.


There are some magic things down

/proc/sys/kernel/

that you might want to meddle with to see if they affect the situation.  Eg

echo "0" >/proc/sys/kernel/randomize_va_space
echo "0" >/proc/sys/kernel/exec-shield

The original values for these files were "1". I set them to "0" as you
told me. These are the results:

	# ./dynamic-test-cpu-2
	... 10 M de rand() en 44.840 sec (example.: 93862647) ...

	# echo "0" >/proc/sys/kernel/randomize_va_space
	# ./dynamic-test-cpu-2
	... 10 M de rand() en 44.800 sec (example.: 1936430894) ...

	# echo "0" >/proc/sys/kernel/exec-shield
	# ./dynamic-test-cpu-2
	... 10 M de rand() en 44.800 sec (example.: 677622031) ...

I am afraid the problem is still present.



Another idea, perhaps to to give a static libm and keep the dynamic libc
stuff  eg

gcc blah.c /usr/lib/libm.a

not sure if that will work but worth a try.  Then the ldd for the
resulting binary should no longer reference libm.


Ok. I compile it with libm this way:
	gcc test-cpu-2.c -o libm-test-cpu-2 /usr/lib/libm.a -lm -O3

Obtaining:
	# file ./libm-test-cpu-2
	./libm-test-cpu-2: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs),
for GNU/Linux 2.6.9, not stripped

These are the results:
	# ./libm-test-cpu-2
	Reservado 0.1 Gb de memoria en 0.000 segundos
	Escritura sobre 0.1 Gb de memoria en 0.230 segundos
	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.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]