Re: [boost] How to find: best integer type for processor

Subject: Re: [boost] How to find: best integer type for processor
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-10-30 11:53:36

On Thu, Oct 30, 2008 at 4:24 PM, Daryle Walker <darylew_at_[hidden]> wrote:
> Is there a macro and/or typedef that will tell me bit-length used for a
> processor and/or the best integer type for said processor?  The "int" type
> is supposed to be that type, and it was in the 16- and 32-bit eras.  (I
> learned C programming with the former in the... early 1990s!)  However, the
> powers-that-be decided, for "backwards compatibility," to freeze "int" and
> "long" at 32 bits and use a new type, "long long," for 64 bits, which should
> be the optimized integer type for 64-bit processors.  (If they kept to the
> plan, "int" would be 64 bits, "long" either 64 or 128, "short" up to 32, and
> the new type will be "short short" at 16.)  I want to know the best type so,
> when I build multi-integer arrays for various purposes, I don't pick an
> element type that causes a slow down, whether to focus on a fraction of a
> register (if the chosen type is too small) to handle two registers at once
> (if the chosen type is too large).
>

A 32 bit integer *is* the best integer type for practically all 64 bit
processor.

At least for x86-64, there is no penalty for performing 32 bit
arithmetic instead of 64 bit. In fact 64 bit arithmetic requires a REX
prefix which will slightly enlarge the code footprint.

There is a large cache saving advantage in using smaller integer size.

Finally, having smaller integers means that you can fit more of them
in SIMD registers.

Long is a bit different as I think most programmers have always
expected 'long' to be big enough to cover all offsets in the address
space (most 64 bit unices have 64 bit longs. I think that Win64 is the
exception). Anyways, correct code should always use size_t for sizes
and ptrdiff_t for offsets.

-- 
gpd