Re: Spinlock backoff algorithm
От | Mark Mielke |
---|---|
Тема | Re: Spinlock backoff algorithm |
Дата | |
Msg-id | 473B1266.1050106@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: Spinlock backoff algorithm (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Spinlock backoff algorithm
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Spinlock backoff algorithm (Greg Smith <gsmith@gregsmith.com>) |
Список | 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>
В списке pgsql-hackers по дате отправления: