Re: Why in stdint.h have both least and fast integer types?
From: Gordon Burditt (gordonb.m2fjo_at_burditt.org)
Date: 12/01/04
- Next message: Chris Croughton: "Re: More bitwise woes"
- Previous message: Martin Ambuhl: "Re: strtok but keep the separator"
- In reply to: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Next in thread: Charlie Gordon: "Re: Why in stdint.h have both least and fast integer types?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 1 Dec 2004 18:50:00 GMT
>>>>> The stdint.h header definition mentions five integer categories,
>>>>>
>>>>> 1) exact width, eg., int32_t
>>>>> 2) at least as wide as, eg., int_least32_t
>>>>> 3) as fast as possible but at least as wide as, eg., int_fast32_t
>>>>> 4) integer capable of holding a pointer, intptr_t
>>>>> 5) widest integer in the implementation, intmax_t
>>>>>
>>>>> Is there a valid motivation for having both int_least and int_fast?
>>>>
>>>> Of course. If 16 bit integers are slow in your hardware, and 32 bit
>>>> integers are fast, then you would want int_least16_t to be 16 bit, and
>>>> int_fast16_t to be 32 bit. That covers about every computer that you
>>>> can
>>>> buy in a shop.
>>>
>>>Interesting example but what advantage does int_least16_t really give? If
>>
>> Space savings.
>
>For scalars?
Yes. The compiler can't necessarily tell that there aren't malloc'd
arrays of these things also. Space savings might translate into
speed savings, too (since you seem to be stuck on fast == GOOD at
the expense of everything else) due to the operation of data caches.
>>>we are talking about a few scalars wouldn't it be OK to let the compiler
>>>represent them as int32s since they are faster?
Wouldn't it be OK to let the compiler represent int_fast16_t as
an int16_t on a machine which requires shift-and-mask operations to
BECAUSE IT TAKES LESS MEMORY? No, because int_fast16_t is supposed
to be fast. Likewise, int_least16_t is supposed to be small.
>> The programmer asked for memory savings over speed savings by
>> using int_least16_t over int_fast16_t. Speed doesn't do much good
>> if the program won't fit in (virtual) memory.
>
>You expect to run out of memory? If that is really a problem why not use
>int16_t?
int16_t is not guaranteed to exist at all, although it will
not be a problem on most current machines. Eventually it might
be an issue on machines where (char,short,int,long,long long) are
(32, 64, 128, 1024, and 8192) bits, respectively.
>More to the point, memory constraints are more likely to be a feature of
>PICs or similar. In that case I would want to be able to tell the compiler
>to fit the code in X words but to still optimize to be as fast as possible.
int_least16_t is a way of telling the compiler to save memory.
If you want fast, use int_fast16_t.
It is quite possible for there to be a tight memory constraint on
some memory but not others in embedded devices, for example, limited
space for NONVOLATILE memory (represented, for example, as one
struct containing all the nonvolatile parameters) but more generous
memory for the program to run.
>> The few scalars might be deliberately made the same type as that
>> of a big array (or disk file) used in another compilation unit.
>> One example of this is storing data in dbm files using a third-party
>> library. When you retrieve data from dbm files, you get back a
>> pointer to the data, but it seems like it's usually pessimally
>> aligned, and in any case the dbm functions do not guarantee alignment,
>> so the way to use it is to memcpy() to a variable/structure of the
>> same type, and access it there. This fails if different compilations
>> have different sizes for int_least16_t.
>
>Agreed but better, surely, to define the interface using int16_t. I expect
int16_t need not exist.
>that int_least16_t would be different for different implementations, making
>them incompatible with each other. This is an argument against the presence
>of int_least16_t.
If the data in question is not used outside the program (as would likely
be the case with arrays or with temporary disk files used only while
this program is running, portability of data between implementations
is not an issue.
>>>If, on the other hand,
>>>these were stored in arrays
>>> int_least16_t fred [10000];
>>>why not let the compiler choose whether to store as int16 or int32,
>>>depending on it's optimization constraints?
>>
>> sizeof(int_least16_t) must be the same in all compilation units
>> that get linked together to make a program. (of course, array
>> subscripting, allocating a variable or array of int_least16_t, and
>> pointer incrementing all implicitly use that size) The optimizer
>> doesn't get much info on what size to make int_least16_t when the
>> only reference to it is:
>>
>> void *vp;
>> size_t record_count;
>>
>> qsort(vp, record_count, sizeof(int_least16_t), compar);
>>
>> However, using that information, the compiler *MUST* choose now.
>> Perhaps before the part that actually allocates the array vp points
>> at is even written.
>
>Again, perhaps this is better written as int16_t, though I am beginning to
>see there could be benefits to separating int_fast16_t.
int16_t need not exist.
I was very disappointed in the standard for not requiring int_least11_t,
int_fast37_t, and, if it exists in the implementation, int53_t.
(or, in general, int_leastN_t, int_fastN_t, and if present, intN_t
for all prime values of N up to the maximum size available, and
preferably non-prime values as well). It would at least be clear
in arguments over int_fast37_t vs. int_least37_t that there is a
good chance that int37_t doesn't exist.
Gordon L. Burditt
- Next message: Chris Croughton: "Re: More bitwise woes"
- Previous message: Martin Ambuhl: "Re: strtok but keep the separator"
- In reply to: James Harris: "Re: Why in stdint.h have both least and fast integer types?"
- Next in thread: Charlie Gordon: "Re: Why in stdint.h have both least and fast integer types?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
