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@xxxxxxxxxxxxxxxxx> ' <http://www.georgeanelson.com/>