Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id A755E9FA28E for ; Mon, 11 Dec 2006 09:34:06 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 47533-04 for ; Mon, 11 Dec 2006 09:33:49 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by postgresql.org (Postfix) with ESMTP id 604219FA178 for ; Mon, 11 Dec 2006 09:33:59 -0400 (AST) Received: from trofast.ipv6.sesse.net ([2001:700:300:1803:20e:cff:fe36:a766] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtp (Exim 4.50) id 1GtlI2-0006R6-Il for pgsql-performance@postgresql.org; Mon, 11 Dec 2006 14:33:54 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1GtlI8-0006je-00 for ; Mon, 11 Dec 2006 14:34:00 +0100 Date: Mon, 11 Dec 2006 14:34:00 +0100 From: "Steinar H. Gunderson" To: pgsql-performance@postgresql.org Subject: Re: New to PostgreSQL, performance considerations Message-ID: <20061211133400.GA25821@uio.no> Mail-Followup-To: pgsql-performance@postgresql.org References: <8a0c7af10612101141n2c7727c3r2f92345753960808@mail.gmail.com> <430d92a20612101336r3de8862coe618277fccb4006a@mail.gmail.com> <8a0c7af10612101702i49b5a533v4a2300d90d9dae6b@mail.gmail.com> <20061211021847.GE16692@mathom.us> <8a0c7af10612110305u305124b2v3d63491b5f57a86b@mail.gmail.com> <20061211112547.GA24571@uio.no> <8a0c7af10612110509r7b1d5a5er68d4efd32c8c0e1e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8a0c7af10612110509r7b1d5a5er68d4efd32c8c0e1e@mail.gmail.com> X-Operating-System: Linux 2.6.19 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/225 X-Sequence-Number: 22281 On Mon, Dec 11, 2006 at 11:09:13AM -0200, Daniel van Ham Colchete wrote: >> You know what? I don't. > So test it yourself. You're making the claims, you're supposed to be proving them... > As I said, it is an example. Take floatpoint divisions. You have > plenty of ways of doing it: 387, MMX, SSE, 3dNow, etc... Here GCC have > to make a choice. No, you don't. MMX, SSE and 3Dnow! will all give you the wrong result (reduced precision). SSE2, on the other hand, has double precision floats, so you might have a choice there -- except that PostgreSQL doesn't really do a lot of floating-point anyhow. > And this is only one case. Usually, compiler optimizations are really > complex and the processor's timings counts a lot. You keep asserting this, with no good backing. > If you still can't imagine any case, you can read Intel's assembler > reference. You'll see that there are a lot of ways of doing a lot of > things. I've been programming x86 assembler for ten years or so... > Steinar, you should really test it. I won't read the PostgreSQL source > to point you were it could use SSE or SSE2 or whatever. And I won't > read glibc's code. Then you should stop making these sort of wild claims. > You don't need to belive in what I'm saying. You can read GCC docs, > Intel's assembler reference, AMD's docs about their processor and > about how diferent that arch is. I have. /* Steinar */ -- Homepage: http://www.sesse.net/