"Michael Paesold" <mpaesold@gmx.at> writes:
> To have other data, I have retested the patches on a single-cpu Intel P4
> 3GHz w/ HT (i.e. 2 virtual cpus), no EM64T. Comparing to the 2,4 dual-Xeon
> results it's clear that this is in reality only one cpu. While the runtime
> for N=1 is better than the other system, for N=4 it's already worse. The
> situation with the patches is quite different, though. Unfortunatly.
> CVS tip from 2005-09-12:
> 1: 36s 2: 77s (cpu ~85%) 4: 159s (cpu ~98%)
> only slock-no-cmpb:
> 1: 36s 2: 81s (cpu ~79%) 4: 177s (cpu ~94%)
> (doesn't help this time)
Hm. This is the first configuration we've seen in which slock-no-cmpb
was a loss. Could you double-check that result?
> Is there a portable way to detect the CPU we are running on? Do you have any
> other idea how to implement the delays?
I can't see any reasonable way to do runtime switching of the cmpb test
--- whatever logic we put in to control it would cost as much or more
than the cmpb anyway :-(. I think that has to be a compile-time choice.
From my perspective it'd be acceptable to remove the cmpb only for
x86_64, since only there does it seem to be a really significant win.
On the other hand it seems that removing the cmpb is a net win on most
x86 setups too, so maybe we should just do it and accept that there are
some cases where it's not perfect. Looking back at the original
discussion, I see that the cmpb was added with little discussion and no
specific performance testing, so it shouldn't be presumed to have a lot
of weight behind it:
http://archives.postgresql.org/pgsql-patches/2003-12/msg00352.php
The other thing that's going on in the patch is dynamic adjustment of
spins_per_delay, and that could certainly be made much smarter than it
is now. For instance, it'd cost almost nothing to make the lower and
upper bounds for spins_per_delay be variables instead of constants.
We could set the bounds during postmaster startup based on some criteria
yet to be determined.
regards, tom lane