ESP32-S3 四种执行方式效率对比：原生 / WebAssembly / Lua/Micropython 的 1000 位圆周率对决
为什么会有这个对比 最近在研究ESP32S3的基础系统和应用分离的开发架构，比较常见的应用层主要有这几种"形态"： 形态 本质 典型用途 原生动态模块(elf) 编译成目标芯片机器码 性能热区、协议栈、编解码 WebAssembly 应用(wasm) 编译成字节码，由运行时解释执行 沙箱隔离、第三方维护、生态复用 Lua 脚本(lua) 直接解释源码 热更新、胶水逻辑、低频控制 Micropython 脚本(py) 直接解释源码 与lua一致 它们共用一个应用包 / 部署 / 加载框架，但运行性能差多少，很少有人用同一把尺子量过。本文就用一个最经典的基准（计算 1000 位圆周率）在同一个设备上给四种形态做了一次公平对决。 测试怎么做到公平 同一台设备：ESP32-S3 R8（Xtensa内核，主频 240 MHz，8MB PSRAM, 16MB Flash） 同一种运行环境：应用都加载到PSRAM执行 同一个算法：四个实现是同一份 Rabinowitz-Wagon spigot 算法的直译 同一位数：都算 1000 位，输出结果逐位一致（小数位完全相同） 同一计时口径：只统计纯计算耗时，不含加载、初始化、日志输出 除了micropython直接在官方固件上运行，其他四种测试脚本各自封装成应用包，由设备启动计划自动拉起，开机即跑、跑完即退，互不干扰。 使用的算法：Rabinowitz-Wagon spigot “spigot”（水龙头）算法是一类逐位生成 π 的算法，像水龙头一样每拧一下流出一位数字。Rabinowitz-Wagon 是其中最经典的一种：用一组长整数数组做"长除法流水线"，每轮归约出一位。 伪代码（以 1 为下标）： 输入 n（要生成的位数） len = floor(10 * n / 3) a[1..len] 全部初始化为 2 nines = 0, predigit = 0 对 j = 1....