Extremely poor performance crunching random numbers under PIV-FC5

[Tony Nelson]

At 5:45 PM +0100 5/19/06, Andy Green wrote:
 ...
>BankHacker wrote:
 ...
>>     2.- Jakub told that "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." It sounds very interesting but I don´t know how
>> to handle this ... any further explanation would be a great hint.
>> Thanks!
>
>I didn't really understand what Jakub was telling with this (it seems
>that the compiler would react to expecting needing threadsafety in an
>expensive way?) but as I understood it the random_r() test was intended
>to test around this case.

A "lock" prefix is how one does atomic instructions for multi-processors on
x86.  Jakub says that on PIV it is unreasonably slow, especially when
compared to all the other x86 chips.  The library is trying to avoid using
the expensive instruction -- which is probably expensive on all x86, though
only terribly so on PIV -- when it isn't needed.  Atomic operations are not
needed when there is only one thread that can access the data structure.
If, for some reason, that check is failing and the lock prefix is being
executed, that could explain the slowdown.  It is possible that some of the
cleanup that was done to eliminate the old Linux Threads in favor of NPTL
may have led to this happening.

The code Jakub showed hacks the x86 ISA in a way that might cause slowdowns
on some implementations, but what do I know.
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>