JIT和非JIT对比

[linxiaolong]

实际跑下来（用真正的业务层复杂函数），且确保所调用的所有函数都被jit的情况下，最后结果和非JIT还是差不多，有其他没考虑到的可能性吗？

[fesily]

我粗看了这个jit实现,说的不对,欢迎作者批评.

这个JIT可以说说纯粹翻译成C调用Lua API,本质上去掉了VM的指令派发,其他应该跟原生的无任何差别.

这个工作15年前有人做过lua2c,结论是不会有太大的提升.

我不知道作者的最大7倍提升的benchmark是什么.

因为编译器根本不理解动态语言.

建议你直接换luajit.

不过作者做的NOGC还是很好的优化点,尤其是在大量使用不变lua配置的环境下

[Yu2erer]

我粗看了这个jit实现,说的不对,欢迎作者批评.

这个JIT可以说说纯粹翻译成C调用Lua API,本质上去掉了VM的指令派发,其他应该跟原生的无任何差别.

这个工作15年前有人做过lua2c,结论是不会有太大的提升.

我不知道作者的最大7倍提升的benchmark是什么.

因为编译器根本不理解动态语言.

建议你直接换luajit.

不过作者做的NOGC还是很好的优化点,尤其是在大量使用不变lua配置的环境下

使用了 mir 作为后端去优化

[fesily]

c2mir_compile不就是将C语言JIT吗?

这个工作流程我看了一下,就是直接翻译字节码到LUA C API,最后拼装了一份C的代码,扔进MIR编译一下.

本质上不就是去掉了VM的字节码派发吗,难道还有其他优化么,麻烦指出来.我可能遗漏了.

这种方式其实就跟V8的Sparkplug引擎差不多,直接翻译字节码,压根不追踪代码运行状态,不做任何条件假设. 不过好歹V8的堆栈是用的机器码,不是跟lua一样用堆模拟的.

[Yu2erer]

c2mir_compile不就是将C语言JIT吗?

这个工作流程我看了一下,就是直接翻译字节码到LUA C API,最后拼装了一份C的代码,扔进MIR编译一下.

本质上不就是去掉了VM的字节码派发吗,难道还有其他优化么,麻烦指出来.我可能遗漏了.

这种方式其实就跟V8的Sparkplug引擎差不多,直接翻译字节码,压根不追踪代码运行状态,不做任何条件假设.

不过好歹V8的堆栈是用的机器码,不是跟lua一样用堆模拟的.

看看mir吧。至于你说的其他类似inline cache优化确实是没有的。

[linxiaolong]

c2mir_compile不就是将C语言JIT吗? 这个工作流程我看了一下,就是直接翻译字节码到LUA C API,最后拼装了一份C的代码,扔进MIR编译一下. 本质上不就是去掉了VM的字节码派发吗,难道还有其他优化么,麻烦指出来.我可能遗漏了. 这种方式其实就跟V8的Sparkplug引擎差不多,直接翻译字节码,压根不追踪代码运行状态,不做任何条件假设. 不过好歹V8的堆栈是用的机器码,不是跟lua一样用堆模拟的.

看看mir吧。至于你说的其他类似inline cache优化确实是没有的。

你的意思是mir内部会根据热点路径来做类型具化减少类型判断等优化？ @fesily 说的我之前也是感觉到疑惑，因为确实除了指令派发其他都基本一样，所以认为jit常见的部分侦测mir会搞定。但实际跑起来确实没啥区别

[fesily]

你可以看看ravi,也是用的mir.

作者的博客今年2月code-specialization-mir-lightweight-jit-compiler动态去优化计划中,所以这个功能估计现在没有.

[Yu2erer]

你可以看看ravi,也是用的mir.

作者的博客今年2月code-specialization-mir-lightweight-jit-compiler动态去优化计划中,所以这个功能估计现在没有.

因为我自己一些想法的转变，这个项目已经不再继续维护了。