EVMK2H: Benchmark program between DSP and ARM

Hi,

https://www.ti.com/lit/an/sprac13/sprac13.pdf you mentioned is our application note for A15 and C66x bench-marking. The table 1 well summarized the results where C66x shows advantages over A15.

Typically, anything that involves in heavy signal processing, matrix operations, linear algebra are good for DSP implementation. The program with more control code are good for ARM processor.

>>> I try to implement a small program invlove mostly mathematic calculation>>>> For any benchmarking, you need have a framework setting up right: cache, cycle counter, memory placement, compiler/linker options, etc for comparison between different processor architectures. Also, if any optimized library code (like TI MATHLIB) is used for better performance.

Regards, Eric  

Hi Eric,

Thanks for your advice.

Do you have any example DSP and ARM project that contains proper setting for benchmarking purpose?

Hi,

Attached one is for C66x Dhrystone, it should report number like "Normalized MIPS/MHz =   0.8297". Then you can replace with your own application.

For A15, I try to find one for you.

Regards, EricDhrystone_C66.zip

Hi Eric,

I have try the provided example, and can get similar result as yours.

Just few question about the calculation of the result:

Normalized MIPS/MHz =  Dhrystones_Per_Second/1757.0/1000.0 --> Can I say that in this calculation we assume that 1000.0 MHz is processor clock? So if I change the processor PLL I should change the number 1000.0 as well, Am I correct? And from my searching, the number 1757 is "The industry has adopted the VAX 11/780 as the reference 1 MIP machine. The VAX 11/780 achieves 1757 Dhrystones per second".

Microseconds, Dhrystones_Per_Second will depend on the processor clock, while Normalized MIPS/MHz should be constant (or could be vary a little bit) regarless of the processor clock, am I correct?

Thanks a lot.

Got it. Thanks Eric.

Hi Eric,

The comments in the file performance_unit.s says that ARM_CCNT_Read returns the clock value divided by 64 cycles. Is it the case?

If yes then the total cycles on ARM should be multiplied by 64, is it correct?

Another issue is that, could you please explain more on the float printing issue? Any solution for that? We may need to print in float number for verification. Actually my existing project can print float number, but I compare the two project and cannot find any setting different.

Thanks.

Hi,

See this: https://developer.arm.com/documentation/ddi0438/c/performance-monitor-unit/pmu-register-descriptions/performance-monitor-control-register

Please check the bit 3: D-bit setting in the code. ORR R0, R0, #0x5, D-bit is 0 ========> so counts every cycle.

2) For me, floating point in some project print and didn't print on others. I didn't track why. I will ask my colleague if they know. Good to know there is no such problem in your setup.

Regards, Eric

Hi Eric,

Thanks for your information.

I have added my testing code to your sample project (For DPS, since it is not BIOS project, I replaced it by my BIOS project and run the drystone test, I can get the similar result with you project). my observation is that:

• DSP timing is more consistent than ARM.
• DSP timing is larger than ARM, even the test code only involve calculation.

Could you please advise how to exlpain the result, as we all know DSP calculation speed should be better than ARM? For the ARM timing, anyway to improve the consistency for the Real-time Application?

My test result and test project are as below. Thanks a lot.

WS_66AK2_Calc_W_Drystone_200709.zip

Hi,

Is that correct the figure you showed above is the cycles for your calc_test() and calc_test2()? This is not the Dhrystone?

You test is data addition and multiplications and math functions in generic C code. I'm not sure the performance with such algorithm C66x vs A15. Maybe this is what you can get, or you can check how many cycles spends on each steps to understand which consumes more cycles. DSP code can be optimized with intrinsic which will greatly improve the performance, but this needs expertise.

ARM A15 is a supersclar and in order instruction execution is not guaranteed. That may be the reason you see the fluctuation. You can add ARM barrier like dsb, imb, dmb to see if helps.

Another angle is for you to check the A15 instruction cache and data cache usage, to see if any cache missing caused this. Your test code is small and it should fully cached, but I am not sure as you didn't delete the Dhrystone code, which was also runs.

Regards, Eric          

Hic Eric,

Yes, they are calculation function time, not Dhrystone.

Could you please could you please elaborate more on ARM barrier like dsb, imb, dmb, and A15 instruction cache and data cache usage. Or is there any document I can refer to?

Thanks a lot.

Hi Eric,

The 2 function is already very simple (e.g. contains those operations like +-*/ or math functions like sin/cos/pow/sqrt), so I wonder if breakdown the timing could help to understand more.

I search online, but I still do not under stand how those mentioned methods (ARM barrier, I cache and D cache usage). May I know if those technique is used on your benchmark program between DSP and ARM?

Could you please help to confirm if my observation in previos post is correct? I feels very supprise as this conflict with what we know about DSP and ARM. And could you please provide the explaination on this result also?

Further more, I also see some part on DSP can be improved using intrinsic (for example for loop, some addition/multiplication operation), but for those math function, the only way to optimize is to use MathLib, am I correct? My DSP project should already use MathLib.

Thanks a lot.

Hi Eric,

Just suplement, the most important topic is why in my test result, the ARM is faster than DSP. Is it expected. So I would appreciate your help on the conclusion and exlaination on this topic.

For the fluctuation on the ARM, it is also important but not as high priority as the performance comparation between DSP and ARM. Sorry if my previous post is not clear.

Thanks a lot.

Hi,

Here is what I got on K2H DSP and ARM for your benchmarking algorithms:

Yes, with conventional C code, C66x is slower than A15. (My C66x for rgu32TimeSpend2 is even slower than yours for some reason, also the C66x showed fluctuation).

Regards, Eric

Hi Eric,

Can we have a clear explaination on this result?

Or can you share the source of benchmarking program that shows DSP is faster than ARM, to gether with your test result (e.g. program used in document SPRAC13, or any similar)?

Thanks a lot.

Hi,

The test code we both tried is generic C code. To improve the performance we need to rewrite with C66x intrinsic and use the MATHLIB for those math functions. 

When we use include <math.h>, those functions come from C66x run time library (rts6600_elf.lib), not the MATHLIB. 

I am checking if we have the code for SPRAC13.

Regards, Eric 

Hi Eric,

I rebuilt MathLib with OVERRIDE_RTS flag and put mathlib.ae66 above lib.a, so when the same interface with normal funtion is used, it still be repalced by coresponding function from MathLib. We can vefiry it by the map file.

Thanks.