How can my variable declarations affect execution time

Question

I am a circuit designer (not a software wizard) and have been working on a numerical algorithm for the past 9 months. As a way to evaluate the effectiveness of my algorithms, I monitor the amount of time needed to converge on a solution.

About 6 months ago I discovered that the way I declare my variables can have a dramatic effect on the time needed for the program to run. For example, simply rearranging the declarations, as shown below, can double the time needed to run the code. Simply changing the lengths of the arrays also affects the problem similarly.

int N, j, Iter;
long double RealZero, RealErr, QuadIterErr, QuadX;
long double TUV[3], QuadQP[102], RealQP[102];
bool Updated;

int N, j, Iter;
long double RealZero, RealErr, QuadIterErr, QuadX;
long double QuadQP[102], RealQP[102];
bool Updated;
long double TUV[3];

I initially assumed I had some sort of bug, but I can't find it. Other than speed, I don't see any other anomalies, and I get the same results whether the code runs slow or fast.

I found some discussions on problems associated with packing long doubles, but I didn't understand any of it, and they never said how to fix the problem they were discussing.

Can someone give me some insight as to what might be going on here and how to fix it?

I need consistency more than I need the speed. I am not using any speed optimizers (default compiler settings) and I am using C++ Builder XE3. I am not using a #pragma pack (as someone asked).

Based on the comments, I setup the declarations for slow and fast execution, and compared the base addresses on all the long double variables. Whether slow or fast, the addresses end with a 0, 4, 8, or C.

Answer 1

One thing that definitely does affect code performance is unaligned data: the x86 platform can read unaligned data (unlike some other architectures), but will suffer a performance penalty.

What is an unaligned access? When the size of the type is not stored at an address that is a multiple of that size. So if you store a 32-bit integer at an odd address, or even at an even address that isn't a multiple of 4, the CPU may have to do two memory reads to get both halves of the data.

In this case, the size of long double is 8, so you'd want them to be stored at addresses with a multiple of 8 - but the first three variables are integers, making 12, so in the first block of definitions all of the long doubles are stored at non-aligned memory addresses.

The second block of definitions given don't seem to be too different - but the bool has moved up, making TUV fully aligned now. If TUV was the most heavily used memory in the algorithm, then I could well believe that there was a timing difference!

So how do you fix it? Either tell the compiler to store variables at a greater alignment (note this is not to do with packing - that has to do with storage within a structure), or at the very least put all the largest-typed variables first in the declarations.