Re: Why in stdint.h have both least and fast integer types?

From: James Harris (no.email.please)
Date: 12/01/04 

Date: Wed, 1 Dec 2004 18:03:55 -0000

"Gordon Burditt" <gordonb.4sa97@burditt.org> wrote in message
news:coaq1f$jc0@library1.airnews.net...
>>>> 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?

>>we are talking about a few scalars wouldn't it be OK to let the compiler
>>represent them as int32s since they are faster?
>
> 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?

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.

> 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
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, 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. 

--
Cheers,
James

Relevant Pages

  • Re: Fast string operations
    ... Looping: I thought looping over arrays in managed code was "slow" ... array handling and such. ... The problem with TrimHelper is that it always returns a new string instance. ... The customer perceives this as a memory leak. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: High Memory Consumption of Classes and Arrays
    ... Only the array itself has overhead. ... memory as a reference type. ... > least consume 40 bytes of memory. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Fast linked list
    ... > amounts of memory rather than huge chunks of it. ... random insertions into a vector/dynamic array are not as slow ... to cause a cache miss. ... some hard numbers on speed differences between lists and arrays. ...
    (microsoft.public.vc.mfc)
  • Re: Fast linked list
    ... > amounts of memory rather than huge chunks of it. ... random insertions into a vector/dynamic array are not as slow ... to cause a cache miss. ... some hard numbers on speed differences between lists and arrays. ...
    (microsoft.public.vc.language)
  • Re: not enough storage... error using GetRows
    ... > array only contained ~150,000 rows. ... It took 19 minutes for GetRows to return (db ... and the prog had consumed 200MB of memory. ... The first one allocates some 180MB, the next two only allocate about 47MB ...
    (microsoft.public.vb.database.ado)