I think you have a huge case of pre-mature optimization staring you in the face. Never make micro changes like this in your application until a profiler has definitively told you that it is a source of significant performance problems.

Otherwise you ll spend a lot of time fixing non-problems.

Well if the 32-bit operations are taking place in 64-bit registers, some extra instructions do need to get emitted to handle things like setting carry/overflow flags, etc. I d be surprised if you realised any noticeable performance improvement, though. I can all but guarantee there are far worse bottlenecks in your program.

Firstly, using 64-bit ints instead of 32-bit ints in 64-bit environment will not generally speed-up anything. Depending on the context and on the compiler abilities, this might actually slow things down. Normally, you should prefer using int/unsigned int types for storing integral values in your program, switching to other types only when really necessary. In the end, the definitive answer to the question can only be obtained by an actual experiment, since it depends on too many variables.

Secondly, anyone who advises using size_t for that purpose (as a generic unsigned type) should be immediately denied access to code and sent to take some C/C++ classes before they are allowed to touch the code again.

Don t do it. It just means that the cpu will not be able to hold as much data in cache and the penalty for going to main memory is a lot higher than most other things.

The idea that using a 64bit integer vs. a 32bit integer will speed things up is a myth. The more important thing in your code is to use the appropriate types. For instance, when referring to the size of an array or data structure, use a size_t because that s what a size_t is supposed to represent. If you re storing some piece of data, then use an int and not a size_t because that s what an int is meant to describe.

Don t just change everything to size_t because it will "automatically become 64bit" this will result in probably no improvement whatsoever. It will cause larger memory overhead which will probably cause the application to slow down due to cache misses because of the larger memory space. It will also quite possibly cause unexpected bugs.

I d guess (and it s just a guess) that you ll likely see no improvement in performance and may see a slight drop if the amount of memory increase causes some memory access to lose locality of reference and push things out of the cache more often than before.

As JaredPar says, if there s not a factual reason to do this or unless you need the increased range of the larger ints, it s probably a waste of time.