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@xxxxxx 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
