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 E9B7FD7A59 for ; Wed, 24 Aug 2005 18:10:25 -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 64704-10 for ; Wed, 24 Aug 2005 21:10:24 +0000 (GMT) Received: from unicorn.rentec.com (unicorn.rentec.com [216.223.240.9]) by svr1.postgresql.org (Postfix) with ESMTP id F39C2D7A19 for ; Wed, 24 Aug 2005 18:10:23 -0300 (ADT) Received: from ram.rentec.com (mailhost [192.5.35.66]) by unicorn.rentec.com (8.13.1/8.12.1) with ESMTP id j7OL959w025968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2005 17:09:06 -0400 (EDT) X-Rentec: external Received: from [172.26.132.145] (hoopoe.rentec.com [172.26.132.145]) by ram.rentec.com (8.13.1/8.12.1) with ESMTP id j7OL949a019445; Wed, 24 Aug 2005 17:09:05 -0400 (EDT) Message-ID: <430CE1F0.3080205@rentec.com> Date: Wed, 24 Aug 2005 17:09:04 -0400 From: Alan Stange Reply-To: stange@rentec.com Organization: Renaissance Technologies Corp. User-Agent: Mozilla Thunderbird 1.0+ (X11/20050712) MIME-Version: 1.0 To: mark@mark.mielke.cc Cc: Donald Courtney , pgsql-performance@postgresql.org Subject: Re: Caching by Postgres 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> In-Reply-To: <20050824193441.GA13772@mark.mielke.cc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Logged: Logged by unicorn.rentec.com as j7OL959w025968 at Wed Aug 24 17:09:06 2005 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.019 required=5 tests=[AWL=0.019] X-Spam-Level: X-Archive-Number: 200508/407 X-Sequence-Number: 14154 mark@mark.mielke.cc wrote: > On Wed, Aug 24, 2005 at 02:47:09PM -0400, Alan Stange wrote: > >> At least on Sparc processors, v8 and newer, any double precision math >> (including longs) is performed with a single instruction, just like for >> a 32 bit datum. Loads and stores of 8 byte datums are also handled via >> a single instruction. The urban myth that 64bit math is >> different/better on a 64 bit processor is just that; yes, some lower >> end processors would emulate/trap those instructions but that an >> implementation detail, not architecture. >> > > It isn't an urban myth that 64-bit math on a 64-bit processor is > faster, at least if done using registers. It definately is faster. > 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? 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? 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. -- Alan