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
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?
Not sure it really helps but check out http://www.boost.org/doc/libs/1_36_0/libs/integer/cstdint.htm, especially the uint_fast32_t typedefs. Philippe
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
On Thu, Oct 30, 2008 at 4:24 PM, 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).
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
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.
... and {u}intptr_t when converting between pointers and integers. -Ossama
On Thu, Oct 30, 2008 at 4:24 PM, 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).
Giovanni answered:
A 32 bit integer *is* the best integer type for practically all 64 bit processor.
I'm going to disagree with Giovanni here. For Daryle's purposes 64 bit is better on a 64 bit platform. I'd like to call your attention to the study performed by gmp
On Thu, Oct 30, 2008 at 6:16 PM, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:
On Thu, Oct 30, 2008 at 4:24 PM, 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).
Giovanni answered:
A 32 bit integer *is* the best integer type for practically all 64 bit processor.
I'm going to disagree with Giovanni here. For Daryle's purposes 64 bit is better on a 64 bit platform. I'd like to call your attention to the study performed by gmp
Well, mine was an answer to the general question 'why int is not 64 bits on 64 bit platforms'. Of course an application may have its specific needs. -- gpd
A quick question regarding 64-bit. Is the alignment here 8 bytes or still 4 bytes? I mean when reading from memory does the compiler read in 4 bytes or 8 byte chunks? Thanks, Christian
Christian Henning wrote:
A quick question regarding 64-bit. Is the alignment here 8 bytes or still 4 bytes? I mean when reading from memory does the compiler read in 4 bytes or 8 byte chunks?
On a true 64 bit architecture the word size would be 8 bytes. You current 64 bit processors are still 32 bit addressable and have 32 bit alignment. A cache line much larger than 8 bytes is read from physical memory into cache and when data is fetched from the data cache into a register it depends on the bit width of the bus between the cache and the processor whether it is 4 or 8 bytes at a time. If it were a 32-bit architecture it would read two four byte chunks into two 32 bit registers. On a EM64 bit architecture it would read one 8 byte chunk into a 64 bit extended register, unless the value were split between two cache lines in memory, in which case it takes two 32 bit chunks from the two different cache lines. It takes more than one clock to access even L1 cache so whether it does it in one step or two isn't really the performance critical aspect of the problem anyway. In general, you should not need to consider whether reading a 64 bit value from data cache into register by the processor is one step or two for the processor when programming in C++. It is read as one chunk from memory into the cache, even on a 32-bit architecture, which is good enough, and your latency from cache to memory is usually a bigger deal than your latency from cache to register. In other words, the typical workload loses more performance to cache misses than to cache access latency. The compiler would be hard pressed to align 64-bit values to addresses that are multiples of eight bytes in memory in a 32-bit addressable system, and as you can see, it is more profitable to align things to cache lines, which can be done at the application level with special allocators. Hope that helps, Luke
On Thu, Oct 30, 2008 at 4:24 PM, 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).
Giovanni answered:
A 32 bit integer *is* the best integer type for practically all 64 bit processor.
I'm going to disagree with Giovanni here. For Daryle's purposes 64 bit is better on a 64 bit platform. I'd like to call your attention to the study performed by gmp http://gmplib.org/32vs64.html Where the compared the effectiveness of using arrays of 64 bit integer vs. 32 bit integer for their multi-precision integer objects. Their conclusion is that 64 bit is much better. If you don't need more than 32 bits, don't use 64 bit integers even on a 64 bit platform. If you need more than 64 bits, don't use 32! Luke
participants (7)
-
Christian Henning -
Cory Nelson -
Daryle Walker -
Giovanni Piero Deretta -
Othman, Ossama -
Philippe Vaucher -
Simonson, Lucanus J