X-Original-To: pgsql-performance-postgresql.org@postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id 304ED9FA5E7
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 13 Jun 2006 06:04:47 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024)
	with ESMTP id 48769-06 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 13 Jun 2006 06:04:37 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from mail.aeccom.com (port-83-236-156-26.static.qsc.de
	[83.236.156.26])
	by postgresql.org (Postfix) with ESMTP id 1C7ED9F9316
	for <pgsql-performance@postgresql.org>;
	Tue, 13 Jun 2006 06:04:36 -0300 (ADT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.aeccom.com (Postfix) with ESMTP id 6ADB01CFF0
	for <pgsql-performance@postgresql.org>;
	Tue, 13 Jun 2006 11:04:35 +0200 (CEST)
Received: from mail.aeccom.com ([127.0.0.1])
	by localhost (gate6.aeccom.com [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 28250-02-9 for <pgsql-performance@postgresql.org>;
	Tue, 13 Jun 2006 11:04:34 +0200 (CEST)
Received: from [192.168.2.14] (andes.core.aeccom.com [192.168.2.14])
	by mail.aeccom.com (Postfix) with ESMTP id 4812A1CFEA
	for <pgsql-performance@postgresql.org>;
	Tue, 13 Jun 2006 11:04:34 +0200 (CEST)
Message-ID: <448E7FA0.5030006@aeccom.com>
Date: Tue, 13 Jun 2006 11:04:32 +0200
From: Sven Geisler <sgeisler@aeccom.com>
Organization: AEC/communications GmbH
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Pgsql-Performance ((E-mail))" <pgsql-performance@postgresql.org>
Subject: Re: 64-bit vs 32-bit performance ... backwards?
References: <1150151282.14661.42.camel@tigger>
	<54CA6A16-AB42-440D-B5DB-BC43AE283ED8@blighty.com>
	<448E11B1.20309@commandprompt.com>
	<31554317-AD3E-4D08-92DC-7958E46A0D47@neopolitan.com>
In-Reply-To: <31554317-AD3E-4D08-92DC-7958E46A0D47@neopolitan.com>
Content-Type: multipart/mixed; boundary="------------030908050406040306000605"
X-Virus-Scanned: amavisd-new at aeccom.com
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200606/171
X-Sequence-Number: 19528

This is a multi-part message in MIME format.
--------------030908050406040306000605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.





--------------030908050406040306000605
Content-Type: text/plain;
 name="postgresql-8.1.4.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="postgresql-8.1.4.patch"

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

--------------030908050406040306000605--