> Really? Cool, I'd like to see that. Could you follow up with Hans?
> Or give
> me his e-mail?

You can subscribe to the Reiser mailinglist on namesys.com or :
reiser@namesys.com

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Wed, Aug 24, 2005 at 09:21:12AM -0400, Donald Courtney wrote:
> I built postgreSQL 8.1 64K bit on solaris 10 a few months ago
> and side by side with the 32 bit postgreSQL build saw no improvement.
> In fact the 64 bit result was slightly lower.

I've had this sort of argument with a friend of mine who works at a
retail computer sales company who always tries to pitch 64-bit
platforms to me (I don't have one yet).

There are a few issues in here that are hard to properly detach to
allow for a fair comparison.

The first, to always remember - is that the move from 64-bits to
32-bits doesn't come for free. In a real 64-bit system with a
64-bit operating system, and 64-bit applications, pointers are
now double their 32-bit size. This means more bytes to copy around
memory, and in an extreme case, has the potential to approach
halfing both the memory latency to access many such pointers from
RAM, and half the effective amount of RAM. In real world cases,
not everything is a pointer, so this sort of performance degradation
is doubtful - but it is something to keep in mind.

In response to this, it appears that, at least on the Intel/AMD side
of things, they've increased the bandwidth on the motherboard, and
allowed for faster memory to be connected to the motherboard. They've
increased the complexity of the chip, to allow 64-bit register
operations to be equivalent in speed to 32-bit register operations.
I have no idea what else they've done... :-)

So, it may be difficult to properly compare a 32-bit system to a
64-bit system. Even if the Ghz on the chip appears equal, it isn't
the same chip, and unless it is the exact same make, product and
version of the motherboard, it may not be a fair compairson. Turning
support for 32-bit on or off, and using a kernel that is only 32-bit
may give good comparisons - but with the above explanation, I would
expect the 32-bit application + kernel to out-perform the 64-bit
application.

So then we move on to what 64-bit is really useful for. Obviously,
there is the arithmetic. If you were previously doing 64-bit
arithmetic through software, you will notice an immediate speed
improvement when doing it through hardware instead. If you have
a program that is scanning memory in any way, it may benefit from
64-bit instructions (for example - copying data 64-bit words at
a time instead of 32-bit words at a time). PostgreSQL might benefit
slightly from either of these, slightly balancing the performance
degradation of using more memory to store the pointers, and more
memory bandwidth the access the pointers.

The real benefit of 64-bit is address space. From the kernel
perspective, it means that more programs, or bigger programs can run
at once. From the application perspective, it means your application
can use more than 32-bits of address space. For programs that make
extensive use of mmap(), this can be a necessity. They are mapping
very large files into their own address space. This isn't a
performance boost, as much as it is a 'you can't do it', if the
files mmap()'ed at the same time, will not fit within 32-bits of
address space. This also becomes, potentially, a performance
degradation, as the system is now having to manage applications
that have very large page tables. Page faults may become
expensive.

PostgreSQL uses read(), instead of mmap(), and uses <2 Gbyte files.
PostgreSQL doesn't require the additional address space for normal
operation.

If, however, you happen to have a very large amount of physical memory
- more memory than is supported by a 32-bit system, but is supported
by your 64-bit system, then the operating system should be able to use
this additional physical memory to cache file system data pages, which
will benefit PostgreSQL if used with tables that are larger than the
memory supported by your 32-bit system, and which have queries which
require more pages than the memory supported by your 32-bit system to
be frequently accessed. If you have a huge database, with many clients
accessing the data, this would be a definate yes. With anything less,
it is a maybe, or a probably not.

I've been looking at switching to 64-bit, mostly to benefit from the
better motherboard bandwidth, and just to play around. I'm not
expecting to require the 64-bit instructions.

Hope this helps,
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/


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Donald Courtney wrote:
> I built postgreSQL 8.1 64K bit on solaris 10 a few months ago
> and side by side with the 32 bit postgreSQL build saw no improvement. In
> fact the 64 bit result was slightly lower.

I'm not surprised 32-bit binaries running on a 64-bit OS would be faster
than 64-bit/64-bit. 64-bit isn't some magical wand you wave and it's all
ok. Programs compiled as 64-bit will only run faster if (1) you need
64-bit address space and you've been using ugly hacks like PAE to get
access to memory > 2GB or (2) you need native 64-bit data types and
you've been using ugly hacks to piece 32-bit ints together (example,
encryption/compression). In most cases, 64-bit will run slightly slower
due to extra overhead of using larger datatypes.

Since PostgreSQL hands off the majority of memory management/data
caching to the OS, only the OS needs to be 64-bit to reap the benefits
of better memory management. Since Postgres *ALREADY* reaps the 64-bit
benefit, I'm not sure how the argument moving caching/mm/fs into
Postgres would apply. Yes there's the point about possibly implementing
better/smarter/more appropriate caching algorithms but that has nothing
to do with 64-bit.

mark@mark.mielke.cc wrote:
> So then we move on to what 64-bit is really useful for. Obviously,
> there is the arithmetic. If you were previously doing 64-bit
> arithmetic through software, you will notice an immediate speed
> improvement when doing it through hardware instead. If you have
> a program that is scanning memory in any way, it may benefit from
> 64-bit instructions (for example - copying data 64-bit words at
> a time instead of 32-bit words at a time). PostgreSQL might benefit
> slightly from either of these, slightly balancing the performance
> degradation of using more memory to store the pointers, and more
> memory bandwidth the access the pointers.
>
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. I believe that this is all
true for other RISC processors as well.

