Re: Spinlocks and CPU Architectures

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Spinlocks and CPU Architectures
Date: 2005-10-11 19:58:56
Message-ID: 18291.1129060736@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout <kleptog(at)svana(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2005-10-11 20:34:15 Re: avoid pulling up subquerys that contain volatile functions?
Previous Message Magnus Hagander 2005-10-11 19:33:00 beta2 no longer builds with MSVC?