这是一个创建于 2778 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
realpg 2017-04-14 17:02:57 +08:00
就为了编译快？牺牲性能？
最快的应该是直接把源代码拷到 release 目录，直接把编译器压一起…… 执行时候再编译呗 |
 |
2
schezukNewTos OP @realpg 我其实是想了解，解释型语言为什么在某些场合比编译型语言有优势……
|
 |
3
em70 2017-04-14 17:07:27 +08:00 via Android
不就是 python 和 C 的区别么
|
 |
4
liuzhedash 2017-04-14 17:17:54 +08:00
@schezukNewTos #2
解释型语言开发效率更高 |
 |
5
BoBoy 2017-04-14 17:26:34 +08:00
@liuzhedash 但是执行效率更慢（始终比不上 C ，当然也要看使用场景，逃~
|
 |
6
zjqzxc 2017-04-14 17:26:48 +08:00
@schezukNewTos #2
解释性语言执行时才编译，可以实现一些编译性语言无法实现的"奇巧淫技" 例如： php 中的 extract()，可以实现把数组中将变量导入到当前的符号表（简单来说，就是把数组中的 key 作为变量名， value 作为值来“生成”一堆变量）； 解释性语言一般是执行一行编译一行，执行过程中用不到的可以先不编译，开发的时候可以提升效率； 跨平台时不用针对目标平台进行任何额外的工作 |
 |
7
tony601818 2017-04-14 17:44:24 +08:00
@schezukNewTos 解释型的用开发速度换运行速度，大概就是这个差别。
Python 这种上了 Cython ，配合合适的策略，速度不见得比纯 C 慢很多。 https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en |
 |
8
geelaw 2017-04-14 17:48:22 +08:00
不编译，直接放一个无限循环的程序上去，算吗？
|
 |
9
jybox 2017-04-14 22:22:46 +08:00
所谓「解释型」是算是基于「虚拟机」的语言的一种简易实现。但除了 CPython 这个异端之外，其他基于虚拟机的语言都多多少少转向了 JIT ，在一些特定场景下已经可以和本地代码（你们说的「编译型」语言大概就是这个意思吧，毕竟 JIT 也有编译环节）一较高下了，之所以和本地代码仍有差距的原因其实更多是因为这些语言往往是「动态类型」而且有 GC 。
楼上各位多多少少混淆了这些概念，可以看下我近期的一篇文章 https://jysperm.me/2016/12/categories-of-languages |
 |
10
ghostheaven 2017-04-14 22:52:12 +08:00 via Android
解释器在运行时会优化，极端情况下可以直接返回之前计算好的结果，而不必执行整段代码，这是编译型需要做不到的。
|
 |
11
soulshell 2017-04-15 04:48:27 +08:00
了解过 gcc llvm 的编译优化过程么？
v2 的人对 compiler 的了解仅限于此？ 所以也不过都是一帮二字套餐的 |
|
12
schezukNewTos OP @soulshell 愿闻其详。
|
 |
13
linux40 2017-04-16 10:01:01 +08:00 via Android
性能损耗和语言特性有关，比如 c++可以给你优化掉内存访问、分支、跳转、虚函数、异常、值返回等等所有特性，但不优化的话估计和比 Java 不带 gc 的要差在内存访问、分支、跳转上。。。。还有前面的真的不是编译器不能优化的。
|
|
14
linux40 2017-04-16 10:09:16 +08:00 via Android
说不带 gc 是指 gc 会有很慢的时候啊，一般带上 gc 也挺快的。。。
|
 |
15
zhuangtongfa 2017-04-16 12:48:15 +08:00
这种极端的话就变成解释性语言了
|
 |
16
secondwtq 2017-04-16 13:11:00 +08:00 via Android
楼主指的是啥编译器
我长期折腾 C++，感觉其他 compiled language 的编译器都快得要命，甚至完全没必要优化编译速度 比如第一次编译 OpenRA 的时候按惯例倒了杯水回来发现已经编译完了，一脸懵逼 |
 |
17
Arthur2e5 2017-04-17 01:47:26 +08:00
@secondwtq OpenRA (C#/.NET) 这种东西基本翻译成 MSIL 之后优化就交给运行时了，和彻底的“编译时”作比较有点不妥吧……
|
 |
18
reus 2017-04-17 08:21:11 +08:00
google 的 go 编译器编译速度很快，但编译出来的东西执行也不见得慢。所以这种比较只能用单个编译器来讨论。
go 的 lexer 、 parser 都是并发的，后端的代码生成、链接等也将会并发执行，和 make -jX 这种做法不一样，单个 object 也是并发的，充分利用各个 cpu 核心，编译速度可以更快。 |
Select Language