… 这可能是一个不受欢迎的观点，但构建一个好的即时编译器（JIT compiler）很难，而且领导力很重要。我带着10多年的即时编译器经验以及一支技术娴熟的工程师团队启动了YJIT项目，而据我所知，Python即时编译器项目是由一名学生领导的。一开始YJIT要顺利运行是一场艰难的战斗。我们需要毅力，并且我坚持采用非常数据驱动的方法，这样我们就能从早期的失败中学习并做出明智的决策。你可以对此做出自己的判断。是的，Python很难优化。我仍然相信为CPython打造一个优秀的JIT是完全可能的，但它必须正确地完成。如果你想完成这个工作，可以雇佣我 :) 有关YJIT的几场演讲在YouTube上，有兴趣的人可以看看：https://youtu.be/X0JRhh8w_4I
源讨论对CPython的JIT编译器两年的思考原帖 96 条评论 · 导入时统计Ruby在语义和实现上都非常接近Smalltalk，它并不真正使用Python的对象模型，该模型可以概括为“一切都是带有字符串键的字典”。这使得过去40年中如何让Smalltalk和Lisp变快的各种技巧在Ruby中更加直接地适用。
完整原文把你的经验，加入这段讨论。
虽然我没有JIT开发的经验，但一直每周关注着CPython JIT的进展，我觉得他们的JIT策略有点奇怪。整个决定似乎围绕着不想嵌入一个外部JIT/编译器所带来的所有问题…… 起初我认为他们的解决方案非常优雅。我欣赏他们的方法，我自己也可能被这种方案所吸引。但到目前为止，我认为这可能是一种沉没成本谬误。JIT距离提供显著的改进还很远，而且在CPython更快的社区中似乎没有人能说出这个基础方法可能无法达到最佳结果。 我要么希望我错了，要么希望CPython更快的管理团队对JIT有比我更好的愿景。
完整原文感谢你的回复，Maxime，你在YJIT上的工作令人印象深刻。YJIT带来的速度提升比cRuby或MJIT要好很多，而且相比Python，它在相对较短的时间内就完成了这项工作，而Python似乎一直在谈论这个JIT，但我们从未看到类似的发布。
完整原文嗨Maxime！ > 据我所知，Python的JIT项目是由一名学生领导的。 我绝对不是团队的领导者！我坦白说，我根本不具备这个资格，哈哈。团队主要由Mark Shannon领导，他有10年以上编译器/静态分析的经验。我最初只领导了JIT的优化器实现。选择追踪、使用复制和修补等整体设计都是其他人的想法。 > 但是他们决定忽视我的建议，采用他们自己的未经证实的方法。 你的建议非常受欢迎，我确实没有忽视你的建议。我只是对最初架构选择的决定权不大。我们正在根据数据慢慢改变JIT，但就像你所说的，这是一场艰难的战斗。如果你感兴趣的话，它正在慢慢变得像懒惰的基本块版本 https://github.com/python/cpython/issues/128939 你在Y方面做得很好…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。