topic Kinetis K60 FPU Benchmark in Kinetis Microcontrollers

Kinetis K60 FPU Benchmark

mon3al — Wed, 12 Mar 2014 19:59:06 GMT

Hi, I'm using the TWR-K60F120M Tower module. I have the FPU enabled 'FPU with hard vfp passing' and ''c9x' model. I have code that performs 100,000 floating point adds in a loop. The results are as follows:

Kinetis FPU enabled ~120ms

Kinetis No FPU (software) ~500ms

Coldfire MCF52259CAG80 ~150ms

Does these numbers seems resonable. I guess I was expecting the Kinetis to be a magnitude better than the Coldfire (which does not even have an FPU). Can the Kinetis w/FPU be only marginally better that the Coldfire libraries, or do I have something not configured correctly?

Re: Kinetis K60 FPU Benchmark

egoodii — Thu, 13 Mar 2014 15:36:44 GMT

Like MOST ARM instructions, the ARM website claims that most floating-point operations require 1 clock (subject to a number of caveats, of course, relative to access modes, pipeline, etc.) except: divide/sqrt at 14, and some 'dual operation' at 3, etc. I assume you are running at 120Mhz, so your 1.2us/loop indicates 144 clocks per loop. I would be curious what the assembly-code of this loop looks like! Certainly there should be a 'VADD' in there, that takes 1 clock. Note of course Cortex M4F is only a 'single precision' instruction set.

Re: Kinetis K60 FPU Benchmark

mon3al — Fri, 14 Mar 2014 17:12:30 GMT

Here is the assembly listing....

for (i=0; i<100000; i++)

a: f04f 0300 mov.w r3, #0

