Quad Xeon vs. Dual Itanium

Started by John Gibsonabout 22 years ago34 messagesgeneral
Jump to latest
#1John Gibson
gib@edgate.com

Hi, all.

I need to upgrade my dual Xeon PostgreSQL engine.

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.

Do any of you have thoughts on:

1. Straight performance capability
2. Price/Performance

I would appreciate any feedback you might have.

...john

#2Doug McNaught
doug@mcnaught.org
In reply to: John Gibson (#1)
Re: Quad Xeon vs. Dual Itanium

John Gibson <gib@edgate.com> writes:

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a
better choice.

Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?

-Doug

#3Stephen Howard
stephen@thunkit.com
In reply to: John Gibson (#1)
plperlu and 'use' statement scope question

Hello list,

I'm designing a plperlu function and i was wondering about scoping on
use statements for external libraries. I couldn't find any information
on it in the documentation or in the mail archives, so any information
would be much appreciated.

The function is intended to be used as part of a select statement:

select foo,my_function(bar) as baz from table where baz > some_value
order by baz

And the function uses an external module to do much of the heavy
lifting. What I'm wondering is will the function have to reload the
external module for every row, or is plperlu smart enough to only load
it once for the entire query? In the other extreme, I'm hoping that it
does reload the external module for each query, as I expect to be
dynamically rewriting one of the modules that that external module requires.

-Stephen

#4Rob Sell
lists@facnd.com
In reply to: Doug McNaught (#2)
Re: Quad Xeon vs. Dual Itanium

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Doug McNaught
Sent: Monday, February 09, 2004 10:44 AM
To: John Gibson
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Quad Xeon vs. Dual Itanium

John Gibson <gib@edgate.com> writes:

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a
better choice.

Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?

-Doug
-------------------------

The only way I can see that its not optimized for 64 bit would be to use
32bit binaries on it, and the only way that can even happen is on the new
amd chips I believe, or will itanium run 32bit apps also?

Rob

#5James Moe
jimoe@sohnen-moe.com
In reply to: John Gibson (#1)
Re: Quad Xeon vs. Dual Itanium

John Gibson wrote:

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.

The Itanic hasn't lived up to its marketing hype. The comparisons
I've seen between it and a 32-bit CPU show performance differences
primarily due to clock speeds. So far the only advantage of 64 bits is
address space. And because they are new, itanics cost much more.
So with 2 itanics you get a slight improvement. With 4 xeons you get
about 1.7x improvement over your current setup.

--
jimoe at sohnen-moe dot com

#6Joshua D. Drake
jd@commandprompt.com
In reply to: John Gibson (#1)
Re: Quad Xeon vs. Dual Itanium

John Gibson wrote:

Hi, all.

I need to upgrade my dual Xeon PostgreSQL engine.

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.
'

Bang for the buck per CPU you are best off using an Opteron based
solution from AMD. This will give you the 64bit address space that Xeon
can't but for a heck of a lot less money than an Itanium.

Sincerely,

Joshua D. Drake

Show quoted text

Do any of you have thoughts on:

1. Straight performance capability
2. Price/Performance

I would appreciate any feedback you might have.

...john

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

#7Lincoln Yeoh
lyeoh@pop.jaring.my
In reply to: Doug McNaught (#2)
Re: Quad Xeon vs. Dual Itanium

At 11:44 AM 2/9/2004 -0500, Doug McNaught wrote:

John Gibson <gib@edgate.com> writes:

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a
better choice.

Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?

Maybe compilers aren't as good at doing Itanium yet?

John Gibson <gib@edgate.com> writes: "I need to upgrade my dual Xeon
PostgreSQL engine."
It just might be helpful if you could tell us "where it hurts".

Unless you need cutting edge floating point performance I doubt you'd want
an Itanium (and even if you do, you might wish to consider powerpc as well).

Without any more info, I'd ask why not dual/quad Opteron? Even if you don't
recompile or wait for better compilers or use 64 bit such a system would
probably run faster than your dual Xeons.
---

http://www.infoworld.com/article/04/01/30/05FElinux_2.html

"Tests were run on three separate hardware platforms: Intel Xeon (x86),
Intel Itanium (IA-64), and AMD Opteron (x86_64). The x86 tests were
conducted on an IBM eServer x335 1U rack-mount server with dual 3.06GHz P4
Xeon processors and 2GB of RAM. The Itanium tests were run on an IBM
eServer x450 3U rack-mount server with dual 1.5GHz Itanium2 processors and
2GB of RAM. And the Opteron tests were run on a Newisys 4300 3U rack-mount
server with dual 2.2GHz Opteron 848 processors and 2GB of RAM. "

Summary: Dual Itanium slower than Xeon in many tests, Opteron fastest in
most tests.

#8John Gibson
gib@edgate.com
In reply to: John Gibson (#1)
Re: Quad Xeon vs. Dual Itanium

Doug McNaught wrote:

John Gibson <gib@edgate.com> writes:

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a
better choice.

Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?

-Doug

Please help educate me. That is why I am asking. :)

...john

#9Chris Browne
cbbrowne@acm.org
In reply to: John Gibson (#1)
Re: Quad Xeon vs. Dual Itanium

Clinging to sanity, gib@edgate.com (John Gibson) mumbled into her beard:

I need to upgrade my dual Xeon PostgreSQL engine.

Assuming similar memory and disk sub-systems, I am considering a
Quad Xeon system vs. a Dual Itanium for PostgreSQL. I believe that
the PostgreSQL code is written for 32 bit and not optimized for the
64 bit Itanium cpu. That makes me think that the Xeon system would
be a better choice.

Do any of you have thoughts on:

1. Straight performance capability
2. Price/Performance

First thing: What, in particular, makes you think that PostgreSQL code
was written to make it slower or otherwise more restrictive on 64 bit
systems than it needs to be?

Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.

Your belief of it being "written for 32 bit" should fly away in the
wake of that.

Secondly, there's a significant counterargument to this, on Intel,
when you look at memory availability.

I have been tearing hair out with some FreeBSD testing in that I have
some quad Xeon systems with 8GB of memory, which gives me the dilemma
of choosing between:

a) Ignoring 4GB of it, or
b) Not having disk connected.

The problem is that having large amounts of memory requires invoking
an Intel "hack" (on FreeBSD, the option is called "PAE"), which
happens to break the disk subsystem. (At least for the controller I
have got.)

And irrespective of any "successful hacks," you are still limited to
either 2GB or 4GB of memory for the postmaster.

If you jump into a 64 bit platform, those sorts of hacks evaporate as
unnecessary, and the main process can get as big as you need it to.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/rdbms.html
``God decided to take the devil to court and settle their differences
once and for all. When Satan heard of this, he grinned and said, "And
just where do you think you're going to find a lawyer?"''

#10scott.marlowe
scott.marlowe@ihs.com
In reply to: John Gibson (#1)
Re: Quad Xeon vs. Dual Itanium

On Mon, 9 Feb 2004, John Gibson wrote:

Hi, all.

I need to upgrade my dual Xeon PostgreSQL engine.

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.

Do any of you have thoughts on:

1. Straight performance capability
2. Price/Performance

This really depends on what you'll be doing. If your data set is very
large, then having a fast drive subsystem and lots of REALLY fast memory
matters more than CPU most of the time.

If you'll be doing lots of CPU intensive stuff, then having four CPUs is
likely to be nice.

It really kinda depends on what you're doing, and how fast the memory
busses / caches are in the two machines. The CPUs in a well tuned
database server tend to sit near idle mostly, while the drives spin and
the data in memory gets pumped around.

If the Itaniums have twice the memory bandwidth of the Xeons, it might
well be a wash for most loads.

So, what kinda profile are we looking at for your server?

#11Bruce Momjian
bruce@momjian.us
In reply to: James Moe (#5)
Re: Quad Xeon vs. Dual Itanium

James Moe wrote:

John Gibson wrote:

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.

The Itanic hasn't lived up to its marketing hype. The comparisons
I've seen between it and a 32-bit CPU show performance differences
primarily due to clock speeds. So far the only advantage of 64 bits is
address space. And because they are new, itanics cost much more.
So with 2 itanics you get a slight improvement. With 4 xeons you get
about 1.7x improvement over your current setup.

Here is an interesting article about the Opteron/Itanium issue:

http://www.theinquirer.net/?article=14038

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#12William Yu
wyu@talisys.com
In reply to: John Gibson (#1)
Re: Quad Xeon vs. Dual Itanium

John Gibson wrote:

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.

Unfortunately, both have issues.

With Itanium, you absolutely have to use the Intel compiler. GCC is
beyond unoptimized for Itanium; you should expect 1/3rd the performance
with Postgres of what the Intel compiler would do. On the otherhand,
I've heard a few caveats about the Intel compiler that a lot of the
tricks they use are 100% designed for the Spec benchmarks and could
break real world code. Depends on what your stomach is for risk taking
on how many of the optimization flags you are willing to turn on.

Quad Xeon has it's own problems. The shared bus makes the 2P to 4P
scaling a bit problematic. The more intensive you use the memory
subsystem (which probably is the case with database uses), the bigger
hit you will take. As an example, SpecIntRate's 2->4 scaling for the
XeonMP is 75% but the SpecFPRate (SpecFP uses much larger datasets)
scaling drops to a mere 31%. Which memory usage model your DB would fall
under unfortunately can only be tested by you. Also throw in the need
for PAE to go over 2GB (~1GB for caching under most OS's) and you could
see some performance penalties there versus a 64-bit server.

But looking at the straight SpecIntRate numbers though, a 4P Xeon MP
will be faster than an 2P Itanium. There's enough of a performance gap
where penalties for shared memory bus and PAE won't make enough of a
difference.

4P XeonMP 2.8GHz 47.4
4P Xeon 2GHz 34.7
2P Itanium2 1.5GHz 25.4

As for pricing, you'll have to look that up yourself. :) Personally, I'm
very fond of Opteron servers due to the combination of 64-bit + ondie
memory controller + point-to-point inter-cpu connect. As a point of
comparison, 2P-4P Opteron Spec scaling numbers are 87% ad 76%.

#13Michael Glaesemann
grzm@seespotcode.net
In reply to: Lincoln Yeoh (#7)
Re: Quad Xeon vs. Dual Itanium

On Feb 10, 2004, at 2:18 AM, Lincoln Yeoh wrote:

At 11:44 AM 2/9/2004 -0500, Doug McNaught wrote:

John Gibson <gib@edgate.com> writes:

Assuming similar memory and disk sub-systems, I am considering a

Quad

Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64

bit

Itanium cpu. That makes me think that the Xeon system would be a
better choice.

Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?

<snip />

Unless you need cutting edge floating point performance I doubt you'd
want an Itanium (and even if you do, you might wish to consider
powerpc as well).

Speaking of PowerPC, has anyone out there run PostgreSQL on a G5
(either PowerMac or Xserve)? From looking at the specs, it seems it's
got great throughput in terms of moving data around.

Michael Glaesemann
grzm myrealbox com

#14Vivek Khera
khera@kcilink.com
In reply to: John Gibson (#1)
Re: Quad Xeon vs. Dual Itanium

"JG" == John Gibson <gib@edgate.com> writes:

JG> Hi, all.
JG> I need to upgrade my dual Xeon PostgreSQL engine.

JG> Assuming similar memory and disk sub-systems, I am considering a Quad
JG> Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the

Save the money from the dual itanium or quad xeon and buy a dual xeon
but faster disks with a larger cache in the RAID controller, and
perhaps a dedicated RAID controller for the disk set that holds the
write-ahead log.

You're sure to find that you saturate the disk system faster than you
fill up even one CPU, let alone 4.

I assume that the box will be running *only* the database and any
other applications will run elsewhere.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

#15Andrew Sullivan
ajs@crankycanuck.ca
In reply to: Chris Browne (#9)
Re: Quad Xeon vs. Dual Itanium

On Mon, Feb 09, 2004 at 12:46:58PM -0500, Christopher Browne wrote:

Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.

But actually, there are problems with using postgres as a 64 bit
application on Solaris. It works, and it's reliable, but I've never
seen any evidence that it helps anything (and I've looked plenty).

A

--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland

#16Lincoln Yeoh
lyeoh@pop.jaring.my
In reply to: Andrew Sullivan (#15)
Re: Quad Xeon vs. Dual Itanium

Hmm, do you mean 64 bit postgresql on Solaris-Sparc isn't significantly
better performance-wise than 32 bit postgresql on Solaris-Sparc?

Interesting.

How about very large databases?

At 07:17 AM 2/13/2004 -0500, Andrew Sullivan wrote:

Show quoted text

On Mon, Feb 09, 2004 at 12:46:58PM -0500, Christopher Browne wrote:

Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.

But actually, there are problems with using postgres as a 64 bit
application on Solaris. It works, and it's reliable, but I've never
seen any evidence that it helps anything (and I've looked plenty).

A

--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

#17Andrew Sullivan
ajs@crankycanuck.ca
In reply to: Lincoln Yeoh (#16)
Re: Quad Xeon vs. Dual Itanium

On Fri, Feb 13, 2004 at 10:44:55PM +0800, Lincoln Yeoh wrote:

Hmm, do you mean 64 bit postgresql on Solaris-Sparc isn't significantly
better performance-wise than 32 bit postgresql on Solaris-Sparc?

Not in any test I've ever run. I haven't tried again lately, mind
you. And I never had the Sun compiler, which, for all I know, does a
better job with 64 bit binaries than gcc.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie

#18scott.marlowe
scott.marlowe@ihs.com
In reply to: Andrew Sullivan (#15)
Re: Quad Xeon vs. Dual Itanium

On Fri, 13 Feb 2004, Andrew Sullivan wrote:

On Mon, Feb 09, 2004 at 12:46:58PM -0500, Christopher Browne wrote:

Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.

But actually, there are problems with using postgres as a 64 bit
application on Solaris. It works, and it's reliable, but I've never
seen any evidence that it helps anything (and I've looked plenty).

I wonder if this would hold true when running 64 bit linux on Sparc
hardware... Could well be that the reason 64 bit is no faster than 32 bit
is that Solaris is just not a very fast platform for Postgresql, so any
improvements running 64 bit pgsql are lost in the Solaris/Postgresql mix.

#19Steve Atkins
steve@blighty.com
In reply to: Andrew Sullivan (#17)
Re: Quad Xeon vs. Dual Itanium

On Fri, Feb 13, 2004 at 11:24:05AM -0500, Andrew Sullivan wrote:

On Fri, Feb 13, 2004 at 10:44:55PM +0800, Lincoln Yeoh wrote:

Hmm, do you mean 64 bit postgresql on Solaris-Sparc isn't significantly
better performance-wise than 32 bit postgresql on Solaris-Sparc?

Not in any test I've ever run. I haven't tried again lately, mind
you. And I never had the Sun compiler, which, for all I know, does a
better job with 64 bit binaries than gcc.

As a general rule 64 bit binaries tend to run slower than 32 bit
binaries on any given architecture. The 32 bit binaries still get to
use 64 bit data values if they feel so inclined, so that's nothing
special. But all the pointers in the 64 bit build are twice the size,
so the memory footprint is larger, it makes less efficient use of
cache, it takes longer to read data from main memory and so on. If you
need direct access to a lot of memory, and your application is
structured to use it, then a 64 bit model can be a big win, but
usually not otherwise.

Forte C is a lot better than gcc for Solaris/SPARC (unsurprisingly)
but 32 bit builds still seem a little faster than 64 bit builds. There
are some benchmarks I looked at recently that show that, but I don't
seem to be able to find the article right now.

Cheers,
Steve

#20Bruce Momjian
bruce@momjian.us
In reply to: scott.marlowe (#18)
Re: Quad Xeon vs. Dual Itanium

scott.marlowe wrote:

On Fri, 13 Feb 2004, Andrew Sullivan wrote:

On Mon, Feb 09, 2004 at 12:46:58PM -0500, Christopher Browne wrote:

Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.

But actually, there are problems with using postgres as a 64 bit
application on Solaris. It works, and it's reliable, but I've never
seen any evidence that it helps anything (and I've looked plenty).

I wonder if this would hold true when running 64 bit linux on Sparc
hardware... Could well be that the reason 64 bit is no faster than 32 bit
is that Solaris is just not a very fast platform for Postgresql, so any
improvements running 64 bit pgsql are lost in the Solaris/Postgresql mix.

64-bits isn't faster than 32, and can be slower because of the longer
pointer length, decreasing cache performance. The major advantage to
64-bits is accessing more the 4gb of RAM.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#21Andrew Sullivan
ajs@crankycanuck.ca
In reply to: Bruce Momjian (#20)
#22Chris Browne
cbbrowne@acm.org
In reply to: scott.marlowe (#18)
#23Mark Kirkwood
mark.kirkwood@catalyst.net.nz
In reply to: Andrew Sullivan (#15)
#24Dann Corbit
DCorbit@connx.com
In reply to: Mark Kirkwood (#23)
#25Chris Browne
cbbrowne@acm.org
In reply to: Dann Corbit (#24)
#26Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mark Kirkwood (#23)
#27Mark Kirkwood
mark.kirkwood@catalyst.net.nz
In reply to: Dann Corbit (#24)
#28Mark Kirkwood
mark.kirkwood@catalyst.net.nz
In reply to: Mark Kirkwood (#27)
#29Andrew Sullivan
ajs@crankycanuck.ca
In reply to: Dann Corbit (#24)
#30Andrew Sullivan
ajs@crankycanuck.ca
In reply to: Tom Lane (#26)
#31Dann Corbit
DCorbit@connx.com
In reply to: Andrew Sullivan (#30)
#32Chris Browne
cbbrowne@acm.org
In reply to: Dann Corbit (#31)
#33Lincoln Yeoh
lyeoh@pop.jaring.my
In reply to: Dann Corbit (#31)
#34Jan Wieck
JanWieck@Yahoo.com
In reply to: Tom Lane (#26)