small bitmap.c patch [off-topic]
Michael Sweet
mike at easysw.com
Mon Sep 24 11:32:21 GMT 2001
"Christopher R. Hertel" wrote:
> ...
> An interesting opinion. While I agree that allowing reordering removes
> some functionality from the lanuage it also acknowledges architectural
> differences between machines.
Reordering almost never improves performance; it has the potential
for allowing the compiler to choose a more compact representation
(to use less memory) which *may* improve performance, however
unless the compiler is really smart (i.e. as smart or smarter than
the programmer - than a *good* programmer, that is :) it cannot make
value judgements such as "put the most often referenced member first".
Those kinds of optimizations require a broader knowledge of the
code that the code along may not be able to provide (i.e. libraries
vs. applications that use the libraries), and sometimes it is
better for a structure to be a power of 2 in size so that random
access to the array is faster (shifts instead of multiplies)
Often the most space-efficient representation is not the most
time-efficient.
> > There
> > will always be size and alignment issues which the spec has to
> > acknowledge, but to add *reordering* to the list of things a
> > compiler can do is just dangerous.
>
> Only if the programmer makes assumptions about the structure ordering. :)
This is a meaningless argument. Code exists today, has existed, and
will continue to exist that makes this assumption, which is why
most (all?) compilers do not perform structure member reordering.
> > The following structure,
> > according to the current specs, could be reordered causing
> > problems in the compiled program:
> >
> > struct
> > {
> > int foo;
> > char bar[1];
> > }
>
> This is exactly the kind of structure that caused problems when I
> compiled the code on my SGI Indy at work.
Hmm, with what compilers? We regularly use this type of structure
under IRIX in o32, n32, and 64-bit modes, and under Linux, AIX,
Tru64, Solaris, HP-UX, *BSD, Windows, etc. The code is portable
on current compilers and systems, and will likely stay so as long
as compiler writers retain some amount of sanity.
> ...
> The problems with the above are:
> 1) Alignment might cause some shifting of the actual location of q. It
> might be necessary to round up the value passed to malloc() to the
> next highest word multiple.
Nope. sizeof(struct) will return the padded size of the structure,
such that 2*sizeof(struct) will provide enough memory (and alignment)
for 2 structs. Otherwise allocating an array or 2 structures with:
p = malloc(sizeof(struct) * count);
would not work... :)
> 2) The pointer to the data is still not part of the structure, and adding
> that pointer adds another sizeof( void * ) bytes to the structure size.
The space use isn't the worst part - every access of the pointer
requires a memory load, whereas the member array address is
accessable via pointer arithmetic...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com
More information about the samba-technical
mailing list