【MicroPython】计算性能测试

dcexpert

【MicroPython】计算性能测试 [复制链接]

 一直有网友担心，MicroPython运行是否足够快，性能够不够用。所以我做了一个小测试，用python计算阶乘，看看速度到底会有多快，是否可以达到大家的期望值。

我们先编写一小段测试程序，这段代码先计算阶乘，然后计算总的耗时。测试程序如下：

1. import time
   
2. 
   
3. def fact(n):            
   
4.     r=1           
   
5.     t1=time.ticks_us()                     
   
6.     while n>1:                  
   
7.         r=r*n                 
   
8.         n=n-1                 
   
9.     t2=time.ticks_us()                          
   
10.     print('elapsed: ', time.ticks_diff(t1,t2), 'us')                                    
    
11.     return r
    

复制代码

我们先在小钢炮开发板上进行测试，它使用了STM32F401RE，最高主频84MHz，SRAM是64KB。

MicroPython v1.7 on 2016-04-17; CANNON with STM32F401xE
Type "help()" for more information.

>>> import fact_t
>>> n=fact_t.fact(100)
elapsed:  2534 us

>>> n=fact_t.fact(1000)
elapsed:  174353 us
>>> n=fact_t.fact(5000)
elapsed:  4223822 us
>>> n=fact_t.fact(10000)
Traceback (most recent call last):
  File "", line 1, in
  File "fact_t.py", line 7, in fact
MemoryError: memory allocation failed, allocating 6498 bytes


计算速度还不错，计算5000阶乘也只用了4.2秒。在计算10000的阶乘时因为SRAM不足而出错。因为python支持大数计算，所以计算的位数只受SRAM大小的限制。在进行大数计算的时候，数字范围远远超出了一般数据的范围，因此比较容易测试计算性能。

在换用PYBOARD进行测试，PYBOARD使用了STM32F405RG，它的最高主频是168MHz，SRAM达到192KB。运行同样的测试，结果如下：

MicroPython v1.7 on 2016-04-17; PYBv1.0 with STM32F405RG
Type "help()" for more information.
>>> import fact_t
>>> n=fact_t.fact(100)
elapsed:  1417 us
>>> n=fact_t.fact(1000)
elapsed:  108004 us
>>> n=fact_t.fact(5000)
elapsed:  2333655 us
>>> n=fact_t.fact(10000)
elapsed:  9839525 us
>>> n=fact_t.fact(20000)
Traceback (most recent call last):
  File "", line 1, in
  File "fact_t.py", line 7, in fact
MemoryError: memory allocation failed, allocating 16210 bytes


得益于更高的主频和大SRAM，计算用时缩短了接近一半，计算直到20000时才内存不足。最后在试试性能更好的STM32F746DISC，它使用了STM32F746NGH6，主频达到216MHz，SRAM有320KB。

MicroPython v1.8 on 2016-05-15; F7DISC with STM32F746                           
Type "help()" for more information.
>>> import fact_t
>>> n=fact_t.fact(100)
elapsed:  979 us
>>> n=fact_t.fact(1000)
elapsed:  45384 us
>>> n=fact_t.fact(5000)
elapsed:  1174590 us
>>> n=fact_t.fact(10000)
elapsed:  4386010 us
>>> n=fact_t.fact(20000)
elapsed:  18040829 us

>>> n=fact_t.fact(25000)
elapsed:  33982479 us
>>> n=fact_t.fact(30000)
Traceback (most recent call last):
  File "", line 1, in
  File "fact_t.py", line 7, in fact
MemoryError: memory allocation failed, allocating 49620 bytes




从上面的测试中，我们可以看出python的运行效率还是不错的，计算速度足以满足普通的应用。

dcexpert

附测试使用的fact_t.py

fact_t.zip (254 Bytes, 下载次数: 15)

2016-5-16 22:23 上传

点击文件名下载附件

suoma

谢谢，树莓派怎么样？

dcexpert

suoma 发表于 2016-5-16 22:46
谢谢，树莓派怎么样？

树莓派的CPU性能更好，当然会更快一些。

小T

谢谢分享   使用micropython 能够使用一些现成的（电脑上用的）py库么

dcexpert

小T 发表于 2016-5-17 22:09
谢谢分享   使用micropython 能够使用一些现成的（电脑上用的）py库么

应该是部分可以使用，两者还是有不少区别的。

5525

楼主厉害，还自己测了一把。
最近也在看MicroPython, 不知道怎么的看着看着，觉得MircoPython跟LUA有点像。
效率的话LUA要比MicroPython 好些

dcexpert

5525 发表于 2016-7-3 20:08
楼主厉害，还自己测了一把。
最近也在看MicroPython, 不知道怎么的看着看着，觉得MircoPython跟LUA有点像 ...

两者都是脚本语言，自然是有不少相似的地方。前两年有一个不错的ESP8266项目NodeMcu就是跑Lua的，可惜已经停止开发了。

虽说Lua更加小巧，可以在更低配置的MCU上运行，但是现在整体来说Lua的用户少，各种资源也远远比不上python。micropython的一个优势在于完成度很高，容易直接，很适合初学者，是Arduino进阶的最好选择。对于网络的支持也非常好，在以后物联网应用中会用很大空间。

allankliu

最初我看到NodeMCU，我一直以为他是Javascript引擎。结果是Lua。不知道为何是这样。

dcexpert

allankliu 发表于 2016-7-20 08:36
最初我看到NodeMCU，我一直以为他是Javascript引擎。结果是Lua。不知道为何是这样。

嵌入式的Lua出道很早，它很精简，占用资源少，但是因为比较小众，所以真正用起来比较麻烦，很多功能都没有。

ESP8266现在有Lua、micropython、js三种移植版本了，但是只有micropython的功能是最全的。

akljh

你好，我研究了下，，进行一加法要12us多，一次赋值也要几us。主频168M(MIPS=168M?)，怎么会这么慢。有没有加速的办法代码。按At89C51的24M,  MIPS=24M/12=2M, 一次NOP 0.5us ,感觉这板的速度连51机都比不上啊？

akljh

import pyb
n=1000
sum=0;
c=1
a=pyb.micros()
for i in range(n):
    sum = i
    c=i
    sum=c
b=pyb.micros()
print(a)
print(b)
print(b-a)
测试代码结果a=239697b=257088b-a=17391,(b-a)/1000=17.4us /3=4.+us,直慢，一次赋值就要4us

dcexpert

akljh 发表于 2017-5-5 04:32
import pyb
n=1000
sum=0;
c=1
a=pyb.micros()
for i in range(n):
    sum = i
    c=i
    sum=c ...

这个结果很正常，mpy需要先解析指令，然后在执行。看起来效率低，速度比51还慢，但是这是针对一般性指令的，对性能要求高的部分，可以用C语言完成，做成模块，内部直接调用。

mpy的优势不在这里，在于应用上。