64-bit and memory bandwidth

Question

Mason asked about the benefits of a 64-bit processor .

Well, the obvious drawback is that you need to move more bits. And considering that accessing memory is a serious problem these days [1], moving twice as much memory for a number of operations may not be good.

But how bad is the effect of this, really? And why is this offset? Or should I run all my small applications on 32-bit machines?

I should mention that I am considering, in particular, the case when you have the choice to run 32-bit or 64-bit on the same computer, so in both modes the bandwidth for the main memory is the same.

[1]: And even fifteen years ago, for that matter. I remember talking about the good behavior of the cache, and also especially that the Alpha processors, which won all the benchmarks, at that time had a giant 8 MB L2 cache.

Answer 1

Most 64-bit software environments use the "LP64" model, which means that only pointers and long int variables (if you are a C / C ++ programmer) are 64 bits. Integers ( int s) remain 32-bit unless you are in the "ILP64" model, which is pretty rare.

I return it only because most int variables are not used for size_t friendly purposes, that is, they remain within ranges conveniently held by 32 bits. For variables of this nature, you can never distinguish this information.

If you are working with numerical or heavy data s> 4 GB of data, in any case you will need 64 bits. If you do not, you will not notice the difference if you are not used to using long , where most of them will use int s.

Answer 2

Whether your application should be 64-bit depends on what calculations it does. If you need to handle very large datasets, you obviously need 64-bit pointers. If not, you need to know if your application spends relatively more time on arithmetic or memory access. On x86-64, general-purpose registers are not only twice as wide, they are twice as large, and they are more "general-purpose." This means that 64-bit code can have much better integer performance. However, if your code does not require additional register space, you are likely to see better performance using less pointers and data due to increased cache efficiency. If your application is dominated by floating point operations, then there is probably not much point in making it 32-bit, because most of the memory access will be for wide vectors anyway, and additional SSE registers will help.

Answer 3

I think you start with a bad guess here. You speak:

moving twice as much memory for a fair amount of operations may not be a good thing

and the first question is to ask, "why not"? In a true 64-bit machine, the data path has a width of 64 bits, and therefore the movement of 64 bits exactly corresponds (in a first approximation) to the number of cycles, like the movement of 32 bits on a 32-bit machine. So, if you need to move 128 bytes, it only takes a half cycle, since it takes a 32-bit machine.