语言运行时编译器移动开发【免费下载链接】hermesA JavaScript engine optimized for running React Native.项目地址https://gitcode.com/gh_mirrors/hermes/hermes点击查看免费下载本文基于 Hermes 官方博客 2024 年 11 月 9 日的技术报告doc/blog/2024-11-09-octane-benchmark-jit-progress.md完整解读 Hermes 团队对非类型化untyped / legacyJavaScript的性能优化进展。文章以 Octane 基准测试为主线对比原版 Hermes、static_h 分支、static_h JIT 与参考引擎 QuickJS 在树莓派平台上的实测表现并结合当前仓库的 JIT 源码与后续博客数据帮助读者理解 Hermes JIT 的当前能力、测量方法与底层实现脉络。背景typed JS 之外的另一条战线Static Hermesstatic_h 分支的核心目标是让类型化 JavaScript达到接近原生的性能。但现实世界的 JavaScript 代码大量是非类型化的——未标注类型、未经过 Flow/TypeScript 注解的 legacy 代码在 React Native 生态中依然广泛存在。Hermes 团队在推进 typed JS 的同时并行投入了大量精力提升 untyped JS 的性能这篇 Octane 报告正是这条战线的进度快照。正如后续博客 Static Hermes Update, December 2024 所总结的尽管 Static Hermes 的首要目标是 typed JavaScript 的原生级性能但团队认识到大量 untyped 代码也必须被正确且高效地执行。而 Hermes Compilation and Runtime Modes 进一步说明Hermes 的编译/运行模式可以混合共存于同一运行时AOT 编译为字节码、AOT 编译为原生代码、字节码解释器、首次调用时的懒编译源码到字节码以及对高频执行函数做 Baseline JIT字节码到原生——本篇报告的 JIT 正是其中的 Baseline JIT。测试设计四种引擎配置、两个硬件平台本次基准测试的方法学设计如下维度配置被测引擎原版 Hermesmain 分支、static_h 分支解释器、static_h JIT、static_h 强制 JIT图例中标注为SH -Xforce-jit参考引擎QuickJS作为性能参考基线硬件平台Raspberry Pi 3 与 Raspberry Pi 5覆盖较大跨度的性能区间代码形态全部为 untyped、unannotated JS不使用 native backend即不走类型化 AOT 原生代码路径基准套件Octane分数越高越好一个重要的测试口径调整是TypeScript 基准被移除了原因是其分数过高会压扁图表中其他基准的对比效果。同时Octane 基准套件在仓库中的组织方式见 benchmarks/octane/README.md每个基准文件都被整理为单个完整可执行的文件并在文件末尾调用BenchmarkSuite.RunSuites触发运行其中gbemu.js合并了 part1/part2typescript.js合并了编译器与输入zlib.js则把原本通过eval()包裹的字符串体改写为print()直出后经 prettier 格式化。结果解读Raspberry Pi 3 与 Pi 5原报告提供了两张实测图表分别对应 Raspberry Pi 3 与 Pi 5。两张图横轴均为 Octane 的各单项基准Mandelbrot、Richards、DeltaBlue、Crypto、RayTrace、EarleyBoyer、Splay、NavierStokes、PdfJS、Mandreel、Gameboy、Box2D、zlib 等纵轴为 Octane 分数图例以不同颜色区分 QuickJS、Hermes、SH branch、SH -Xforce-jit 四种配置。从两张图表可以观察到横向对比在多数单项基准中开启 JIT 的 static_h 配置相对于原版 Hermes 均有明显提升部分高负载场景如 Gameboy、Box2D、Mandreel提升幅度尤为突出硬件差异Raspberry Pi 5 的整体分数显著高于 Pi 3可达数倍至十倍以上说明引擎优化与硬件算力在此类纯计算负载上是叠加生效的参考基线QuickJS 作为高质量、小体积且规范合规的参考实现见 2025-07-15-static-h-performance-june-2025.md 对 QuickJS 定位的说明在部分场景中仍保持领先这为 Hermes 的后续优化提供了明确的追赶目标。需要强调的是原文档明确指出Octane 在现代已不具备代表性但如果我们在更重要的场景上表现优秀而在 Octane 上表现糟糕那也是不可接受的——Octane 被当作性能下限的守门基准而非终极目标。纵深数据static_h 相对主分支的逐项提升倍数在同一主题的后续报告中Static Hermes Update, December 2024团队给出了 static_h 分支相对主 Hermes 分支的 Octane 提升倍数times x1 表示更快。Normal 列为解释器模式JIT 列为开启 JIT 后的结果最后三个基准是团队自加的定制项用于突出展示 JIT 在类型信息可用时的爆发力BenchmarkNormalJITRichards1.241.78DeltaBlue1.291.86Crypto1.341.91RayTrace1.722.07EarleyBoyer1.491.71RegExp1.201.20Splay1.221.33SplayLatency1.091.15NavierStokes1.501.87PdfJS1.681.78Mandreel1.381.69MandreelLatency1.361.42Gameboy1.361.68Box2D1.411.93zlib1.652.04Typescript1.281.46InterpDispatch1.662.97InterpDispatch21.587.90Mandelbrot1.253.29这份表格揭示了两个关键信息解释器本身也在进步绝大多数基准在纯解释器模式下就有 1.2x~1.7x 的提升这来自 static_h 分支对 untyped JS 的解释执行优化JIT 的放大效应取决于类型信息在 InterpDispatch27.90x与 Mandelbrot3.29x中编译器能够静态推断出大量类型JIT 因此获得数量级的加速。报告明确指出配合 typed JavaScript 时这些数字预计还会进一步攀升——这印证了 typed JS 与 untyped 优化是相辅相成的两条主线。源码侧支撑当前仓库中的 JIT 实现脉络报告中的 JIT 能力在当前仓库中可以看到完整的实现痕迹。JIT 的核心代码位于 lib/VM/JIT/顶层基础设施DiscoverBB.cpp基本块发现用于识别可 JIT 的函数控制流、RuntimeOffsets.h运行时对象字段偏移表、PerfJitDump.cpp配合 perf 的 JIT 符号转储用于性能分析arm64 后端lib/VM/JIT/arm64/ 是目前仓库中唯一的指令集后端包含JIT.cpp主控文件与一组按指令类别划分的发射器JitEmitter-alloc.cpp寄存器分配、JitEmitter-arith.cpp算术、JitEmitter-array.cpp数组、JitEmitter-call.cpp调用、JitEmitter-const.cpp常量、JitEmitter-control.cpp控制流、JitEmitter-env.cpp环境/闭包、JitEmitter-object.cpp对象、JitEmitter-property.cpp属性访问、JitEmitter-regalloc.cpp寄存器分配等以及JitHandlers.cpp/hJIT 处理函数入口。从源码结构可以推断这是一套面向 arm64 的字节码到原生代码的 Baseline JIT通过把解释器的热点函数按基本块切分DiscoverBB并逐类发射原生指令配合显式的寄存器分配regalloc与运行时字段偏移RuntimeOffsets来保证生成代码与 GC/解释器布局一致。这与 Hermes Compilation and Runtime Modes 描述的 Baseline JITbytecode to nativeof frequently executed functions 完全对应——即 JIT 只针对被频繁执行的函数触发与字节码解释器共存于同一运行时。此外仓库的 test/jit/ 目录下有 46 个 JS 测试文件用于验证 JIT 路径的行为正确性由于 JIT 是运行时后端的组成部分其测试同样依赖test/lit.cfg定义的标准测试运行框架。在仓库中复现与深入若想亲身体验 Octane 基准测试仓库已在 benchmarks/octane/ 内置了整套可独立执行的基准文件box2d.js、crypto.js、deltablue.js、earley-boyer.js、gbemu.js、mandreel.js、navier-stokes.js、pdfjs.js、raytrace.js、regexp.js、richards.js、splay.js、typescript.js、zlib.js 等并在 benchmarks/octane/README.md 中说明了这些文件的整理方式——它们来自 Octane 的 fork被修改为单文件可执行形态便于直接灌入 Hermes 的编译器/运行时进行测试。Octane 之外仓库还提供了更贴近现代工作负载的基准体系宏基准与微基准位于 agent-perf/benchmarks/配套的自动化测试位于 agent-perf/tests/关于 static_h 分支在 2025 年 6 月底相对 QuickJS 的最新性能形态hv32jit 与 hv32interpreter 两种配置可参阅 Static_h Branch Performance: June 2025 Update其中 hv32 表示运行时采用压缩指针并对超出 32 位标签的数值做堆内 boxed double详见 Hermes Memory Modes。结论与局限这篇 2024 年 11 月的报告是 Hermes JIT 路线图中的一个里程碑快照在纯 untyped、无注解的 JavaScript 上static_h JIT 相对原版 Hermes 在 Octane 全量基准上取得了普遍且显著的提升且提升幅度随可静态推断的类型信息增多而放大QuickJS 则提供了持续可比的参考基线。同时必须清醒认识其局限Octane 并非现代代表性负载报告中亦直言 Octane is not representative these days它衡量的是引擎性能的地板而非天花板。对 Hermes 而言JIT 的真正价值在于与 typed JS 协同——当类型信息充足时如 InterpDispatch2 的 7.90x 所示JIT 才能发挥最大威力。从该报告到 2025 年 6 月的 hv32jit 数据doc/blog/2025-07-15-static-h-performance-june-2025.md可以看到这条主线仍在持续推进。赞分享语言运行时编译器移动开发【免费下载链接】hermesA JavaScript engine optimized for running React Native.项目地址https://gitcode.com/gh_mirrors/hermes/hermes点击查看免费下载相关推荐从零到精通Hugging Face深度强化学习实战全攻略从零到精通Hugging Face深度强化学习实战全攻略 你是否曾经看着那些炫酷的AI游戏玩家想象着自己也能训练出如此智能的代理或者你是否在复杂的强化学习强化学习深度学习教程基于图像识别技术的鸣潮自动化工具完整配置指南基于图像识别技术的鸣潮自动化工具完整配置指南 鸣潮自动化工具ok ww是一款基于Python开发的游戏辅助工具采用图像识别技术实现后台自动化操作。该项目通GUI 自动化计算机视觉RPA人工智能终极性能对比RPiPlay在树莓派Zero到4B上的全面基准测试指南终极性能对比RPiPlay在树莓派Zero到4B上的全面基准测试指南 RPiPlay是一款开源的AirPlay镜像服务器专为树莓派设计支持iOS 9及以上音视频后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考