Re: ridiculous amounts of padding

[Alfred Perlstein <bright at hotjobs dot com>]

On Tue, 12 Jan 1999, Zack Weinberg wrote:

> 
> Since everyone is discussing string functions...
> 
> Code of the form
> 
> puts("line 1");
> puts("line 2");
> puts("line 3");
> ...
> puts("line 96");
> 
> is compiled (at least on x86) into a series of calls and a bunch of string
> table entries.  Fine.  The problem is, in the string table we emit
> .align 32 directives between all the strings.  This wastes quite a lot of
> space.  It seems that this is because of a general policy of aligning
> .rodata items on 32 byte boundaries - I assume for cache reasons.  When we
> know, as in this case, that all the strings will be accessed in succession,
> I think we should be able to remove the padding.  (Kaveh's suggested
> collapse-to-one-call optimization would be good too.)
> 
> I would rewrite it
> puts(	"line 1\n"
> 	"line 2\n"
> 	...
> 	"line 96");
> 
> but it has to compile on K+R compilers.

note: frag = sizeof(string) % cacheblock

ok,

I'm wondering why something isn't done to align strings in a smarter way:

by using the cache line size, strings could be sorted and then combined to
minimize cache fragmentation.

if a string is 33 bytes long and a cache line is 32 bytes I don't consider
it _THAT_(*) signifigant if the cache miss happens on the first character,
or the last.

if you could then keep track of frags, you could try to pack strings much
better and match them to set them next to strings that complement the frag
size to minimize data size.

wieghting the sorting could also be done on reference (is this already
done?) so that instead of requiring a new cache block for each string, you
hope that the string packed beforehand would be accessed and therefor
bring in the initial frag from the previous string.

(*) this is a bad example though, because unless locality of reference is
taken into account and the assumption that the beginning of a string is
probably accessed more, this could cause performance issues, but if the
previous string has been accessed this can cause a better cache
utilization.

this is on the assumption that the reason for the 32 byte align is because
of cache, if it's because of alignment speed, i hardly see the point of
using alignment on strings as they are accessed mosty in a byte
granularity.

please excuse if most of this has been done, but if someone thinks this is
a totally incorrect methodology, or that i'm thinking with totally
incorrect asssumptions, please explain, as it makes sense to me.

-Alfred

> 
> zw
>