Extremely poor performance crunching random numbers under PIV-FC5
Andy Green
andy at warmcat.com
Fri May 19 09:30:45 UTC 2006
BankHacker wrote:
> Ok. I tested it and worked. Thanks a lot. You seems to be a "C guru"
> or similar. GUAU!
Gah no Jakub is the Guru. I'm just a hack[er].
> 19 seconds is not a good result! I have compiled the same code on an
> Opteron 64 bits:
...
> Conclusion: random_r() function seems to suffer the same bug/problem
> than rand() standard function. Right?
I guess it can be true.
> Oddity: initstate_r() function seems to throgh very easily a
> "Segmentation Fault" error when not compiling with "-O0" flag on
> certain systems. My opteron and my PIV @ 3Ghz are affected, while my
> PIV at 2.4Ghz not. I will appreciate any comments/similar experiencies.
I imagine the segfault is because I failed to guess the meaning of the
undocumented char array that goes into initstate_r() correctly. It does
seem that the "BSD style" random functions are not widely used and I saw
in Google in the past have thrown segfaults in normal use, although that
is meant to be fixed.
> Any idea to continue testings?
I guess a way to nail the problem source down pretty solid is to make
your own tiny dynamic library with
bankhacker_random_r()
and so on exported in it. Change your code to use the bankhacker_...
versions. These functions can start by being empty I guess and just
returning a fixed value. If that loses the slowdown you can copy the
glibc() implementations into your library (if that is going to be
simple). If it keeps the slowdown, even now we deal with functions with
no real body, then you surely must have some kind of problem captured
clearly.
-Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4492 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20060519/8e7c3830/attachment-0001.bin>
More information about the fedora-list
mailing list