Re: Spinlocks and CPU Architectures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Spinlocks and CPU Architectures
Date
Msg-id 18291.1129060736@sss.pgh.pa.us
Whole thread Raw
In response to Re: Spinlocks and CPU Architectures  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Tue, Oct 11, 2005 at 02:28:02PM -0400, Tom Lane wrote:
>> One thought that comes to mind is that these decisions are probably
>> comparable to those made by gcc conditional on -march flags.  Do we
>> get access to the -march setting by means of predefined symbols?

> The option is available see below. It appears __tune_xxx__ is set for
> the -mcpu option and __xxx__ is set for the -march option. This is gcc
> 3.3.5, but it probably works for older versions...

Actually, after reviewing the thread from last month, I was
misremembering: *all* of the test cases we had for x86_64 showed the
cmpb to be a loss.  It was only on plain x86 that there was some
difference of results for that patch.  So I think we should just remove
the cmpb unconditionally for x86_64, and be done with it.  We can leave
the x86 case alone, at least for now, because there didn't seem to be
any cases of big wins there.

The reason I was confused was that the related patch to vary the spinlock
delay loop count seemed to be a win on Opteron but a loss on EM64T.
This probably means that we need a smarter algorithm for varying the
loop count --- the upper limit has to be configurable, perhaps.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Magnus Hagander"
Date:
Subject: beta2 no longer builds with MSVC?
Next
From: Jaime Casanova
Date:
Subject: Re: avoid pulling up subquerys that contain volatile functions?