Thread: 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