Boost Users :
Subject: Re: [Boost-users] How to find: best integer type for processor
From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-10-30 12:59:45
On Thu, Oct 30, 2008 at 8:41 AM, Cory Nelson <phrosty_at_[hidden]> wrote:
> On Thu, Oct 30, 2008 at 8:24 AM, 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).
> Most things don't need 64-bit ints, so it would just be wasting memory
> to use them if 32-bit ints are as fast or faster. This is why "int"
> stays 32-bit on most x64 ABIs.
IMO, on a 64-bit CPU int should be 64 bits, and long should be 128
bits, except if adding two 64-bit values that are already in registers
is slower than if they were 32-bit.
I don't buy the argument that this wastes memory. When a given integer
type uses too much memory for your needs, you can store a smaller type
in your structs; you can even use bitfields if you need a portable way
to tinker with an integer's memory footprint.
Reverge Studios, Inc.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net