The 64bit API on UltraSparcs does bring along some extra FP registers IIRC.

> If, however, you happen to have a very large amount of physical memory
> - more memory than is supported by a 32-bit system, but is supported
> by your 64-bit system, then the operating system should be able to use
> this additional physical memory to cache file system data pages, which
> will benefit PostgreSQL if used with tables that are larger than the
> memory supported by your 32-bit system, and which have queries which
> require more pages than the memory supported by your 32-bit system to
> be frequently accessed. If you have a huge database, with many clients
> accessing the data, this would be a definate yes. With anything less,
> it is a maybe, or a probably not.
>
Solaris, at least, provided support for far more than 4GB of physical
memory on 32 bit kernels. A newer 64 bit kernel might be more
efficient, but that's just because the time was taken to support large
page sizes and more efficient data structures. It's nothing intrinsic
to a 32 vs 64 bit kernel.

-- Alan

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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.

It may be an urban myth, though, that most applications perform
a sufficient amount of 64-bit arithmetic to warrant the upgrade.
The benefit may be lost in the noise for an application such as
PostgreSQL. It takes, effectively, infinately longer to access
a disk page, than to increment a 64-bit integer in software.

For the lower end processors that emulate/trap these instructions,
they are being performed in software, along with the overhead of a
trap, and are therefore not a single instruction any more. We are
coming at this from different sides (which is good - perspective is
always good :-) ). From the Intel/AMD side of things, ALL non 64-bit
platforms are 'lower end processors', and don't emulate/trap the
instructions as they didn't exist (at least not yet - who knows what
clever and sufficiently motivated people will do :-) ).

> >If, however, you happen to have a very large amount of physical memory
> >- more memory than is supported by a 32-bit system, but is supported
> >by your 64-bit system, then the operating system should be able to use
> >this additional physical memory to cache file system data pages, which
> >will benefit PostgreSQL if used with tables that are larger than the
> >memory supported by your 32-bit system, and which have queries which
> >require more pages than the memory supported by your 32-bit system to
> >be frequently accessed. If you have a huge database, with many clients
> >accessing the data, this would be a definate yes. With anything less,
> >it is a maybe, or a probably not.
> Solaris, at least, provided support for far more than 4GB of physical
> memory on 32 bit kernels. A newer 64 bit kernel might be more
> efficient, but that's just because the time was taken to support large
> page sizes and more efficient data structures. It's nothing intrinsic
> to a 32 vs 64 bit kernel.

Hehe. That's why I was so careful to qualify my statements. :-)

But yeah, I agree. It's a lot of hype, for not much gain (and some
loss, depending on what it is being used for). I only want one because
they're built better, and because I want to play around.

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/


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

> 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. I believe that this is all
> true for other RISC processors as well.
>
> The 64bit API on UltraSparcs does bring along some extra FP registers
> IIRC.

It's very different on x86.
64-bit x86 like the Opteron has more registers, which are very scarce on
the base x86 (8 I think). This alone is very important. There are other
factors as well.

> Solaris, at least, provided support for far more than 4GB of physical
> memory on 32 bit kernels. A newer 64 bit kernel might be more
> efficient, but that's just because the time was taken to support large
> page sizes and more efficient data structures. It's nothing intrinsic
> to a 32 vs 64 bit kernel.

Well, on a large working set, a processor which can directly address more
than 4GB of memory will be a lot faster than one which can't, and has to
play with the MMU and paging units !

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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




---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Wed, Aug 24, 2005 at 03:34:41PM -0400, mark@mark.mielke.cc wrote:
>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.
>It may be an urban myth, though, that most applications perform
>a sufficient amount of 64-bit arithmetic to warrant the upgrade.

The mjor problem is that the definition of "64bit processor" is fuzzy.
The major slowdown of "64bitness" is the necessity of carting around
64 bit pointers. It's not, however, necessary to do 64bit pointers to
get 64bit registers & fast 64 bit ops. E.g., sgi has "n32" & "n64" abi's
which can access exactly the same instruction set & registers, the
difference between them is the size of pointers and whether a "long" is
the same as a "long long". Any discussion of "64 bit processors" is
doomed from the start because people tend to start making implementation
assumptions on top of an already vague concept. Current & future
discussions are tinged by the fact that amd64 *doubles* the number
of registers in 64 bit mode, potentially providing a major speedup--but
one that doesn't really have anything to do with being "64bit".
Pretty much any discussion of 64 bit mode really needs to be a
discussion of a particular abi on a particular processor; talking about
"64 bit processors" abstractly is a waste of time.

Mike Stone

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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/


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

> The first, to always remember - is that the move from 64-bits to
> 32-bits doesn't come for free. In a real 64-bit system with a
> 64-bit operating system, and 64-bit applications, pointers are
> now double their 32-bit size. This means more bytes to copy around
> memory, and in an extreme case, has the potential to approach
> halfing both the memory latency to access many such pointers from
> RAM, and half the effective amount of RAM. In real world cases,
> not everything is a pointer, so this sort of performance degradation
> is doubtful - but it is something to keep in mind.
>
In addition to the above it lessens the effects of the CPU cache, so be
sure to take the larger cached versions if you have structures needing
to fit into the cache...

my 0.02 EUR

thomas