Thread View: comp.std.c++
2 messages
2 total messages
Started by dhoyt
Tue, 25 Sep 1990 19:59
Re: Packing, Ordering, and Rearranging
Author: dhoyt
Date: Tue, 25 Sep 1990 19:59
Date: Tue, 25 Sep 1990 19:59
49 lines
2837 bytes
2837 bytes
In article <204@xstor.UUCP>, iverson@xstor.UUCP (Tim Iverson) writes...
>While your statement is true, it is very misleading. It is due to the lack
>of a standard when exercising such precise control that makes programs
>non-portable, not the existence of such code in a program. If you'll pause
>to reflect a momoment, you'll realize that every area in a language that
>allows the vender to make a decision on how to bridge a gap between cause
>and effect results in a potential portability problem.
No, even truly 'portable' extentions cause portablity problems. Take the
Cray for instance. It has no 'char' datatype and can address only a word
(bytes do not exist). To address a character, the low order (32 on a Cray 2)
bits of an address point to the word of the character and the top three bits
(63:61 - ignored by the hardware) are the character offset from the beginning
of the word.
As you might guess all character resultion is done is software.
if ( c[n] == 'a' )
will take a lot more cycles than a 1.0 / f. As a result any non-aligned
manipulations are very, very slow.
Now take, the average brainless programmer that micro-'optimizes' his or her
code to 'save' memory in structures. They 'know' that with
struct a {
char one[ 2 ];
int two;
};
the size if the structure is
sizeof( struct a ) == 2 + sizeof( int )
And takes advantage of this packing. Now Cray has two options. Break the
code or produce very, very slow code. If the standard requires it to be
packed, i.e. the code is defacto portable, it still is a portablity nightmare;
Cray is forced to produce very slow code. Blech.
The micro programmer that cries, "I never thought it was going to be ported
to a Cray!" Just hasn't hasn't worked very long. Also it is interesting to
note that this 'optimization' will actually slow any machine with a 32 or 64
bit bus (all mainframes, mini's and most workstations) by causing all sorts of
non-aligned references and writes.
The ONLY time that there is a real need for the programmer to understand
the underlying structure layout is when the programmer is dealing device
drivers and whatnot. The need to save memory (aka 640k) is better addressed
by a make-structures-very-tight switch on the compiler.
david paul hoyt | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet
Re: Packing, Ordering, and Rearranging
Author: Tim Iverson
Date: Fri, 28 Sep 1990 23:12
Date: Fri, 28 Sep 1990 23:12
28 lines
1701 bytes
1701 bytes
In article <2275@ux.acs.umn.edu> dhoyt@vw.acs.umn.edu writes: >In article <204@xstor.UUCP>, iverson@xstor.UUCP (Tim Iverson) writes... >>[no std => not portable (usability-wise)] > >[std => not portable (speed-wise)] > > The ONLY time that there is a real need for the programmer to understand >the underlying structure layout is when the programmer is dealing device >drivers and whatnot. The need to save memory (aka 640k) is better addressed >by a make-structures-very-tight switch on the compiler. Actually, 90% of what I write has to interface with with the real world, so I consider the "works" option to be far more important than the "speed" option; it's highly annoying to have to tune a program's structures every time I switch compilers, simply because every vender tries to be different. For strange machines that have such costly restrictions on alignment, such as the Cray, I would mind less having to do a little work to bring the speed up than I would mind having to work to make it go at all (i.e. *first* turn the key, *then* step on the gas). Tell me, which is more important to your management: "it works", or "when it works, it'll be fast"? >david paul hoyt | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet - Tim Iverson iverson!uunet!xstor
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads