Re: Spinlock backoff algorithm - Mailing list pgsql-hackers

Tom Lane wrote:
> Magne Mæhre <Magne.Mahre@Sun.COM> writes:
>   
>> I understand the reasoning for the backoff (as of the discussion on
>> 2003-08-05), but is there any particular reason for using floating
>> point operations here ?   Maybe a modulo would be just as good (or
>> better since it doesn't involve the FPU) ?
>>     
> My goodness that's a hardware-dependent proposal.  Shall we discuss
> how many CPUs there are where an integer division is *slower* than
> a floating-point op?
>   
Hi Tom:

Do you have one in mind, or is this a straw man? :-)

> Why do you think that a couple of FP ops here are a problem, anyway?
> This is a code path where we've already yielded the processor, so
> by definition the repetition rate has to be pretty low.
Yielded the processor? Or yielded the lock? With 32 active threads 
contending for the lock, but first contending for the FPU, one could see 
how it might be relevant.

I think I agree with you that this won't be the only problem, however, 
the FPU may not need to contribute to the problem?

> The other problem with using modulo is that it makes the result depend
> mostly on the low-order bits of the random() result, rather than mostly
> on the high-order bits; with lower-grade implementations of random(),
> the lower bits are materially less random than the higher.  Now
> admittedly high-grade randomness is probably not too important for this
> specific context, but I dislike putting in poor coding practices that
> someone might see and copy without thinking...
>   
If this was a serious problem, there is the >> operator. I see it as a 
poor coding practice to make assumptions about which bits are most 
"random" in a call to random(). If anybody fixes the problem you 
describe, then the opposite may become true. Perhaps the lowest bits are 
the most random. If random() is broken, random() should be fixed. Coding 
in specific implementation details about specific implementations of 
random() is just as bad. :-)

IMHO, use of FPU should be avoided wherever possible on any platform. On 
some platforms, the FPU may be fully implemented in software. My memory 
is faint, but I think SPARC v7 either implemented / in software, or had 
a trap that implemented it in software.

Cheers,
mark

-- 
Mark Mielke <mark@mielke.cc>