仅仅实现编译器是不够的。你需要非常聪明的优化，其中大部分只在非常特定的情况下和有限的时间窗口内有效。JIT编译器在这方面很容易，因为它们可以在运行时生成专门的代码（这是它们的全部目的），可以通过观察程序运行来更轻松（更准确地）分析程序，并且在优化失效时可以撤消优化。与预先编译的编译器不同，它们还可以与解释器交互，并经常这样做，因为这是一个明智的设计决策。我想这就是为什么人们将它们与解释器联系起来的原因，尽管它们可以独立存在。
除了优化解释器代码本身之外，还有其他方法可以使Python实现更快，例如HotPy（2）项目。但是，这些方法目前仍处于研究或实验阶段，并且有待证明它们对真实代码的有效性（和成熟度）。
当然，一个特定程序的性能更多地取决于程序本身而不是语言实现。语言实现仅设置了一系列操作的速度上限。通常情况下，你可以通过避免不必要的工作来提高程序的性能，即通过优化程序。无论你是通过解释器、即时编译器还是静态编译器运行程序，这都是正确的。如果你想让某些东西运行得更快，不要费力去寻找更快的语言实现。有一些应用程序由于解释和动态性的开销而不可行，但它们并不像你想象的那样常见（通常通过调用机器代码编译的代码进行选择性解决）。
源代码 -> 字节码 -> 本机代码，然后微处理器将其解释为微代码... - Noctis Skytower目前唯一支持JIT的Python实现是PyPy，PyPy同时支持Python 2和Python 3。
Numba项目应该能够在Python 3上运行。虽然它不完全符合您的要求，但您可能想尝试一下：https://github.com/numba/numba/blob/master/docs/source/doc/userguide.rst。
目前它不支持所有的Python语法。
这个问题最好由这个网站上一些出色的Python开发人员来回答。
不过我想评论一下：当讨论解释语言的速度时，我喜欢指向一个托管在此位置：计算机语言基准测试游戏的项目。
这是一个致力于运行基准测试的网站。有指定的任务要完成。任何人都可以用自己喜欢的语言提交解决方案，然后测试比较每个解决方案的运行时间。解决方案可以进行同行评审，经常会被其他人进一步改进，并且结果会与规范进行检查。从长远来看，这是比较不同语言的最公平的基准测试系统。
正如你可以从类似于这个的指示性摘要中看到的那样，编译语言相对于解释语言而言非常快。但是，差异可能不在于确切的编译类型，而在于Python（以及图表中比Python慢的其他语言）是完全动态的。对象可以即时修改。类型可以即时修改。因此，某些类型检查必须推迟到运行时，而不是编译时。
因此，虽然你可以争论编译器的好处，但你必须考虑到不同语言中的不同特性。这些特性可能会带来内在的代价。
最后，在谈论速度时：大多数情况下，导致问题的不是语言和语言的感知缓慢，而是糟糕的算法。我从来没有因为一种语言太慢而不得不切换语言：当我的代码存在速度问题时，我修复算法。然而，如果你的代码中有耗时的、计算密集型循环，重编译它们通常是值得的。一个著名的例子是用C编写的库，被脚本语言使用（Perl XS库，或例如numpy/scipy用于Python，lapack/blas是许多脚本语言可用绑定的库的示例）
multiprocssing或threading模块进行并行化，或者使用C语言编写扩展（可以借助 cython 或类似软件来简化）。 - James