# Float Speed Espruino Pico VS Pyboard

Posted on
• Hello Forum,

this little test may neither be fair nor exact but i still wonder about the outcome...

The Leibniz Formula is a little float Problem for calculating Pi.

I wrote the code in Python and Javascript and let it run on the PyBoard and the Espruino Pico.

Here‘s the Python-Code:

``````import time

iterations = 1000000

x = 1
pi = 1
start = time.time()
for i in range(2, iterations + 2):
x = x * -1
pi = pi + (x / (2*i-1))

pi = pi * 4
print('Pi: ' + str(pi))
end = time.time()
print('Time taken for ' + str(iterations) + ' Iterations: ' + str((end - start)*1000000) + ' Mikroseconds')
``````

And here‘s the „same“ in Javascript:

``````var iterations = 1000000;

var x = 1;
var pi = 1;
var begin=Date.now();
for (i = 2; i < iterations + 2; i++) {
x = x * -1;
pi = pi + (x / (2*i-1));
}

pi = pi * 4;
console.log('Pi: ' + pi);
var end= Date.now();
console.log('Took ' + ((end-begin)*1000) + ' Microseconds');
``````

On the PyBoard the code took 26 seconds to execute, the Pico took 458 seconds.

I‘m a little puzzled of the outcome because I though both boards have floating point hardware, or am I wrong?

Can anyone explain the massive speed difference to me?

Thomas

PS: I know that this synthetic benchmark has nothing to do with overall speed, I just want to understand why these numbers are what they are in this particular case.

• In my opinion you really can't compare hardware if you have to use different languages.
I know that you have no other choice and the code snippets are as close as they can be in the relevant parts. But you can not level out the differences the language itself brings to the table.

Right now the test is maybe telling more about the advantages of python then about the floating point capabilities of the underlying hardware.

• Hello, you could have a look at this http://forum.espruino.com/conversations/­265821/ .
More specifically this post http://forum.espruino.com/comments/12435­986/
Also there are the pages about:
compiling espruino's javascript, which is simple, http://www.espruino.com/Compilation,
assembler, which I find tricky, http://www.espruino.com/Assembler,
performance, suggestions about writing efficient code, http://www.espruino.com/Performance .
As far as I can remember, Espruino does not use hardware floting points computation in order to run on very small flash memory size. See here http://forum.espruino.com/comments/12613­170/ Espruino floats are 64 bits.

Also micropython is compiled in bytecode so, that's not really fair per opposition to fully interpreted approach of espruino: you can have dynamically written code in strings and then convert them to executable code on the fly.

Dig a bit in this forum.

• The wipy 1.0 has no floating point at all and that's a micropython supported board.

• Just now, I am testing this with a "compiled" directive.
Simple changes are: code inside very identical functions, except that the compiled one needs to declare the i variable.
Results are:

compare()
Starting non compiled espruino pi at 1514037569001.04614257812
Pi: 3.14159365358
Took 446121180.6640625 Microseconds for 1000002 iterations
Starting COMPILED espruino pi at 1514038015123.26708984375
Pi: 3.14159365358
Took 36048217.7734375 Microseconds for 1000002 iterations
=0

So there is a speedup of a factor 12 to using the "compiled" directive.
I had experimented a comparable speedup in a gps checksum computation 2 years ago.
See here

``````function testcompiled() {
"compiled";
var iterations = 1000000;
var x = 1;
var pi = 1;
var i=2; // required for compiler
var begin=Date.now();
console.log("Starting COMPILED espruino pi at", begin);
for (i = 2; i < iterations + 2; i++) {
x = x * -1;
pi = pi + (x / (2*i-1));
}
pi = pi * 4;
console.log('Pi: ' + pi);
var end= Date.now();
console.log('Took ' + ((end-begin)*1000) + ' Microseconds for ' + i + ' iterations');
return pi;
}

function test() {
var iterations = 1000000;
var x = 1;
var pi = 1;
var begin=Date.now();
console.log("Starting non compiled espruino pi at", begin);
for (i = 2; i < iterations + 2; i++) {
x = x * -1;
pi = pi + (x / (2*i-1));
}
pi = pi * 4;
console.log('Pi: ' + pi);
var end= Date.now();
console.log('Took ' + ((end-begin)*1000) + ' Microseconds for ' + i +' iterations');
return pi;
}

function compare() {
return test() - testcompiled();
}

``````
• Yes - the Python interpreter in the Pyboard is significantly faster - Espruino was designed for much more constrained devices, so cares more bout memory usage and less about outright speed.

You're seeing a whole bunch of differences here...

• The pyboard has twice the clock speed - 168MHz vs 84MHz
• Micropython compiles to bytecode first (sometimes even native code), whereas Espruino interprets from source - which really hurts performance. You could try `E.setFlags({pretokenise:1})` at the start of your code to give you a bit of a speed boost though.
• JavaScript uses 64 bit floats for all numbers, which the built-in floating point unit in these chips is useless for - so it's all done in software. If Python uses 32 bit floats it'll have a huge advantage (but it may not be).

@asez using compiled code, all integer code will be very fast - however for floating point it falls back to Espruino's built-in maths library (because of the hassle of linking in all the double maths functions), so it'll suffer a performance hit too.

However it looks like clock-for-clock JS code with the compiled directive is still faster than standard MicroPython, which I'm pretty happy about. If you did a purely integer benchmark I imagine compiled JS would give you some really impressive figures.

• Hi, what my test above shown on the pico with some floats at least for pi computation, is:

1. uncompiled and not pretokenised: 446 s
2. compiled (84 MHz) : 36 s as opposed to ThomasChr result of 28 s on the pyboard (168 MHz)

I did not tried the tokenised functionnality.
Results are indeed in favor of Espruino Pico as it is only 84 MHz clocked.

This test could be rerun on Espruino Pico reflashed with Micropython as it has been ported to.
Porting Espruino to the Pyboard would eventually and symetricaly allow this comparison running on the Pyboard too
That would definitly be fair.

• Post a reply