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
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? |