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