为什么不给Python这样的解释语言写一个编译器?
时间:2021-07-01 10:21:17
帮助过:76人阅读
如题。解释语言性能比较差,为什么一个语言不能既有编译器又有解释器?这样可以在需要性能的时候编译它。
我刚开始涉足计算机科学,工科生,轻喷…
回复内容:
CPython是会编译成bytecode的,见pyc文件。其他JPython,IronPython也都是编译成特定bytecode的。pypy还能进一步JIT编译成machine code。
性能主要问题不是编不编译造成的,是动态类型系统以及各种额外的abstractions造成的。
题主是想问2c-python -
2C.py这种静态编译器么?
类似的脑洞当然不可能只有一个人开。看还有Nuitka,作者还很兴奋:Static Compilation - That is the point. <- 请结合上下文看:A static Python compiler? What's the point?
其他脑动请参考Python官网wiki上的列表:PythonImplementations
很高兴告诉你,python不是单纯的解释性语言。 我们平时所说的python解释器其实是Cpython,在执行的时候,python会先将.py文件编译成中间形式的字节码(bytecode)并存放在内存当中,然后在正真执行的时候将字节码解释为机器可识别的二进制码。
默认情况下,被import的文件编译出字节码会被保存下来,即我们看到的.pyc文件了。当然我们可以显示的编译一个.py文件并保存。
静态语言编译出的是二进制文件,也就是说,打从编译结束后,执行这个文件,机器怎么运行是已经确定好的事情了。
而python是一门动态语言,比如语句a+b,在执行它之前,你丫的根本就不知道a和b是什么,是执行整数运算呢?还是浮点数运算?要知道,一般的计算机,执行整数运算和浮点数运算的运算单元是不一样的。
所以,动态语言你怎么去完全编译它?python已经做得很不错了。
如果你是比较纯正的python,即没有太多的第三方库,可以考虑使用pypy解释器。不过pypy对大部分第三方库支持力度不够。比如强大的科学运算库numpy就未支持,当然,支持的日子相比不会太长远。
而且,大部分速度的瓶颈跟语言关系不大,而是在于算法。实在不行,考虑使用C/C++或者CUDA加速才是王道。
第一次码这么多字,真是累。。。。
更新:
@kalam yum提到了numpy有专门的Pypy版本,官网上也确实提供了下载链接。不过支持力度不够啊,想下下来使用一下,发现根本下不下来,似乎是我这个烂网络的原因。暂时我是不会考虑使用PyPy。
还有网上有人提到了结合CPython和PyPy的方法:
https://github.com/fijal/jitpy
没有试,大家可以看下。
目前看来,还是那句话:
使用C/C++或者CUDA加速才是王道。
使用C/C++或者CUDA加速才是王道。
使用C/C++或者CUDA加速才是王道。
学习Python的同时,学习C/C++和CUDA,何乐而不为?
因为python是一门动态语言。很多特性要依赖于程序元数据。所以即使编译成机器码,还是需要带运行时,垃圾回收器,程序本身的元数据。编译成机器码可能在数值运算方面的性能会得到提升,但其他方面未必会得到显著的性能提升。
编译为机器码,其实类似于pypy那种jit,只是把编译结果保存起来而已。
其实除了科学计算大部分用得上python的场景都不在乎它的性能。
( 抖个机灵
Cython: C-Extensions for Python
你说这个?
Python不是单纯的解释型语言,所以可以认为它的所谓解释器即普遍意义上的编译器。这个问题就像马为什么不像人躺着睡觉一样,躺着多舒服。