Re: New to PostgreSQL, performance considerations - Mailing list pgsql-performance

From Daniel van Ham Colchete
Subject Re: New to PostgreSQL, performance considerations
Date
Msg-id 8a0c7af10612110305u305124b2v3d63491b5f57a86b@mail.gmail.com
Whole thread Raw
In response to Re: New to PostgreSQL, performance considerations  (Michael Stone <mstone+postgres@mathom.us>)
Responses Re: New to PostgreSQL, performance considerations
Re: New to PostgreSQL, performance considerations
Re: New to PostgreSQL, performance considerations
List pgsql-performance
Mike,

unfortunally I don't have any benchmarks right now. Doing something
like this with the same machine would be a 2-day work (at least).
Installing a Gentoo and putting it to run well is not a quick task
(although is easy).

But, trust me on this one. It's worth it. Think of this: PostgreSQL
and GNU LibC use a lot of complex algorithms: btree, hashes,
checksums, strings functions, etc... And you have a lot of ways to
compile it into binary code. Now you have Pentium4's vectorization
that allow you to run plenty of instructions in paralell, but AMD
doesn't have this. Intel also have SSE2 that makes double-precision
floatpoint operations a lot faster, AMD also doesn't have this (at
least on 32bits). Now imagine that you're RedHat and that you have to
deliver one CD to AMD and Intel servers. That means you can't use any
AMD-specific or Intel-specific tecnology at the binary level.

Things can get worse. If you take a look at GCC's code (at
gcc/config/i386/i386.c), you'll see that GCC knows what runs faster on
each processor. Let-me give an example with the FDIV and FSQRT
instructions:

ARCH - FDIV - FSQRT (costs relative to an ADD)
i386: 88 - 122
i486: 73 - 83
pentium: 39 - 70
k6: 56 - 56
Athlon: 24 - 35
K8: 19 - 35
Pentium4: 43 - 43
Nocona: 40 - 44

Imagine that you are GCC and that you have two options in front of
you: you can use FSQRT or FDIV plus 20 ADD/SUB. If you are on an
Pentium situation you should use the second option. But on a Pentium4
or on a Athlon you should choose for the first one. This was only an
example, nowadays you would have to choose between: 387, 3dNow,
3dNow+, SSE, SSE2, ...

With this info, GCC knows how to choose the best ways to doing things
to each processor. When you are compiling to an generic i586 (like
Fedora and RedHat), them you are using pentium's timings.

An example that I know of: it's impossible to run my software at a
high demanding customer without compiling it to the it's processor (I
make 5 compilations on every release). Using Intel's Compiler for
Intel's processors makes things even faster, but it is not free and
the "how fast" part really depends on your application is coded.

With 64bits processors, AMD and Intel restarted the process and
everyone has SSE2 (but not SSE3). Even so, the timings are also very
diferent.

Best regards
Daniel

On 12/11/06, Michael Stone <mstone+postgres@mathom.us> wrote:
> On Sun, Dec 10, 2006 at 11:02:44PM -0200, Daniel van Ham Colchete wrote:
> >I'm using Gentoo Linux, so all my libraries (including glibc that is
> >very important to PostgreSQL), and all my softwares are compiled with
> >good CFLAG options to my processor ("-O2 march=athlon-xp (...)"). My
> >Linux is not an Intel-AMD binary compatible turtle like
> >Fedora/RedHat/SUSE/... It's really important to have your GLIBC
> >compiled for your processor.  It is essencial for performance.
>
> Please, point to the benchmarks that demonstrate this for a postgres
> application.
>
> Mike Stone
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

pgsql-performance by date:

Previous
From: Dave Cramer
Date:
Subject: Re: New to PostgreSQL, performance considerations
Next
From: "Daniel van Ham Colchete"
Date:
Subject: Re: New to PostgreSQL, performance considerations