Re: Warm-cache prefetching - Mailing list pgsql-hackers

From Kenneth Marshall
Subject Re: Warm-cache prefetching
Date
Msg-id 20051209152600.GA18523@it.is.rice.edu
Whole thread Raw
In response to Re: Warm-cache prefetching  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
The main benefit of pre-fetching optimization is to allow just-
in-time data delivery to the processor. There are numerous papers
illustrating the dramatic increase in data throughput by using
datastructures designed to take advantage of prefetching. Factors
of 3-7 can be realized and this can greatly increase database
performance. The first step needed to take advantage of the ability
of pre-fetching to reduce memory latency is to design the index
page layout with an internal blocking of the cache-line size.
Then issue pre-fetch instructions for the memory you are going
to need to process the index page far enough in advance to allow
it to be in a cache-line by the time it is needed. 

Ken

On Fri, Dec 09, 2005 at 09:43:33AM -0500, Bruce Momjian wrote:
> 
> Do these optimizations have any affect on database software?  I know
> call overhead shows up as a performance bottleneck, but do these others
> optimizations also measurably improve performance?
> 
> ---------------------------------------------------------------------------
> 
> Simon Riggs wrote:
> > This technique and others are discussed in detail in the Intel
> > Optimization Manual:
> >
http://apps.intel.com/scripts-util/download.asp?url=/design/PentiumII/manuals/24512701.pdf&title=Intel%AE+Architecture+Optimization+Reference+Manual&fullpg=3&site=Developer
> > 
> > Similar manual exists for AMD and other architectures.
> > 
> > On Thu, 2005-12-08 at 23:07 -0500, Qingqing Zhou wrote:
> > > I write a program try to simulate it, but I am not good at micro
> > > optimization, and I just get a very weak but kind-of-stable improvement. I
> > > wonder if any people here are interested to take a look.
> > 
> > You may be trying to use the memory too early. Prefetched memory takes
> > time to arrive in cache, so you may need to issue prefetch calls for N
> > +2, N+3 etc rather than simply N+1.
> > 
> > p.6-11 covers this.
> > 
> > There's a lot of papers around coming up with interesting sounding
> > techniques. AFAICS, all they've done is read the optimization guide and
> > tried to apply that wisdom, so it seems a good idea to go back to the
> > source.
> > 
> > I think many of these techniques are generic across architectures, so
> > there is much to be done in this area, IMHO. Though we must respect
> > portability and confirm any tuning through testing.
> > 
> > Best Regards, Simon Riggs
> > 
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
> > 
> 
> -- 
>   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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Backslashes in string literals
Next
From: Kai
Date:
Subject: Re: int to inet conversion [or Re: inet to bigint?]