Re: Spinlock backoff algorithm - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Spinlock backoff algorithm
Date
Msg-id 24101.1195054788@sss.pgh.pa.us
Whole thread Raw
In response to Re: Spinlock backoff algorithm  (Mark Mielke <mark@mark.mielke.cc>)
Responses Re: Spinlock backoff algorithm  (Josh Berkus <josh@agliodbs.com>)
Re: Spinlock backoff algorithm  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Mark Mielke <mark@mark.mielke.cc> writes:
> Tom Lane wrote:
>> 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?

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

I've got one upstairs (HPPA), and I believe that it's actually a pretty
common situation in scientifically-oriented workstations from a few
years back.

>> 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?

Yielded the processor, as in pg_usleep.  It is absolutely impossible for
any thread to execute that line of code more than 1000 times per second,
and the expected rate would be very much less.  Furthermore, the entire
point of the function is to try to make processes come out of the sleep
at different times, so they shouldn't be ganging up on the FPU anyway.

There may be some place where we have an unnecessarily high amount
of FP usage, but I very much doubt that this is it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Spinlock backoff algorithm
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] a tsearch2 (8.2.4) dictionary that only filters out stopwords