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

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

 



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.

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux