X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id D3DF8D7B01 for ; Wed, 24 Aug 2005 21:22:59 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 47444-03 for ; Thu, 25 Aug 2005 00:22:54 +0000 (GMT) Received: from mail.envyfinancial.com (unknown [206.248.142.186]) by svr1.postgresql.org (Postfix) with ESMTP id 5F924D7B1A for ; Wed, 24 Aug 2005 21:22:52 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.envyfinancial.com (Postfix) with ESMTP id 5DDB01BD2D; Wed, 24 Aug 2005 20:13:20 -0400 (EDT) Received: from mail.envyfinancial.com ([127.0.0.1]) by localhost (mark.mielke.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18226-05; Wed, 24 Aug 2005 20:13:20 -0400 (EDT) Received: by mail.envyfinancial.com (Postfix, from userid 500) id 235881BD2E; Wed, 24 Aug 2005 20:13:20 -0400 (EDT) Date: Wed, 24 Aug 2005 20:13:20 -0400 From: mark@mark.mielke.cc To: Alan Stange Cc: Donald Courtney , pgsql-performance@postgresql.org Subject: Re: Caching by Postgres Message-ID: <20050825001320.GA18300@mark.mielke.cc> References: <20050823171045.12112.qmail@web51309.mail.yahoo.com> <20050823124323.710a9dd3.frank@wiles.org> <430B6DE3.6040109@sun.com> <430C7448.7030103@sun.com> <20050824173055.GA11788@mark.mielke.cc> <430CC0AD.5040400@rentec.com> <20050824193441.GA13772@mark.mielke.cc> <430CE1F0.3080205@rentec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <430CE1F0.3080205@rentec.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: amavisd-new at mail.envyfinancial.com X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.215 required=5 tests=[AWL=0.037, NO_REAL_NAME=0.178] X-Spam-Level: X-Archive-Number: 200508/410 X-Sequence-Number: 14157 On Wed, Aug 24, 2005 at 05:09:04PM -0400, Alan Stange wrote: > The older 32bit RISC processors do have 64 bit registers, ALUs and > datapaths, and they are marketed toward high end scientific computing, > and you're claiming that such a processor is slower than one which has > the addition of 64 bit pointers added to it? No. I'm claiming that you are talking about a hybrid 64/32 processor, and that this isn't fair to declare that 64-bit arithmetic units don't provide benefit for 64-bit math. :-) > As an example, an UltraSparc running a 32 bit kernel+application will > have the same double precision floating point performance as one > running a 64bit kernel+application (except for the additional FP > registers in the 64bit API). For a function like daxpy, it's the exact > same hardware running the exact same instructions! So why do you think > the performance would be different? Double precision floating point isn't 64-bit integer arithmetic. I think this is all a little besides the point. If you point is that the SPARC was designed well - I agree with you. I won't agree that a SPARC with 64-bit registers should be considered a 32-bit machine. The AMD 64-bit machines come in two forms as well - the ones that allow you to use the 64-bit integer registers (not floating point! those are already 80-bit!), and the ones that allow you to address more memory. I wouldn't consider either to be a 32-bit CPU, although they will allow 32-bit applications to run fine. > I believe the IBM Power processors also upped everything to double > precision internally because of some details of the "multiply-add fused" > instructions. It's been a few years since I taught H&P to CS > undergrads, but I'm fairly sure the details are all the same for MIPS > processors as well. Smart design, that obscures the difference - but doesn't make the difference a myth. If it's already there, then it's already there, and we can't talk as if it isn't. Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/