Is there any difference in speed in manipulating different types of variables?

Question

This is in reference to C++ and using the Visual Studio compilers.

Is there any difference in speed when reading/writing (to RAM) and doing mathematical operations on different types of variables such as bool, short int, int, float, and doubles?

From what I understand so far, mathematical operations with doubles takes much longer (I am talking about 32 bit processors, I know little about 64 bit processors) than, say, operations with floats.

How then do operations (reading/writing to ram and elementary math) with float and int compare? How about int and short int, or even differences between signed and unsigned versions of each of the types? Is there any one data type that would be most efficient to work with as low number counters?

Thanks, -Faken

Answer 1

There are two different questions here: speed when reading/writing, and arithmetic performance. Those are orthogonal. When reading or writing a large array, of course, the speed depends on the amount of bytes read as O(N), so using short over int (considering VC++) would slash the time by ~1/2.

For arithmetic, once the operands are in registers, the size of the type doesn't matter so much. IIRC, between types in the same category, it is actually the same (so short isn't any faster or slower than int ). Using 64-bit integer types on a 32-bit platform will have a penalty, naturally, since there's no single instruction to handle that. Floating-point types, on the other hand, are simply slower than all integral types, even though sizeof(float)==sizeof(int) on VC++. But, again, operations on float aren't any faster than operations on double ; this is assuming default FPU settings, which promote all operands to 80-bit extended floats - this can be disabled to squeeze out a bit more out of using float s, IIRC.

The above is VC++ and x86 specific, as requested by the question. Other platform, and especially other architecture, can differ radically.

The best one data type that is most efficient to work with as number counter (low or not) is int - usually regardless of the architecture and implementation (as the Standard recommends it to be the preferred word size of the platform).

Answer 2

From what I understand so far, mathematical operations with doubles takes much longer (we are talking about 32 bit processors, I know little about 64 bit processors) than say operations with floats.

I don't know (I've virtually never programmed floating-point arithmethic) but I doubt that: because double is native precision (supported by hardware), whereas I don't know about float.

How then do operations (reading/writing to ram and elementary math) with float and int compare?

Float is slower than int.

how about int and short int, or even differences between signed and unsigned versions of each of the variables?

Short may be slower than int, because the CPU uses int natively and needs to truncate results to make them short. They'd only be faster if there are so many of them contiguously that they're better at fitting in the CPU cache.

differences between signed and unsigned versions of each of the variables?

No I don't think so.

Is there any one data type that would be most efficient to work with as low number counters?

int.

Answer 3

Most CPUs work fastest on data types that match their natural word size. So, depending on architecture, 4 or 8 byte data types. int is often defined as "natural word sized" so any operation on an int should be fast.

In practice, however, you're going to pay so much more for cache misses, soft and hard page faults, and memory access than any sort of arithimatic operations that optimizing your data types is probably going to be a waste of time.

Profile your code, then optimize the hots spots.

Answer 4

This heavily depends on the architecture and the compiled assembly of your C++ code. For example on MIPS, floating point operations require reading to and from multiple CPU registers.

This type of micro-optimization shouldn't affect performance very much and should be left to the compiler to handle. You should profile your application for bottlenecks if you're looking to optimize something.

Answer 5

I don't know what the difference is between how doubles and floats are processed, but I'm pretty sure its done with a Floating Point Unit. This compares with register operations for ints and longs. (Is there a separate Integer calculation processor in modern CPUs?)

The writing to RAM question is very tricky to answer now-a-days because of the levels of caching and the very high CPU clock speeds compared to RAM write speeds.

As far as performance is concerned - Measure first!

Write performance tests that accurately reflect your target environment.

Answer 6

Main memory access impacts your performance similarly to CPU cache. Modern (SDRAM, DDRx) DRAM access time improves considerably with locality of reference. What this means is that you want your data to be contiguous. This often contradicts object orientation. OOD would have you put all of the elements of one object together. If your algorithm called for operations against the various elements of one object then your referential locality would be good. If your algorithm called for operations against the same element of multiple objects, your locality would be bad. If you have "loops running mathematical operations numbering in the billions or even trillions of calculations" it is most likely that you have the latter situation. If your operations are picking elements out of objects, your CPU cache and RAM prefetches can be nearly ineffective or even detrimental. If this is the case, you can significantly increase performance by breaking your arrays of objects into synchronized arrays of like elements. It's ugly but can be much faster.

Answer 7

You can have a dramatic increase in performance with smaller types (floats, 8-bit ints, etc) if you can use SIMD primitives. The SIMD primitives can pack eight 8-bit int operations (or two doubles, or 4 floats, etc) into a single operation that gets parallelized in hardware. Though, SIMD primitives are only supported on CPUs since the Pentium III.