math efficiency?

[jpc]

in the process of checking performances between PIC family's i noticed that the math-efficiency on the dsPIC compiler is rather poor, in fact a modern P18 on 64 mHz can outperform a 80 mHz clocked P33 in simple divisions/multiplications of real variables which seems not correct to me.

Code: Select all

program MyProject;
// comparison of simple math efficiency, score's are in cpu-cycles

var r_a,r_b,r_c : real;

begin                         //  P18         P33         P32MX

  r_a := 1.23456;             //  10          15          3
  r_b := 98765.4321* tmr2;    //  116         229         55
  r_c := r_a / r_b;           //  50          400         36
  r_c := r_a * r_b;           //  48          128         35
  r_c := tan(r_a);            //  10932       9208        3195
  
end.

[kjm]

in the process of checking performances between PIC family's i noticed that the math-efficiency on the dsPIC compiler is rather poor, in fact a modern P18 on 64 mHz can outperform a 80 mHz clocked P33 in simple divisions/multiplications of real variables which seems not correct to me.

Code: Select all

program MyProject;
// comparison of simple math efficiency, score's are in cpu-cycles

var r_a,r_b,r_c : real;

begin                         //  P18         P33         P32MX

  r_a := 1.23456;             //  10          15          3
  r_b := 98765.4321* tmr2;    //  116         229         55
  r_c := r_a / r_b;           //  50          400         36
  r_c := r_a * r_b;           //  48          128         35
  r_c := tan(r_a);            //  10932       9208        3195
  
end.

Any comment from ME about this compare test??

[sasa72]

dsPIC version seems to use native IEEE-754 for 32-bit floating point, meaning sign bit is in front 8-bits exponent, which assume constant shifting and masking and accordingly can be expected some speed decreasing, however not 4x efficiency drop. Compensation using 16-bit CPU also should be significant, thus obviously is some overlook or bug during code optimization.

[zristic]

Yes, soon. We are testing it.

[mileta.miletic]

Hi,

There is bug in conversion to float routine in dsPIC and it will be fixed for the incoming release. If you check the above example in the simulator, the tmr is 0 on start, and r_b variable is zero, and you have early exit on multiplying and division by 0. Due the bug in conversion in dsPIC that was not the case, r_b variable wasn't 0, and that is why you had such big difference.
For good performance testing, random numbers should be used in measurement in order to cover all possible branches in floating point routines.

[sasa72]

Mileta,

I suppose you refer on bug in conversion to standard IEEE-754. Otherwise, testing with sqrt(2.) instead tmr the problem with efficiency persist.

[mileta.miletic]

Mileta,

I suppose you refer on bug in conversion to standard IEEE-754. Otherwise, testing with sqrt(2.) instead tmr the problem with efficiency persist.

It was problem in preparing arguments before conversion. For good performance testing of floating point arithmetics, a large set of random input numbers should be used.