Re: Spinlock backoff algorithm

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Spinlock backoff algorithm
Дата
Msg-id 24101.1195054788@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Spinlock backoff algorithm  (Mark Mielke <mark@mark.mielke.cc>)
Ответы Re: Spinlock backoff algorithm  (Josh Berkus <josh@agliodbs.com>)
Re: Spinlock backoff algorithm  (Gregory Stark <stark@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Mark Mielke
Дата:
Сообщение: Re: Spinlock backoff algorithm
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] a tsearch2 (8.2.4) dictionary that only filters out stopwords