I'm going to remove subj...

buf_internals.h:

    /*
     * I padded this structure to a power of 2 (PADDED_SBUFDESC_SIZE)
     * because BufferDescriptorGetBuffer is called a billion times and it
     * does an C pointer subtraction (i.e., "x - y" -> array index of x
     * relative to y, which is calculated using division by struct size).
                                                ^^^^^^^^^^^^^^^^^^^^^^^^
     * Integer ".div" hits you for 35 cycles, as opposed to a 1-cycle
     * "sra" ... this hack cut 10% off of the time to create the Wisconsin
     * database! It eats up more shared memory, of course, but we're
     * (allegedly) going to make some of these types bigger soon anyway...
     * -pma 1/2/93
     */

This is not true now:

#define BufferDescriptorGetBuffer(bdesc) ((bdesc)->buf_id + 1)

Comments ?...

Vadim

Mon, 30 Nov 1998 12:07:37 +0700
Vadim Mikheev <vadim@krs.ru>
sbufdesc' padding...
> * ... this hack cut 10% off of the time to create the Wisconsin
> * database! It eats up more shared memory, of course, but we're
> * (allegedly) going to make some of these types bigger soon 
> * anyway... -pma 1/2/93
> This is not true now:
> #define BufferDescriptorGetBuffer(bdesc) ((bdesc)->buf_id + 1)
> Comments ?...

Does that mean that we have re-introduced the slower allocation
technique sometime since 1993? 10% speed improvement for some operations
seems interesting...

                    - Tom

Mon, 30 Nov 1998 16:28:08 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] sbufdesc' padding...
"Thomas G. Lockhart" wrote:
> 
> > * ... this hack cut 10% off of the time to create the Wisconsin
> > * database! It eats up more shared memory, of course, but we're
> > * (allegedly) going to make some of these types bigger soon
> > * anyway... -pma 1/2/93
> > This is not true now:
> > #define BufferDescriptorGetBuffer(bdesc) ((bdesc)->buf_id + 1)
> > Comments ?...
> 
> Does that mean that we have re-introduced the slower allocation
> technique sometime since 1993? 10% speed improvement for some operations
> seems interesting...

Why slower allocation? BufferDescriptorGetBuffer used sizeof sbufdesc
to get buffer number in 1993. Jolly/Andrew put buffer number
(buf_id) into sbufdesc itself and so made sbufdesc padding
useless.

Vadim

Tue, 01 Dec 1998 09:50:44 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] sbufdesc' padding...
Vadim Mikheev wrote:
> 
> Why slower allocation? BufferDescriptorGetBuffer used sizeof sbufdesc
> to get buffer number in 1993. Jolly/Andrew put buffer number
> (buf_id) into sbufdesc itself and so made sbufdesc padding
> useless.

Ah. I had only read the comment without understanding the current
implementation...

                      - Tom

Tue, 01 Dec 1998 06:00:43 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] sbufdesc' padding...
> I'm going to remove subj...
> 
> buf_internals.h:
> 
>     /*
>      * I padded this structure to a power of 2 (PADDED_SBUFDESC_SIZE)
>      * because BufferDescriptorGetBuffer is called a billion times and it
>      * does an C pointer subtraction (i.e., "x - y" -> array index of x
>      * relative to y, which is calculated using division by struct size).
>                                                 ^^^^^^^^^^^^^^^^^^^^^^^^
>      * Integer ".div" hits you for 35 cycles, as opposed to a 1-cycle
>      * "sra" ... this hack cut 10% off of the time to create the Wisconsin
>      * database! It eats up more shared memory, of course, but we're
>      * (allegedly) going to make some of these types bigger soon anyway...
>      * -pma 1/2/93
>      */
> 
> This is not true now:
> 
> #define BufferDescriptorGetBuffer(bdesc) ((bdesc)->buf_id + 1)
> 
> Comments ?...
> 
> Vadim
> 
> 

You can remove the comment about size-of-2.  It currently pads to a
fixed size of 128, because the old code didn't work.  We now do:

    /*
     * please, don't take the sizeof() this member and use it for
     * something important
     */
     
    char        sb_relname[NAMEDATALEN +        /* name of reln */
                PADDED_SBUFDESC_SIZE - sizeof(struct sbufdesc_unpadded)];

which is much stranger, but works 100% of the time.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 1 Dec 1998 20:26:34 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] sbufdesc' padding...
> > * ... this hack cut 10% off of the time to create the Wisconsin
> > * database! It eats up more shared memory, of course, but we're
> > * (allegedly) going to make some of these types bigger soon 
> > * anyway... -pma 1/2/93
> > This is not true now:
> > #define BufferDescriptorGetBuffer(bdesc) ((bdesc)->buf_id + 1)
> > Comments ?...
> 
> Does that mean that we have re-introduced the slower allocation
> technique sometime since 1993? 10% speed improvement for some operations
> seems interesting...
> 

No, just the way of computing the padding has changed.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 1 Dec 1998 20:30:19 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] sbufdesc' padding...
> "Thomas G. Lockhart" wrote:
> > 
> > > * ... this hack cut 10% off of the time to create the Wisconsin
> > > * database! It eats up more shared memory, of course, but we're
> > > * (allegedly) going to make some of these types bigger soon
> > > * anyway... -pma 1/2/93
> > > This is not true now:
> > > #define BufferDescriptorGetBuffer(bdesc) ((bdesc)->buf_id + 1)
> > > Comments ?...
> > 
> > Does that mean that we have re-introduced the slower allocation
> > technique sometime since 1993? 10% speed improvement for some operations
> > seems interesting...
> 
> Why slower allocation? BufferDescriptorGetBuffer used sizeof sbufdesc
> to get buffer number in 1993. Jolly/Andrew put buffer number
> (buf_id) into sbufdesc itself and so made sbufdesc padding
> useless.

Oh, then you can remove the padding.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 1 Dec 1998 20:39:53 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] sbufdesc' padding...