这对我来说很难弄清楚如何正确提问。
例如，Python解释器是用C编写的。假设您用Python编写了另一个解释器，该解释器是通过CPython编译的。然后，您打算通过解释器运行程序。该代码是否必须先通过您的解释器，然后再通过CPython？还是新的解释器是独立的，并且不需要CPython来解释它的输出。因为如果它不是独立的解释器，则将导致性能损失，在这种情况下，似乎所有编译器都将以低级语言编写，直到时间结束为止
编辑：PyPy正是让我对此主题感到疑惑的一件事。我给人的印象是它是用Python编写的解释器，而且我不明白它可能比CPython更快。我也不理解字节码如何在不转换为机器码的情况下由机器执行，尽管我认为这是另一个主题。
您似乎对编译器和解释器之间的区别感到困惑，因为您在问题中都引用了两者而没有明显的区别。 （很容易理解。。。。。。）
[编译器和解释器虽然不是全部，但在某种程度上是正交的概念：
编译器获取源代码并生成可以更有效地执行的形式，无论是本机代码还是中间形式（如CPython的字节码）。
c可能是几乎总是被编译为本地机器代码的语言的规范示例。确实，该语言是[[designed
，可以相对容易和高效地转换为机器代码。 RISC CPU architectures在已经很好地用于操作系统编程的C语言之后变得很流行，并且通常被设计为使其[[更加有效可以将C的某些功能转换为机器代码。因此，C的“可编译性”已成为自我增强。很难引入一种新的体系结构，在该体系结构上很难编写能够充分利用硬件潜力的良好C编译器（例如Itanium）。如果您的CPU不能高效地运行C代码，那么它就不能高效地运行大多数操作系统（Linux，Unix和Windows的低级位主要用C编写）。口译员传译器传统上被定义为试图直接从其源代码表示形式运行源代码的程序。过去，BASIC的大多数实现都是这样工作的：BASIC会通过循环从字面上重新解析每次迭代的每一行代码。
现代编程语言和平台模糊了
CPython的字节码是可以解释的，但是解释的开销要低得多，因为该代码是预先完全解析的（并保存在.pyc文件中，因此在修改之前不需要重新解析）。
某些通过字节码解释器或JIT编译器“传统上”运行过的语言也适用于ahead-of-time compilation。例如，以前版本的Android中使用的Dalvik VM依赖于即时编译，而Android 4.4引入了ART，它使用提前编译。
Python的中间表示形式
这是一个很棒的线程，它包含@AlexMartelli的useful and thoughful answer，它是由Python的各种实现生成的较低级编译形式的。
A
因此，如果传统的解释器在解释器下运行，而其本身在解释器等下运行，则...会导致性能下降，就像在VM下的VM下运行VM（虚拟机）一样会比在“裸机”上运行慢。对于编译器而言并非如此。我可以编写一个在解释器下运行的编译器，该解释器在已经由编译器编译过的解释器下运行……等等。生成的编译器可以生成与任何其他编译器生成的本地代码一样好的本地机器代码。 （认识到编译器本身的性能可以完全独立于已执行代码的性能，这一点很重要；积极的优化C编译器通常比非优化编译器花费更多的时间来编译代码，但是这样做的目的是为了生成的本机代码运行速度明显加快。）