What C++ type use for fastest “for cycles”?

Question

I think this is not answered on this site yet.

I made a code which goes through many combinations of 4 numbers. The number values are from 0 to 51, so they can be stored in 6 bits, so in 1 byte, am I right? I use these 4 numbers in nested for cycles and then use them in the lowest level for cycle. So what c++ type from those which can store at least 52 values is the fastest for iterating through 4 nested for cycles?

The code looks like: 
for(type first = 0; first != 49; ++first)
 for(type second = first+1; second != 50; ++second)
  for(type third = second+1; third != 51; ++third)
   for(type fourth = third+1; fourth != 52; ++fourth) {
    //using those values for about 1 bilion bit operations made in another for cycles 
   }

That code is very simplified and maybe there is also a better way for this kind of iterating, you can help me also with that.

Answer 1

Use the typedef std::uint_fast8_t from the header <cstdint> . It is supposed to be the "fastest" unsigned integer type with at least 8 bits.

Answer 2

The fastest is whatever the underlying processor ALU can natively work with. Now registers may be addressable in multiple formats. In that case all those formats are equally fast.

So this becomes very processor architecture specific rather than C++ specific. If you are working on a modern day PC processor then an int is as fast as anything else for your for loops.

On an embedded system there are more things to consider. Eg. Whether the variable is stored in an aligned location or not?

Answer 3

On most machines, int is the fastest integer type. On all of the computers I work with, int is faster than unsigned , significantly faster than signed char .

Another issue, perhaps a bigger one, is what you are doing with those numbers. You didn't show the code, so there's no way of telling. Use int if you expect first*second to produce the expected integral value.

Yet another issue is how widely portable you expect this code to be. There's a huge distinction between code that will be ported to a number of different architectures, different compilers versus code that will be used in a limited and controlled setting. If it's the latter, write some benchmarks, and use the type under which the benchmarks perform best. The problem is a bit tougher if you are writing something for wide consumption.