Re: 64-bit vs 32-bit performance ... backwards? - Mailing list pgsql-performance

Installation of a 32-bit PostgreSQL on a 64-bit Linux like RHEL 4 is
very easy. Make sure that you have installed all needed 32-bit libs and
devel packages.

Here is an example to call configure to get a 32-bit PostgreSQL:

CXX="/usr/bin/g++ -m32" \
CPP="/usr/bin/gcc -m32 -E" \
LD="/usr/bin/ld -m elf_i386" \
AS="/usr/bin/gcc -m32 -Wa,--32 -D__ASSEMBLY__ -traditional" \
CC="/usr/bin/gcc -m32" \
CFLAGS="-O3 -funroll-loops -fno-strict-aliasing -pipe -mcpu=opteron
-march=opteron -mfpmath=sse -msse2" \
./configure --prefix=<pgsql-path>


J. Andrew Rogers schrieb:
> The short story is that for us 64-bit PostgreSQL on Opterons is
> typically something like 20% faster than 32-bit on the same, and *much*
> faster than P4 Xeon systems they nominally compete with.  AMD64 is a
> more efficient architecture than x86 in a number of ways, and the
> Opteron has enviable memory latency and bandwidth that make it an
> extremely efficient database workhorse.  x86->AMD64 is not a word-width
> migration, it is a different architecture cleverly designed to be
> efficiently compatible with x86.  In addition to things like a more
> RISC-like register set, AMD64 uses a different floating point
> architecture that is more efficient than the old x87.
>

I did a few test in the past with 64-bit PostgreSQL and 32-bit
PostgreSQL and the 32-bit version was always faster.
Please find attached a small patch with does apply a change to the
x86_64 part also to the i386 part of src/include/storage/s_lock.h.
Without this change the performance of PostgreSQL 8.0 was horrible on a
Opteron. The effect is smaller with PostgreSQL 8.1.

Cheers
Sven.




diff -Naur postgresql-8.1.4.orig/src/include/storage/s_lock.h postgresql-8.1.4/src/include/storage/s_lock.h
--- postgresql-8.1.4.orig/src/include/storage/s_lock.h    2005-10-11 22:41:32.000000000 +0200
+++ postgresql-8.1.4/src/include/storage/s_lock.h    2006-05-31 09:19:04.000000000 +0200
@@ -125,12 +125,9 @@
      * extra test appears to be a small loss on some x86 platforms and a small
      * win on others; it's by no means clear that we should keep it.
      */
+    /* xchg implies a LOCK prefix, so no need to say LOCK explicitly */
     __asm__ __volatile__(
-        "    cmpb    $0,%1    \n"
-        "    jne        1f        \n"
-        "    lock            \n"
         "    xchgb    %0,%1    \n"
-        "1: \n"
 :        "+q"(_res), "+m"(*lock)
 :
 :        "memory", "cc");
@@ -189,8 +186,8 @@
      * is a huge loss.  On EM64T, it appears to be a wash or small loss,
      * so we needn't bother to try to distinguish the sub-architectures.
      */
+    /* xchg implies a LOCK prefix, so no need to say LOCK explicitly */
     __asm__ __volatile__(
-        "    lock            \n"
         "    xchgb    %0,%1    \n"
 :        "+q"(_res), "+m"(*lock)
 :