Skip site navigation (1) Skip section navigation (2)

Re: New to PostgreSQL, performance considerations

From: Ron <rjpeace(at)earthlink(dot)net>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: New to PostgreSQL, performance considerations
Date: 2006-12-15 15:04:58
Message-ID: E1GvEcS-0005rM-ME@elasmtp-spurfowl.atl.sa.earthlink.net (view raw or flat)
Thread:
Lists: pgsql-performance
At 09:23 AM 12/15/2006, Merlin Moncure wrote:
>On 12/15/06, Ron <rjpeace(at)earthlink(dot)net> wrote:
>>
>>It seems unusual that code generation options which give access to
>>more registers would ever result in slower code...
>
>The slower is probably due to the unroll loops switch which can 
>actually hurt code due to the larger footprint (less cache coherency).

I have seen that effect as well occasionally in the last few decades 
;-)  OTOH, suspicion is not _proof_; and I've seen other 
"optimizations" turn out to be "pessimizations" over the years as well.


>The extra registers are not all that important because of pipelining 
>and other hardware tricks.

No.  Whoever told you this or gave you such an impression was 
mistaken.  There are many instances of x86 compatible code that get 
30-40% speedups just because they get access to 16 rather than 8 GPRs 
when recompiled for x84-64.


>Pretty much all the old assembly strategies such as forcing local 
>variables to registers are basically obsolete...especially with 
>regards to integer math.

Again, not true.  OTOH, humans are unlikely at this point to be able 
to duplicate the accuracy of the compiler's register coloring 
algorithms.  Especially on x86 compatibles.  (The flip side is that 
_expert_ humans can often put the quirky register set and instruction 
pipelines of x86 compatibles to more effective use for a specific 
chunk of code than even the best compilers can.)


>As I said before, modern CPUs are essentially RISC engines with a 
>CISC preprocessing engine laid in top.

I'm sure you meant modern =x86 compatible= CPUs are essentially RISC 
engines with a CISC engine on top.  Just as "all the world's not a 
VAX", "all CPUs are not x86 compatibles".  Forgetting this has 
occasionally cost folks I know...


>Things are much more complicated than they were in the old days 
>where you could count instructions for the assembly optimization process.

Those were the =very= old days in computer time...


>I suspect that there is little or no differnece between the 
>-march=686 and the various specifc archicectures.

There should be.  The FSF compiler folks (and the rest of the 
industry compiler folks for that matter) are far from stupid.  They 
are not just adding compiler switches because they randomly feel like it.

Evidence suggests that the most recent CPUs are in need of =more= 
arch specific TLC compared to their ancestors, and that this trend is 
not only going to continue, it is going to accelerate.


>Did anybody think to look at the binaries and look for the amount of 
>differences?  I bet you code compiled for march=opteron will just 
>fine on a pentium 2 if compiled
>for 32 bit.
Sucker bet given that the whole point of a 32b x86 compatible is to 
be able to run code on any I32 ISA. CPU.
OTOH, I bet that code optimized for best performance on a P2 is not 
getting best performance on a P4.  Or vice versa. ;-)

The big arch specific differences in Kx's are in 64b mode.  Not 32b


Ron Peacetree. 


In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2006-12-15 15:45:56
Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2
Previous:From: Tom LaneDate: 2006-12-15 14:56:57
Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group