Sun performance - Major discovery!

From: Jeff <threshar(at)torgo(dot)978(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Sun performance - Major discovery!
Date: 2003-10-08 12:36:56
Message-ID: Pine.BSF.4.44.0310080817500.62574-100000@torgo.978.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Well, as you guys know I've been tinkering with sun-vs-linux postgres for
a while trying to come up with reasons for the HUGE performance
differences. We've all had our anecdotal thoughts (fork sucks, ipc sucks,
ufs sucks, etc) and I've had a breakthrough.

Knowing that GCC only produces good code on x86 (and powerpc with apple's
mods, but it is doubtful that is as good as ibm's power compiler) I
decided to try out Sunsoft CC. I'd heard from more than one person/place
that gcc makes abysmal sparc code. Given that the performance profiles
for both the linux and sun boxes showed the same functions taking up most
of the time I thought I'd see what a difference sunsoft could give me.

So - hardware -
Sun E450 4x400mhz ultrasparc IIi, 4GB ram, scsi soemthing disk. (not
raid) solaris 2.6

Linux - 2xP3 500mhz, 2GB, scsi disk of some flavor (not raid) linux 2.2.17
(old I know!)

So here's the results using my load tester (single connection per beater,
repeats the query 1000 times with different input each time (we'll get
~20k rows back), the query is a common query around here.

I discounted the first run of the test as caches populated.

Linux - 1x - 35 seconds, 20x - 180 seconds

Sun - gcc - 1x 60 seconds 20x 245 seconds
Sun - sunsoft defaults - 1x 52 seonds 20x [similar to gcc most likely]
Sun - sunsoft -fast - 1x 28 seconds 20x 164 seconds

As you math guru's can probably deduce - that is a rather large
improvement. And by rather large I mean hugely significant. With results
like this, I think it warrants mentioning in the FAQ_Solaris, and probably
the performance guide.

Connecting will always be a bit slower. But I think most people realize
that connecting to a db is not cheap.

I think update/etc will cause more locking, but I think IO will become the
bottle neck much sooner than lock/unlock will. (This is mostly anecdotal
given how fast solaris can lock/unlock a semaphore and how much IO I know
I have)

Oh yes, with was with 7.3.4 and sunsoft cc Sun WorkShop 6 update 1 C
5.2 2000/09/11 (which is old, perhaps newer ones make even better code?)

I'm not sure of PG's policy of non-gcc things in configure, but perhaps if
we detect sunsoft we toss in the -fast flag and maybe make it the
preferred one on sun? [btw, it compiled with no changes but it did spew
out tons of warnings]

comments?

--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.jefftrout.com/
http://www.stuarthamm.net/

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2003-10-08 12:59:20 Re: new initdb.c available
Previous Message Zeugswetter Andreas SB SD 2003-10-08 11:55:58 Re: new initdb.c available

Browse pgsql-performance by date

  From Date Subject
Next Message Andriy Tkachuk 2003-10-08 13:16:52 IMMUTABLE function's flag do not work: 7.3.4, plpgsql
Previous Message Tom Lane 2003-10-08 04:15:57 Re: TPC-R benchmarks