e: 603b		str r3, [r7, #0]
10: e00b		b.n 2a <main+0x2a>
		f1 = f1 + 1.76f;

12: ed97 7a01 vldr s14, [r7, #4]

16: eddf 7a09 vldr s15, [pc, #36] ; 3c <main+0x3c>

1a: ee77 7a27 vadd.f32 s15, s14, s15

1e: edc7 7a01 vstr s15, [r7, #4]

Re: Kinetis K60 FPU Benchmark

egoodii — Fri, 14 Mar 2014 19:42:30 GMT

I don't see the 'end of loop' but I assume it is 'right there'. I have to agree that I see the 'proper' list of single-precision floating-point instructions there, which counting clocks per ARM should come out to about 10 per loop here in those instructions -- so 100K cycles should take only a million clocks, or about a 1/120th of a second here (8 [maybe 11 with overhead] milliseconds)! I am baffled -- we should certainly see the 'order of magnitude' performance increase you were expecting! Unfortunately, I don't have any 'F' Kinetis CPUs myself to play with...

Re: Kinetis K60 FPU Benchmark

egoodii — Thu, 20 Mar 2014 14:26:30 GMT

Found some hardware, did my own little 'test' summing an array of 10,000 single-precision floats using RAM code and IAR tools. First, an 'optimized' software-loop took 1.7ms. Then after manually enabling the FPU (what's up with THAT?) the same add of all elements in a 10,000-word array dropped to 0.5ms. Not the 'factor of 10' you would dream of, but in such a loop the floating-point operations are now a 'smaller percentage' of the overall instruction count--even with the IAR optimization for some un-rolling that makes the loop look like this, where only 1/4 of the instructions are 'VADD' (8 per outer loop):

for( uint32_t i=sizeof(Farray)/sizeof(float);i>0;i--)

0x1fff1958: 0x4638 MOV R0, R7

0x1fff195a: 0xf240 0x41e2 MOVW R1, #1250 ; 0x4e2

accum += Farray[i];

??main_2:

0x1fff195e: 0x19aa ADDS R2, R5, R6

0x1fff1960: 0xed92 0x0a00 VLDR S0, [R2]

0x1fff1964: 0xedd0 0x0a00 VLDR S1, [R0]

0x1fff1968: 0xee30 0x0a20 VADD.F32 S0, S0, S1

0x1fff196c: 0x1f02 SUBS R2, R0, #4

0x1fff196e: 0xedd2 0x0a00 VLDR S1, [R2]

0x1fff1972: 0xf1a0 0x0208 SUB.W R2, R0, #8

0x1fff1976: 0xee30 0x0a20 VADD.F32 S0, S0, S1

0x1fff197a: 0xedd2 0x0a00 VLDR S1, [R2]

0x1fff197e: 0xf1a0 0x020c SUB.W R2, R0, #12 ; 0xc

0x1fff1982: 0xee30 0x0a20 VADD.F32 S0, S0, S1

0x1fff1986: 0xedd2 0x0a00 VLDR S1, [R2]

0x1fff198a: 0xf1a0 0x0210 SUB.W R2, R0, #16 ; 0x10

0x1fff198e: 0xee30 0x0a20 VADD.F32 S0, S0, S1

0x1fff1992: 0xedd2 0x0a00 VLDR S1, [R2]

0x1fff1996: 0xf1a0 0x0214 SUB.W R2, R0, #20 ; 0x14

0x1fff199a: 0xee30 0x0a20 VADD.F32 S0, S0, S1

0x1fff199e: 0xedd2 0x0a00 VLDR S1, [R2]

0x1fff19a2: 0xf1a0 0x0218 SUB.W R2, R0, #24 ; 0x18

0x1fff19a6: 0xee30 0x0a20 VADD.F32 S0, S0, S1

0x1fff19aa: 0xedd2 0x0a00 VLDR S1, [R2]

0x1fff19ae: 0xf1a0 0x021c SUB.W R2, R0, #28 ; 0x1c

for( uint32_t i=sizeof(Farray)/sizeof(float);i>0;i--)

0x1fff19b2: 0x3820 SUBS R0, R0, #32 ; 0x20

0x1fff19b4: 0xee30 0x0a20 VADD.F32 S0, S0, S1

0x1fff19b8: 0xedd2 0x0a00 VLDR S1, [R2]

0x1fff19bc: 0x19aa ADDS R2, R5, R6

0x1fff19be: 0x1e49 SUBS R1, R1, #1

0x1fff19c0: 0xee30 0x0a20 VADD.F32 S0, S0, S1

0x1fff19c4: 0xed82 0x0a00 VSTR S0, [R2, #0]

for( uint32_t i=sizeof(Farray)/sizeof(float);i>0;i--)

0x1fff19c8: 0xd1c9 BNE.N ??main_2 ; 0x1fff195e

The total instruction count in the loop is 30, and 1250 iterations is 37,500 total instructions. At 120MHz, that would 'ideally' have taken 0.3ms assuming 1 clock each, so I suppose we can 'write off' a 40% 'clock overhead' in RAM access and pipeline stalls.

So the 'bottom line' is that a factor-of-four may indeed be about what improvement you can expect in an overall compute-intensive sequence -- and what THAT means is that the 'software library' is actually pretty darn good(!) -- like 10 to 15 clocks for the single-precision add.

Some other benchmarks with the same loop:

32-bit integers 0.9ms(???) -- Must be RAM code-fetch getting in the way??? From ROM = 0.3ms. SP float from ROM = 2.2ms.

And not surprisingly double-precision float (double) takes 5.5ms with or without FPU, so apparently a SP FPU is of 'no help' in double-float math. Double from ROM takes3.2ms

Re: Re: Kinetis K60 FPU Benchmark

bowerymarc — Fri, 28 Mar 2014 21:12:45 GMT

> after manually enabling the FPU (what's up with THAT?)

Try adding this define to your compiler preprocessor defines:

__VFPV4__

I was having problems compiling <cmath> and other issues, and doing that seemed to have solved it... and it looks like __fp_init() is defined in with that symbol in __arm_eabi_init.c