Mail Archives: djgpp/1997/09/24/08:15:53
In article <Pine DOT SUN DOT 3 DOT 91 DOT 970922141858 DOT 12051B-100000 AT is>, Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> writes
>> I heard a rumour somewhere (some internet page) that in a 32-bit compiler,
>> you should always use 32-bit ints instead of shorts because they don't have
>> to be "played with" so much in the registers (sorry, I didn't know how to
>> say that). Is this true and would it really give that much of a speed gain?
>
>It is true that for some architectures, ints are faster than shorts.
>However, when portability is an issue, IMHO, use shorts and don't look
>back. In most programs you won't see the difference, since the optimizer
>usually does a good job. The only place where you should use ints is
>in tight loops, where the speed really matters; but an index in a loop
>can always be declared int (if 16 bits are enough) without hampering
>portability.
This is not very good advice for a number of reasons.
Theres the obvious one that some processors do handle them slower.
Less obvious is that some processors (x86) actually generate longer
opcodes and others (MIPS) generate extra code to sign extend shorts. The
net result is for a 2 byte data saving you pay much more in extra code
and potentially reduced cache effectiveness.
gcc will optimise away most of this, even so we are seeing measurable
speedups from switching shorts->ints in R3000 code.
The only reasons to use shorts are: saving memory in arrays,interfacing
to hardware.
The portability argument is nonsense apart from the rare case where
extra precision breaks code: I would call that code broken in the first
place ;)
---
Paul Shirley: my email address is 'obvious'ly anti-spammed
- Raw text -