V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
schezukNewTos
V2EX  ›  C

现代编译器以性能为代价,编译速度最多能快多少倍,此时性能损耗有多大?

  •  
  •   schezukNewTos · 2017-04-14 16:55:19 +08:00 · 3341 次点击
    这是一个创建于 2779 天前的主题,其中的信息可能已经有所发展或是发生改变。
    18 条回复    2017-04-17 08:21:11 +08:00
    realpg
        1
    realpg  
       2017-04-14 17:02:57 +08:00
    就为了编译快?牺牲性能?

    最快的应该是直接把源代码拷到 release 目录,直接把编译器压一起……
    执行时候再编译呗
    schezukNewTos
        2
    schezukNewTos  
    OP
       2017-04-14 17:07:22 +08:00
    @realpg 我其实是想了解,解释型语言为什么在某些场合比编译型语言有优势……
    em70
        3
    em70  
       2017-04-14 17:07:27 +08:00 via Android
    不就是 python 和 C 的区别么
    liuzhedash
        4
    liuzhedash  
       2017-04-14 17:17:54 +08:00
    @schezukNewTos #2
    解释型语言开发效率更高
    BoBoy
        5
    BoBoy  
       2017-04-14 17:26:34 +08:00
    @liuzhedash 但是执行效率更慢(始终比不上 C ,当然也要看使用场景,逃~
    zjqzxc
        6
    zjqzxc  
       2017-04-14 17:26:48 +08:00
    @schezukNewTos #2

    解释性语言执行时才编译,可以实现一些编译性语言无法实现的"奇巧淫技"
    例如: php 中的 extract(),可以实现把数组中将变量导入到当前的符号表(简单来说,就是把数组中的 key 作为变量名, value 作为值来“生成”一堆变量);

    解释性语言一般是执行一行编译一行,执行过程中用不到的可以先不编译,开发的时候可以提升效率;

    跨平台时不用针对目标平台进行任何额外的工作
    tony601818
        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
    geelaw
        8
    geelaw  
       2017-04-14 17:48:22 +08:00
    不编译,直接放一个无限循环的程序上去,算吗?
    jybox
        9
    jybox  
       2017-04-14 22:22:46 +08:00
    所谓「解释型」是算是基于「虚拟机」的语言的一种简易实现。但除了 CPython 这个异端之外,其他基于虚拟机的语言都多多少少转向了 JIT ,在一些特定场景下已经可以和本地代码(你们说的「编译型」语言大概就是这个意思吧,毕竟 JIT 也有编译环节)一较高下了,之所以和本地代码仍有差距的原因其实更多是因为这些语言往往是「动态类型」而且有 GC 。

    楼上各位多多少少混淆了这些概念,可以看下我近期的一篇文章 https://jysperm.me/2016/12/categories-of-languages
    ghostheaven
        10
    ghostheaven  
       2017-04-14 22:52:12 +08:00 via Android
    解释器在运行时会优化,极端情况下可以直接返回之前计算好的结果,而不必执行整段代码,这是编译型需要做不到的。
    soulshell
        11
    soulshell  
       2017-04-15 04:48:27 +08:00
    了解过 gcc llvm 的编译优化过程么?

    v2 的人对 compiler 的了解仅限于此?

    所以也不过都是一帮二字套餐的
    schezukNewTos
        12
    schezukNewTos  
    OP
       2017-04-15 16:09:35 +08:00
    @soulshell 愿闻其详。
    linux40
        13
    linux40  
       2017-04-16 10:01:01 +08:00 via Android
    性能损耗和语言特性有关,比如 c++可以给你优化掉内存访问、分支、跳转、虚函数、异常、值返回等等所有特性,但不优化的话估计和比 Java 不带 gc 的要差在内存访问、分支、跳转上。。。。还有前面的真的不是编译器不能优化的。
    linux40
        14
    linux40  
       2017-04-16 10:09:16 +08:00 via Android
    说不带 gc 是指 gc 会有很慢的时候啊,一般带上 gc 也挺快的。。。
    zhuangtongfa
        15
    zhuangtongfa  
       2017-04-16 12:48:15 +08:00
    这种极端的话就变成解释性语言了
    secondwtq
        16
    secondwtq  
       2017-04-16 13:11:00 +08:00 via Android
    楼主指的是啥编译器

    我长期折腾 C++,感觉其他 compiled language 的编译器都快得要命,甚至完全没必要优化编译速度

    比如第一次编译 OpenRA 的时候按惯例倒了杯水回来发现已经编译完了,一脸懵逼
    Arthur2e5
        17
    Arthur2e5  
       2017-04-17 01:47:26 +08:00
    @secondwtq OpenRA (C#/.NET) 这种东西基本翻译成 MSIL 之后优化就交给运行时了,和彻底的“编译时”作比较有点不妥吧……
    reus
        18
    reus  
       2017-04-17 08:21:11 +08:00
    google 的 go 编译器编译速度很快,但编译出来的东西执行也不见得慢。所以这种比较只能用单个编译器来讨论。
    go 的 lexer 、 parser 都是并发的,后端的代码生成、链接等也将会并发执行,和 make -jX 这种做法不一样,单个 object 也是并发的,充分利用各个 cpu 核心,编译速度可以更快。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1090 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 19ms · UTC 18:56 · PVG 02:56 · LAX 10:56 · JFK 13:56
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.