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 核心,编译速度可以更快。 |