解释器 – llvm / tools：lli REPL与LuaJIT相比

发布时间：2020-12-15 00:24:58 所属栏目：大数据来源：网络整理

导读：我想知道是否有人有llvm / tools – lli interpreter / JIT-compiler(参见 http://llvm.org/docs/GettingStarted.html#tools)的经验.我对您可以提供的任何信息感兴趣(速度,复杂性,实现等). 谢谢. 更新：好吧,假设lli充当解释器,如何将bitcode执行与LuaJIT V

我想知道是否有人有llvm / tools – lli interpreter / JIT-compiler(参见 http://llvm.org/docs/GettingStarted.html#tools)的经验.我对您可以提供的任何信息感兴趣(速度,复杂性,实现等).

谢谢.

更新：

好吧,假设lli充当解释器,如何将bitcode执行与LuaJIT VM执行进行比较？当lli充当jit-compiler(同样的比较)时呢？

注意：
我只是问是否有人有经验/愿意花些时间分享.

解决方法

LuaJIT是一个跟踪JIT,这意味着它可以重新优化自身以更好地套接通过执行环境传递的数据,但是,LLVM是一个静态JIT,因此只会生成相应的一次性最佳机箱代码来源,这可能导致它在紧密循环或坏分支错误预测中失去性能.

实际的LuaJIT VM也是高度优化的,线程化的,特定于机器的程序集,其中LLVM使用C来实现可移植性(以及其他原因),因此这显然给LuaJIT带来了巨大的优势. LLVM也比LuaJIT具有更高的开销,纯粹是因为LuaJIT设计用于功能较弱的系统(例如由ARM CPU驱动的系统).

LuaJIT字节码也是专为LuaJIT设计的,因为LLVM的bitcode更通用,这显然会使LuaJIT的执行速度更快. LuaJIT的字节码也非常适合编码优化提示等,供JIT和跟踪器使用.

忽略了这两种不同类型的JIT这一事实,整个比较归结为LLVM专注于成为通用的JIT /编译器后端,LuaJIT专注于以尽可能最快的方式尽快执行Lua,因此它从不受普遍性的限制.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!