securd

After receiving my Due, I wanted to benchmark its numeric processing power as compared to the Mega. I was also interested in understanding which of my standard Arduino shields and gadgets were compatible with the 3.3v I/O of the Due.

Being a recovering physicist, what better test than to approximate pi, and periodically display the approximation results on 1638 display!

I utilized the slowly-converging Newton Approximation for pi, which does a reasonably good job of calculating pi / 4, using the infinite series 1 - 1/3 + 1/5- 1/7 + 1/9 - 1/11 +...

This is simple to express in Arduino C, and uses the floating point libraries to further assess performance. I tested a Due and a Mega, connected to a JY-LKM1638 V1.2 display module (which is based on the TM1638 controller chip). The times required to traverse 100,000 iterations were as follows:

There might be an imbalance between your tests as on a Uno/Mega double is only really a float (32 bits) but on the Due I think it is full double precision (64 bits). Try it again using float on the Due, you should still get 7 digits of precision out of it.

No, it's just a 'feature' of C++ which makes it quite hard to get it to do calculations as floats - basically any floating point constant is considered to be a double, then because the calculation has one double in it the whole thing gets done in double precision. To get round it you have to put f after the constants, ie: pi += x / (2.0f*(float)i-1.0f);I am getting 675ms for 100000 iterations (3.1416058540), although I have removed the display driver code.

Ok, well, this is strange. I changed all of the doubles to floats. The Mega had exactly the same time (which reinforces your point).

The official Arduino docs clearly state that for AVR, double is the same as float, likewise 32bit with 6-7 digits of precsion.

Quote

However the time for the Due actually went UP.

For due...double: 1785 msfloat: 2056 ms

I haven't had time to go through the floating point library, but do you suppose the Due handles all floating points as doubles by default?

As the Cortex-M3 core (on which the SAM3X used in the Due is based on) doesn't have a FPU (only the M4 has an optional 32bit FPU, and the M7 has an optional 32bit or 64bit FPU) and in order not to implement all functions to emulate FP operations in both 32bit and 64bit, it is probably safe to assume that all FP operations are indeed by default 64bit, eventually truncated to 32bit. That would explain the relatively small increase when using floats vs double on the Due, as each parameter and result has to converted to 64bit and back to 32bit...