Re: Derived data types vs computation time

From: Richard E Maine (nospam_at_see.signature)
Date: 10/05/04 

Date: 05 Oct 2004 10:10:28 -0700

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Jan Vorbrüggen wrote:

> > - Alignment: depending on the order of components and the specification,
> > or not, of SEQUENCE in the definition, the compiler may or may be forced
> > to generate slow code for accessing some or all components. General
> > rule: order by size, larger items first.
>
> > - A second alignment issue might occur when the total size does not fit
> > well with the alignment required by the hardware - this can happen in
> > arrays of structures when, for instance, the second array element is
> > mis-aligned because of the size of the first element. Padding to some
> > suitable total size can help here. Also, adverse interactions with
> > cache line sizes or replacement policies can occur.
>
> Aren't they padded? Since the problems with COMMON not padding
> data, I thought people had learned by now. All other languages
> that I know pad structures to align data.

They "ought" to be padded appropriately. If they aren't, bitch at the
compiler vendor. Note that compilers are almost never "forced" to
do this poorly; if they do so, that is a poor implementation and is
*NOT* specified by the standard.

For non-sequence types, the standard has no reason at all for the compiler
not to re-order and/or pad as needed for decent performance. If the
compiler doesn't do so, bitch loudly.

Even for most sequence types, the standard does not really mandate
the order or packing of the components. The only requirement is that
it be consistent so that when you put the same type definition in
multiple scoping units, you'll get the same layout. Although the
standard does mention the component storage sequence, you'll find that
there isn't actually any way for a standard-conforming program to
tell.

The one where a standard-conforming program can tell are numeric
sequence and character sequence types. Those categories are very
restricted. For a numeric sequence type, everything has to boil down
to default real, default integer, default logical, default comple, or
double precision. If it weren't for the darned double precision,
there would be no consequent alignment issues at all.

I can see it as reasonable that a compiler might not want to
special-case numeric and character sequence types (and I don't think
any compilers do). So I see it as at least reasonable that the
requirements on numeric and character sequence would be generalized to
all sequence types. A bit unfortunate, and not really forced by the
standard, but likely to be at least common.

But for nonsequence types, there is just no "excuse" for alignment
problems. If the compiler gives you poor performance because of
alignment in nonsequence types, bitch loudly. If the vendor uses
the excuse that they thought it a good tradeoff to sacrifice performance
to save space, and if they don't even provide a switch to change this,
then consider whether the vendor's priorities match yours.

(Locality of reference is a separate matter, discussed in other posts
in the thread). 

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Relevant Pages

  • (part 25) Han from China answers your C questions
    ... be able to 'explain' it in terms of the famous C standard. ... sequence points, in some indeterminate order. ... increment p. ... And it allows the compiler to generate code that will evaluate ...
    (comp.lang.c)
  • Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
    ... compiler writer that pulls such a dirty trick, but the C standard really ... The compiler is not permitted to move volatile references ... across a sequence point. ...
    (Linux-Kernel)
  • Re: why is it so ?
    ... >>>to visualise how the sequence point makes the second statement ... So the standard requires this to be undefined behavior. ... > between evaluating `++i' and starting to execute `f', ... What if the compiler can predict the ...
    (comp.lang.c)
  • Re: Function order.
    ... particular ordering (sequence of operations). ... the compiler actually used. ... Schedule a copy the value found into the location found ... Here we "schedule an increment and produce the previous value", ...
    (comp.lang.c)
  • Re: Fixpoint for LZH
    ... > might (with a particular compiler) indeed get a fixed point. ... "0123456789", I got a strictly increasing sequence of sizes, as follows: ... for example, in that Stuffit for Macs if memory serves right, never ...
    (sci.math)