V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
schezukNewTos
V2EX  ›  C

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

  •  
  •   schezukNewTos · Apr 14, 2017 · 4010 views
    This topic created in 3300 days ago, the information mentioned may be changed or developed.
    18 replies    2017-04-17 08:21:11 +08:00
    realpg
        1
    realpg  
    PRO
       Apr 14, 2017
    就为了编译快?牺牲性能?

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

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

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

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

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

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

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

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

    比如第一次编译 OpenRA 的时候按惯例倒了杯水回来发现已经编译完了,一脸懵逼
    Arthur2e5
        17
    Arthur2e5  
       Apr 17, 2017
    @secondwtq OpenRA (C#/.NET) 这种东西基本翻译成 MSIL 之后优化就交给运行时了,和彻底的“编译时”作比较有点不妥吧……
    reus
        18
    reus  
       Apr 17, 2017
    google 的 go 编译器编译速度很快,但编译出来的东西执行也不见得慢。所以这种比较只能用单个编译器来讨论。
    go 的 lexer 、 parser 都是并发的,后端的代码生成、链接等也将会并发执行,和 make -jX 这种做法不一样,单个 object 也是并发的,充分利用各个 cpu 核心,编译速度可以更快。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   4264 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 59ms · UTC 04:13 · PVG 12:13 · LAX 21:13 · JFK 00:13
    ♥ Do have faith in what you're doing.