Are "char" and "small int" slower than "int"? [duplicate]

Question

Possible Duplicate:
Performance of built-in types : char vs short vs int vs. float vs. double

Hi. Assume, that you have 32-bit processor. Are 8-bit char and 16-bit short int types slower than native 32-bit int? What about using 64-bit long long int?

Are this datatypes supported by hardware by default, or they are all transformed into 32-bit data anyway, by using additional instructions?

In case, that I have to store a small amount of chars, isn't it faster to store them as ints?

Octans

If you're storing a small amount of chars why are you bothering with a potential nanosecond difference? – Yelp

@Erik: A single variable could be used millions of times. Your argument doesn't follow. – Oloughlin

@R.: And using wider types for chars could increase cache misses. Pointless optimization until the profiler proves otherwise. – Yelp

@Erik: What are cache misses? Just in a few words, I don't need entire definition :) thanks – Octans

CPUs keep recently used memory location in "fast RAM" This RAM is a cache to the much slower main memory. – Harlot

@R.. Don'cha love how Erik changed the subject and addressed a strawman. And what's with people who can't spell your userid. – Laban

Optimization matters, and learning how to do things the fastest way possible is a good thing! . Please stop with the Premature Pessimization. – Sphinx

Stolen directly off the linked duplicate above: Typically, CPUs are fastest at operating on integers of their native word size (with some caveats about 64-bit systems). 32 bit operations are often faster than 8- or 16- bit operations on modern CPUs, but this varies quite a bit between architectures. Also, remember that you can't consider the speed of a CPU in isolation; it's part of a complex system. – Sphinx

Even if operating on 16-bit numbers is 2x slower than operating on 32-bit numbers, you can fit twice as much data into the cache hierarchy when you represent it with 16-bit numbers instead of 32-bits. If that makes the difference between having all your data come from cache instead of taking frequent cache misses, then the faster memory access will trump the slower operation of the CPU. – Sphinx

Cache matters a lot more then CPU operations if you're iterating over sets of data so I'd wager that the smaller sizes would be faster - cooking up a benchmark now. – Sphinx

I can't post code as this is closed, please see my answer on the duplicate: #5069989 – Sphinx

Answer 1

On any modern, practical machine, char, int, and long will all be fast (probably equally fast). Whether short is fast or not varies somewhat between cpu architecture and even different cpu models within a single architecture.

With that said, there's really no good reason to use small types for single variables, regardless of their speed. Their semantics are confusing (due to default promotions to int) and they will not save you significant space (maybe not even any space). The only time I would ever use char, short, int8_t, int16_t, etc. is in arrays or structs that have to match a fixed binary layout of where you'll have so many of them (e.g. pixels or audio samples) that the size of each one actually matters.

Oloughlin

Really? You'd use an int for a boolean instead of a signed char, for example? – Obduce

Of course. Not only is it likely to generate smaller, faster code; it's also more idiomatic. All of the standard C functions that return truth values use int as their return type, and the value of all comparison/boolean operators in C has type int. – Oloughlin

I'm too biased toward minimal designs to think that's right. lol. I'll try using this from now on. – Obduce

@Spidey: I recommend against using int where you mean bool or char. Use the type you need. – Huckaback

Also note that signedness can matter. Arm for example has had instructions for fast "load and zero extend" of bytes for a long time but the support for fast "load and sign extend" of bytes was only added in a later version and has more restrictive addressing. – Edraedrea

Answer 2

It depends on the operations in the instruction set as well as the compiler.

Wandie