Re: Spinlock backoff algorithm

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Mark Mielke <mark(at)mark(dot)mielke(dot)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.

I think floating point is fast on many common platforms, even many i386
variants. But usually that's assuming you're comparing doing a whole bunch of
work in floating point or integer math. Converting a bunch of integers to
floating point for a single operation doesn't seem like a case that's going to
shine on any floating point unit.

And there are plenty of platforms with *no* floating point. On embedded 486,
ARM, etc the floating point will be emulated by either the compiler or the
kernel.

But as Tom said there are plenty of places using floating point arithmetic in
the kernel. The planner does all of its selectivity and costing in floating
point for example.

I wonder if you wouldn't be better off going whole hog with soft floating
point emulation. I et Sun's cc has an option to implement floating point
arithmetic entirely in user-side software.

Another option might be to compile just some modules with soft float and do
utils/adt/*.c using hardfloat -- so user-defined types still use the floating
point unit but the database's internal arithmetic is done using software
emulated math.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!