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: