How to find: best integer type for processor
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). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
On Thu, Oct 30, 2008 at 8:24 AM, Daryle Walker <darylew@hotmail.com> 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. If you want the largest native integer, though not 100% portable to weird archs, this should work in x86/x64 and most others: typedef boost::int_t<sizeof(void*) * 8>::fast fastint_t; -- Cory Nelson http://www.int64.org
[ this latest and greatest hotmail refuses to put ">" on earlier text and seems to resent the idea I would decline to send html. LOL ] There is no requirement that the address space cardinality as reflected in the size of a pointer be related to relevant registers or bus size or anything having to do with your application needs. Sure, normally registers are sized to manipulate addresses and usually this would be a reasonable guess on register size but may not be related to various bus sizes. More important things, like cache size, would be nice to learn about at runtime. As a person who likes to write lower level code and gets annoyed manipulating char's knowing that registers and buses are wider, I have a lot of sympathy, but you first need to size your structures for your needs. What did the OP mean by "best?" Date: Thu, 30 Oct 2008 14:12:59 -0200 From: rodrigo.madera@gmail.com To: boost-users@lists.boost.org Subject: Re: [Boost-users] How to find: best integer type for processor typedef boost::int_t::fast fastint_t; Nice, but why isn't this part of the standard distribution as a "word_t" or something? Just curious why it's not there already. Rodrigo _________________________________________________________________ Stay up to date on your PC, the Web, and your mobile phone with Windows Live. http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/
On Thu, Oct 30, 2008 at 8:41 AM, Cory Nelson <phrosty@gmail.com> wrote:
On Thu, Oct 30, 2008 at 8:24 AM, Daryle Walker <darylew@hotmail.com> 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. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
IMO, on a 64-bit CPU int should be 64 bits, and long should be 128
I agree that such a type should be available. Maybe not all ints directly, but have a word_t for that purpose. People may argue that "it's not needed" or redundant or whatever, but having the register width as a type could be really useful sometimes. Rodrigo
On Thu, Oct 30, 2008 at 12:15 PM, Rodrigo Madera <rodrigo.madera@gmail.com> wrote:
IMO, on a 64-bit CPU int should be 64 bits, and long should be 128
I agree that such a type should be available. Maybe not all ints directly, but have a word_t for that purpose.
People may argue that "it's not needed" or redundant or whatever, but having the register width as a type could be really useful sometimes.
As the original message said, int is supposed to be the type that matches the CPU register size. The semantics of the C/C++ expressions have been carefully designed for that purpose of int. For example, adding 2 shorts in C/C++ produces an int (not a short), because a typical CPU works most efficiently with full registers (in fact it may not even have "half registers".) With int being 32-bit on a 64-bit CPU, a C compiler is forced to generate code that works with half registers, which would have been inefficient had most 64-bit CPUs not been designed with this in mind. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Thu, Oct 30, 2008 at 13:08, Othman, Ossama <ossama.othman@intel.com> wrote:
If you want the largest native integer, though not 100% portable to weird archs, this should work in x86/x64 and most others:
typedef boost::int_t<sizeof(void*) * 8>::fast fastint_t;
Why not just use the standard {u}intptr_t or {u}intmax_t typedef in this case?
For intptr_t, this message comes to mind: http://lists.boost.org/Archives/boost/2005/09/94158.php And intmax_t is the wrong choice on 32-bit systems that provide a 64-bit type.
Hi Scott,
If you want the largest native integer, though not 100% portable to weird archs, this should work in x86/x64 and most others:
typedef boost::int_t<sizeof(void*) * 8>::fast fastint_t;
Why not just use the standard {u}intptr_t or {u}intmax_t typedef in this case?
For intptr_t, this message comes to mind: http://lists.boost.org/Archives/boost/2005/09/94158.php
Well that certainly explains things. That makes my comment on the boost mailing list a bit moot, as well. Thanks for the pointer! It's been three years since that thread was posted. Do the arguments still apply? I assume they do.
And intmax_t is the wrong choice on 32-bit systems that provide a 64-bit type.
I agree. I merely mentioned it because of the "largest native integer" comment above. Thanks again! -Ossama
Scott McMurray wrote:
On Thu, Oct 30, 2008 at 13:08, Othman, Ossama <ossama.othman@intel.com> wrote:
If you want the largest native integer, though not 100% portable to weird archs, this should work in x86/x64 and most others:
typedef boost::int_t<sizeof(void*) * 8>::fast fastint_t; Why not just use the standard {u}intptr_t or {u}intmax_t typedef in this case?
For intptr_t, this message comes to mind: http://lists.boost.org/Archives/boost/2005/09/94158.php
True, but IMO it is an error in the C standard, that it did not add a similar statement for (u)intptr_t as it does for the exact integer types (u)intN_t, which says in 7.18.1.1/3: "These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement representation, it shall define the corresponding typedef names." If this had been done, you could always use (u)intptr_t where boost::int_t<sizeof(void*) * CHAR_BIT>::fast would be a feasible instantiation. Side note: Is anyone aware of the proper forum/contact person to address this issue to persons near to the C standard? Just my 2 euro cents, Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cory Nelson wrote:
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.
If you want the largest native integer, though not 100% portable to weird archs, this should work in x86/x64 and most others:
typedef boost::int_t<sizeof(void*) * 8>::fast fastint_t;
I use this approach when I need the maximum "fast" integer type. If you are really paranoid about the pointer/fast integer size ratio not being 1, you can add a BOOST_STATIC_ASSERT somewhere to prevent compilation on weird archs. Francesco. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkJ9VQACgkQFCtI0YdDCEthfgCeOtSG862w6LO2pLdIErmClZ95 VsMAoJ5OY/Fz3tgBzcjbnPdmgVl25JtW =svbV -----END PGP SIGNATURE-----
participants (2)
-
Cory Nelson -
Daniel Krügler -
Daryle Walker -
Emil Dotchevski -
Francesco Biscani -
Mike Marchywka -
Othman, Ossama -
Rodrigo Madera -
Scott McMurray