=?ISO-8859-1?Q?Magne_M=E6hre?= <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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly

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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Josh Berkus <josh@agliodbs.com> writes: > Nah, if it's only Niagara, it's not worth bothering. It's not only that aspect of it --- it's that I am 100% convinced that Magne has misidentified the source of whatever FPU contention he's seeing. The floating-point code in s_lock() is executed only just after having returned from a sleep that is at least one millisecond and often many times that. If Niagara cannot handle a few kiloflops then you need to find some other company to work for ;-) I am interested to find out what the true cause of the reported FPU contention is, but I'll bet our next lunch that s_lock.c ain't it. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org