Re: Spinlocks and CPU Architectures

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

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Tue, 2005-10-11 at 18:45 +0200, Peter Eisentraut wrote:
>> A number of packages in the video area (and perhaps others) do compile
>> "sub-architecture" specific variants. This could be done for
>> PostgreSQL, but you'd probably need to show some pretty convincing
>> performance numbers before people start the packaging effort.

> I completely agree, just note that we already have some cases where
> convincing performance numbers exist.

I'm not sure the data we have is convincing enough to justify
sub-architecture packaging. We have a somewhat-artificial test case
that's designed to generate the maximum possible spinlock contention,
and we can measure a significant difference in that context --- but
that's a long way from saying that a similar percentage difference would
be seen in real-world applications. It's also a long way from saying
that the effort needed to set this up wouldn't be better repaid working
on other problems.

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?
If so we could compile different TAS code for opteron and em64t without
introducing any packaging issues that didn't exist already. It would
essentially be up to the source-code builder which sub-arch to tune for.

(Since the assembly code in question currently works only for gcc
anyway, I'm not too concerned about making gcc-specific assumptions
about the availability of flag macros.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2005-10-11 19:01:22 Re: slow IN() clause for many cases
Previous Message Ilia Kantor 2005-10-11 18:13:01 Re: slow IN() clause for many cases