Обсуждение: 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
calleda billion times and it    * does an C pointer subtraction (i.e., "x - y" -> array index of x    * relative to y,
whichis calculated using division by struct size).
^^^^^^^^^^^^^^^^^^^^^^^^   * Integer ".div" hits you for 35 cycles, as opposed to a 1-cycle    * "sra" ... this hack
cut10% 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

> * ... 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

"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

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

> 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,
Pennsylvania19026
 

> > * ... 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,
Pennsylvania19026
 

> "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,
Pennsylvania19026