This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cycles calculation in beagle board

Offline Senthilkumar N L over 9 years ago

Note: This was originally posted on 22nd November 2010 at http://forums.arm.com

Hello All,

I am trying to use the cycle counter registers of cortexA8 for calculating cycles.
Following is the code i am using.

int main()
{
     int i;
     int a,b,c,n;
     printf("Enter a: ");
     scanf("%d",&a);
     printf("Enter b: ");
     scanf("%d",&B);
     printf("Enter c: ");
     scanf("%d",&c);
     printf("No of times to run: ");
     scanf("%d",&n);

     ccnt_init();
     ccnt_start();
     cycles=ccnt_read();
     {
             c=a+b;
     }
     cycles=ccnt_read()-cycles;
     ccnt_stop();
     printf("Sum : %d\n",c);
     printf("Cycles : %d\n",cycles);
}

The above simple integer addition takes 5 cycles since it includes load operations.
If all the above variables are made double it takes 3800 cycles if I enable neon and 1900cycles if i disable neon.
Kindly explain how i am getting these values.
I am using beagle board XM-A3 to run this code and i am using codesourcery 2010q1 toolchain to compile the code.
I am wondering whether it is due to the interrupts. If so how to disable the interrupts.

Thanks in advance..

Offline Martin Weidmann over 9 years ago

Note: This was originally posted on 22nd November 2010 at http://forums.arm.com

Could be due to lazy context switch, if you are running under Linux.

As many (most?) apps aren't built to use the FPU, Linux simply disables the FPU on context switch instead of saving/restoring all the FPU regs. If the newly switch in app does use the FPU, its first FPU operation will trigger a hardware exception. This is trapped by the OS, and at that point the FPU is re-enabled and state saved/restored. This process means the first op after a context switch takes significantly longer.

Try doing a dummy calculation using doubles before you timed block.

Other thing to consider is the length of block you measure. The A8 has quite a long pipeline, and measure a block which is shorter than the pipeline will hide many of the pipeline benefits.
Cancel
Up 0 Down

Cancel
Offline Peter Harris over 9 years ago

Note: This was originally posted on 25th November 2010 at http://forums.arm.com

You may also want to look at how your floating point is being provided. In many cases for Linux it defaults to a floating-point library (which may be hardware or software) which lis loaded at run-time. A lot of Linux distros default to this shared object implementation, which adds veneer call overheads for every FPU operation. Even with "hard float" you may still find you link a library rather than emitting float instructions directly into the binary - so you may want to dump the image using objdump to make sure you are emitting hard-float directly.

Secondly - the linker resolution of symbols in a shared object is commonly "lazy" for Linux - that is they are resolved the first time they are hit and found to be missing. You may well find you are spending time in your 1900 cycles resolving a link into the shared object via the dynamic linker. The idea of ttfn to do one operation outside of the timing loop before timing should solve this one.

Finally - don't use doubles if you can use floats. For an embedded platform doubles are horrendously expensive - and for most use cases float is fine.

Iso
Cancel
Up 0 Down

Cancel