• Locked Locked
  • Replies 2 replies
  • Subscribers 119 subscribers
  • Views 2771 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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

Senthilkumar N L
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..
  • Arm Employee Badge
    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.
  • Arm Employee Badge
    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