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