From: mark@mark.mielke.cc
To: Alan Stange <stange@rentec.com>
Cc: Donald Courtney <Donald.Courtney@Sun.COM>
Cc: pgsql-performance@postgresql.org
Subject: Re: Caching by Postgres
Date: Wed, 24 Aug 2005 20:13:20 -0400
Message-ID: <20050825001320.GA18300@mark.mielke.cc> (raw)
In-Reply-To: <430CE1F0.3080205@rentec.com>
References: <20050823171045.12112.qmail@web51309.mail.yahoo.com>
<20050823124323.710a9dd3.frank@wiles.org>
<430B6DE3.6040109@sun.com>
<deg68k$16gh$1@news.hub.org>
<430C7448.7030103@sun.com>
<20050824173055.GA11788@mark.mielke.cc>
<430CC0AD.5040400@rentec.com>
<20050824193441.GA13772@mark.mielke.cc>
<430CE1F0.3080205@rentec.com>
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/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark@mark.mielke.cc, stange@rentec.com, Donald.Courtney@Sun.COM
Subject: Re: Caching by Postgres
In-Reply-To: <20050825001320.GA18300@mark.mielke.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox