Re: Spinlock backoff algorithm - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Spinlock backoff algorithm
Date
Msg-id 23504.1195052419@sss.pgh.pa.us
Whole thread Raw
In response to Spinlock backoff algorithm  (Magne Mæhre <Magne.Mahre@Sun.COM>)
Responses Re: Spinlock backoff algorithm  (Mark Mielke <mark@mark.mielke.cc>)
Re: Spinlock backoff algorithm  ("Trevor Talbot" <quension@gmail.com>)
List pgsql-hackers
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?

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.

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...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Simplifying Text Search
Next
From: Mark Mielke
Date:
Subject: Re: Spinlock backoff algorithm