Re: Warm-cache prefetching

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(at)candle(dot)pha(dot)pa(dot)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