execution speed

[krkrkr]

Hello,

I'm programming a PPC405 in c on a devolpment board, I didn't enable the cache and I set the compiler option to no optimization. I'm trying to measure the execution time for a simple for loop with a HW timer on an FPGA some thing like this:
i, test is defined as unsigned integer 32 bit
start the timer;
for (i=0; i<1000000; i++)
test = i + 5000;
read the timer and print the timer result;

My problem is that the result is changed if I chenged my code i.e. increased the code but outside the loop and the timer.
I expect to have fix time since the loop is not changed, any hint?

Thanks.

 

[xwb]

Are there any alignment issues? For instance, on Intels, i does not have to be on a word boundary: it can be across a word boundary and would cause similar timing problems. The PPC405 may possibly have similar issues.

 

[krkrkr]

Could you explain more what do you mean? Can you give a sample code?

Thanks.

 

[xwb]

Do you have something like this

char misalign;
int i, test;
for (i=0; i<1000000; i++)
 test = i + 5000;

Without misalign, you get one timing, with misalign, you get a different timing. This is very compiler and architecture dependent. Is it possible to check the code generation to see if i and test are on an odd boundry?

 

[krkrkr]

1- I don't have some thing with 'char misalign', all what I have is i, test and they are unsigned integer 32 bit and PPC405 is a 32 bit device.

2- Compiler is set to no optimization.

3- Even if I have 'char misalign', why would it affect the timing of the for loop? the loop is independent from misalign. I read the timer value around the for loop only.

4- I could not check the generated code from the compiler, but is there a method to ask the compiler not to generate misaligned variables?

Thanks.

 

[xwb]

3 some compilers will pack the data such that i will take bytes 1-4 instead of 4-7. This stretches over a word boundary and can result in slower execution. If you don't have anything like that then that is obviously not the answer.

4 which compiler are you using? Is it gcc? I'm not familiar with the ppc toolset.

 

[krkrkr]

3- i and test are defined as 32 bit integer, so there will be no stretches over a word boundry, and those are the only variables i used in the for loop.

4- yes, its gcc.

 

[xwb]

Don't think it is the problem I mentioned: must be something else. I don't know if PPC uses register variables. If it does, it could explain the speed difference. The one with register variables would be faster.

 

[krkrkr]

But since I choose to compile without optimization then all variables should go to memory.

Thank you.

 

[ArkM]

Some remarks. I have never seen compilers with so strange (and funny alignment problems. Bad alignment of int variable in declarations like these

char misalign;
int  itsaligned;

is an unthinkable compiler error. Impossible...

 

[xwb]

It is just something I noticed a few years ago on one of the MS compilers when looking at the code generation.

 

[lionelhill]

ArkM, amazing how the world changes. Back in 386 and lower days in IBM compatible PCs, there were compilers considered good that would very happily put word-sized data across a word boundary, doubling the memory accesses needed per loop. Of course back then they had to be aware a user might prefer to optimise for low memory use rather than speed.

Also, given a definition of a data structure, an old-fashioned compiler was obliged to stick to it, even if it was a structure that couldn't align all its fields properly, because that might just be how the structure was going to be read as a block from elsewhere.

I remember the first time I was silly enough to make the mistake; a tiny change in code made a huge (nearly 2-fold) difference to execution time, because it had shifted a subsequent block of data out of alignment. Another reason to be wary of mixing data and code, but those were innocent days.

 

[ArkM]

Data alignment problems in compilation area were considered (and solved many decades ago (in pre-System/360 era.
Yes, that's true: some compilers have special code generation modes (ignore data alignment boundaries, pack structures etc), but it's the other story.
No pro-level compilers with "ignore data alignment in the stack frame data mapping" by default code generation.
Moreover, there are (were) lots of CPUs which can't process unaligned data at all (FP especially)...