Extremely poor performance crunching random numbers under PIV-FC5
Jakub Jelinek
jakub at redhat.com
Thu May 18 15:32:43 UTC 2006
On Thu, May 18, 2006 at 05:06:28PM +0200, BankHacker wrote:
> I think this could be the reason for the slowdown in my case because
> symptoms match. My program is invoking 10 million system calls for the
> first random test and it happens only in the dynamic version. My CPU
> is an Intel Pentium IV.
You are not invoking 10 million system calls, just 10 million library
routines. Now, rand() as well as random() are thread-safe routines,
so they need to use a lock to protect the seed (unlike say random_r ()).
On i?86, glibc inlines the lock code:
14: b9 01 00 00 00 mov $0x1,%ecx
19: 65 83 3d 0c 00 00 00 cmpl $0x0,%gs:0xc
20: 00
21: 74 01 je 24 <__random+0x24>
23: f0 0f b1 8b XX XX XX lock cmpxchg %ecx,0xXXXXXXXX(%ebx)
2a: XX
2b: 0f 85 8f 01 00 00 jne 1c0 <_L_mutex_lock_13>
and similarly for unlock.
%gs:0xc ought to be non-zero only when the first pthread_call in the program
has been made.
On PIV, atomic instructions are horribly expensive.
Either you have preloaded some library that called pthread_create,
or your CPU is unable to do the jump around lock prefix trick quickly.
I certainly don't see your testcase being slow on my AMD64, neither
for 64-bit nor 32-bit program.
First of all, try benchmarking random_r, then see under debugger
if %gs:0xc is 0 or not.
Jakub
More information about the fedora-list
mailing list