Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!im4u!milano!mcc-pp!tiemann
From: tiemann@mcc-pp.UUCP (Michael Tiemann)
Newsgroups: net.lang.c
Subject: Re: Re: structure alignment question
Message-ID: <1705@mcc-pp.UUCP>
Date: Sat, 20-Sep-86 11:51:16 EDT
Article-I.D.: mcc-pp.1705
Posted: Sat Sep 20 11:51:16 1986
Date-Received: Sat, 20-Sep-86 20:59:49 EDT
References: <101@hcx1.UUCP> <7363@sun.uucp> <696@mips.UUCP> <7447@sun.uucp>
Organization: MCC, Austin, TX
Lines: 44
Summary: Lets talk performance for a minute

In article <7447@sun.uucp>, guy@sun.UUCP writes:
> > >Yes, at least in the 4.3BSD version of the compiler, ....
> > Actually, some might be aligned to 8-byte boundaries, on machines that
> > like doubles on such boundaries.
>  [... text deleted ...]
> > Note that for speed, it is usually best to align data items on the most
> > restrictive boundaries, even if a specific machine implementation doesn't
> > really require it.  Lots of machines let words be on arbitrary boundaries,
> > but you pay for it in speed, if not now, then later, as CPUs come
> > to have wider data paths.
> 
> Yes, the VAX PCC aligns "int"s and "long"s on 4-byte boundaries, even though
> the machine can fetch longwords off such a boundary; there is, I'd bet, a
> performance penalty for such a fetch.
> -- 
> 	Guy Harris
> 	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
> 	guy@sun.com (or guy@sun.arpa)

I was waiting for SOMEBODY to talk performace for once. The last 68000
compiler I used aligned strings on WORD boundaries. This would cost
one byte per string, half the time. But there was a big speed payoff:
I could do word operations in my strnlen, strncmp, strncpy, and whatever
other string processing functions I happened to write. All this code ported
to a Sun-3 no (apparent) problem, but crashed on a Sun-2, because the SUN
compiler allocated strings in a totally stingy 1-byte alignment.
So now, all this "fast" code actually runs slower than a "dumb" byte-copy
model, because the 68020 faults itself to death reading in 32-bit words
on odd boundaries, and doesn't run at all on a Sun-2 because the 68010
can read odd words.

Now I *know* you're not *supposed* to do things like that, but often
high performance comes not by reading some 20 year old manual, but
by analyzing the machine at hand, and trying to more than just
accomodate it. Tune those compilers, comment those machine dependencies,
and watch the code fly!

How many other compilers are so parsimonious? Is this something we should
stand for, or are we trying to get away from performance in the name
of cleanliness? I suppose that this letter was a bit of a flame, sorry.
Y'all are welcome to flame me back,

Michael
tiemann@mcc.com