On 05/05/2012 05:06 PM, Comeau At9Fans wrote:
> On Sat, May 5, 2012 at 1:48 PM, Charles Forsyth wrote:
>
> if it's performance you're worried about, for programs that don't
> care about width, i'd expect 32 bits at least
> to match performance with 64 bits (if there's a measurable
> difference). for one thing, cache lines will contain
> more values, and several will be fetched at once when cache lines
> are filled.
>
> And for programs that do care about this, C99 provides things such as
> int_fast64_t (which IIRC 8c et al does not currently support).

<stdint.h> is just a bunch of typedef's, some of which have been
included, under different names (u{8,16,32,64}int), in <u.h>. Wouldn't
be hard to provide for APE if anyone wants it.

Yes, the u{...}int names are important. Those "different names" are normally for other (though obviously related) purposes (conceptually int_exact_*), and the int_least_* and int_fast_* names, usually are built from the exact ones. BTW, more generally re the greater issue raised earlier by an OP, if ones intent is X bits, then int is not expressing that intent, and even if your assumption happens to be correct, it might also create a portability faux pas if that is a concern. Also, if int was X bits underneath, then arrays of int, now in the case of X == 64 effectively become arrays of long stuff since not only is there now maybe wasted memory, but cache management and such can be a concern. This all has architecture dependencies though.