what integer width processed faster in C?_问答_开发者

Is there difference in speed when I use 16-bit width or 32-bit width integer on 32-bit CPU? Or, 3开发者_运维百科2-bit vs 64-bit int on 64-bit arch?

In other words, if I have some value that fit into uint16_t ranges, should I use "unsigned int" instead if performance is matter?

The <stdint.h> header provides typedef for the "fastest integer types having at least certain specified widths" which may be helpful in your case :

Each of the following types designates an integer type that is usually fastest to operate with among all integer types that have at least the specified width.

The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N.

The following types are required:
int_fast8_t               uint_fast8_t  
int_fast16_t              uint_fast16_t  
int_fast32_t              uint_fast32_t  
int_fast64_t              uint_fast64_t  

You should never use the fixed-size integer types except for constructing fixed-layout binary structures or large arrays of data where larger-than-necessary size could lead to huge amounts of wasted memory.

The only good use I can think of for uint16_t or int16_t is 16-bit audio samples (still the predominant format for audio). Otherwise just use an ordinary type you know will be sufficiently large. int is always at least 16-bit, and on POSIX and Windows it's at least 32-bit.

If you need to store a count of objects, always use size_t, and if you need to store a file offset, always use off_t (unfortunately only available on POSIX).

Usually all operations are performed on machine's native word, so you could have a small penalty when using smaller types (for example, passing a short int when an int is expected would use a sign extension opcode). But, they would be faster if SSE instrcuctions could be used!

And, surely, a much larger penalty when using the larger types than the machine word :)
Also, be careful with signed/unsigned operands, in some cases it can make difference.

Here you can find more about it.

This is highly CPU dependent and there's no surefire way to know this ahead of runtime, especially because you're not asking about a specific CPU...

16-bit arithmetic is generally believed to be inefficient on 64-bit computers, and 32-bit arithmetic should perform faster or just as fast as 64-bit arithmetic, but like I said, your mileage may vary, especially with future CPUs.

If you don't know the target CPU ahead of time and this is very time-sensitive code, you may want to implement it both ways, have your software run a quick benchmark at startup, then use the path that's faster.

In many cases, the question that you are asking is not the right one and it should only be of concern when you are doing a lot computations with integer data without too much loading or storing them into memory. This can only be checked by benchmarking a particular program.

For all other programs, correctness and portability (in that order) should be of much more concern. Therefore you should always use the "generic" types and typedefs that C (and perhaps your platform) foresees for special purposes.

Any type of counting and indexing should be done with size_t.
Differences and relative positions should be done with ptrdiff_t.
Error and return codes from standard library or system calls usually are int.
Character strings use char or wchar_t.

These are usually types that fit well into CPU registers and for which the compiler knows to generate efficient code. All other integer types are for special purpose and should otherwise be avoided. In particular types that have a width that is less than the one of int are not much use for arithmetic, since the standard enforces that they are promoted to int or unsigned before any kind of operation.