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

编程语言的性能由什么决定?

  •  
  •   LMkillme · 2015-02-08 18:53:04 +08:00 · 5049 次点击
    这是一个创建于 3336 天前的主题,其中的信息可能已经有所发展或是发生改变。

    看新闻时看见下面这句话:

    「苹果很注重 Swift 的性能,并提到使用 Swift 代码编写的搜索逻辑执行效率要比 Objective -C 快 2.6倍,比 Pyton 快8.4倍」

    编程语言的性能由什么决定?编译器?没想明白,谷歌了一下,没找到答案。

    15 条回复    2015-02-09 14:12:27 +08:00
    acros
        1
    acros  
       2015-02-08 19:00:26 +08:00
    由语言设计者的设计意图和水平决定的·····

    一般越底层的越快,汇编、C、C++之类,你可以针对硬件特性都做很多优化,比如inline函数减小调用开销之类。像做应用的java要虚拟机,就像两个人交流中间还插了个翻译帮忙一样,当然慢了。
    acros
        2
    acros  
       2015-02-08 19:01:29 +08:00
    编译器也是会影响的编译出代码的执行效率····这个看编译器开发者的水平了。
    vietor
        3
    vietor  
       2015-02-08 19:02:06 +08:00 via Android
    应用场景
    lincanbin
        4
    lincanbin  
       2015-02-08 19:06:08 +08:00
    语法语言特性设计,编译器/解释器。

    前者比较重要,例如为了提高开发效率,允许使用不定长数组,那么这个数组申请的内存就有浪费,当数组变长,又重开一块足够长的区域把原来的数据复制过去,然后再追加,效率就低了。
    又或者说弱类型,运行过程中要推导,又浪费了一些时间。
    DingSoung
        5
    DingSoung  
       2015-02-08 21:44:42 +08:00
    代码本身没有绕弯路的话,剩下的就主要看编译器优化了。
    WildCat
        6
    WildCat  
       2015-02-08 21:45:13 +08:00
    ARC > GC
    LMkillme
        7
    LMkillme  
    OP
       2015-02-08 21:52:31 +08:00   ❤️ 1
    @dingsoung 那意思就是 编程语言的性能 == 编译器的优化能力?
    LMkillme
        8
    LMkillme  
    OP
       2015-02-08 21:53:04 +08:00
    @WildCat 都用ARC的语言之间也还是有性能区别
    sumhat
        9
    sumhat  
       2015-02-08 21:53:33 +08:00
    由市场部决定,宣传的时候有多快说多快,实际使用还是得看程序员。
    DingSoung
        10
    DingSoung  
       2015-02-08 22:17:16 +08:00
    @LMkillme 不完全是,还有本身的设计等等,我不是专业做这个的,但是优化,尤其是针对硬件真的很重要。
    话说Swift就那几个平台,设计的时候又可以考虑那么多新的资源可以参考,快是理所当然的。
    hitsmaxft
        11
    hitsmaxft  
       2015-02-08 22:43:32 +08:00   ❤️ 2
    这种对比还是比较常见的, 比如 c / c++ / java 之间的快排实现.

    早期的java的部分基础库是c实现的, 因为纯java实现性能不够. 但后来的版本就迁移到java实现了, 因为在有 jit 的帮助下, java的版本快于原来的c实现. c++ 也有同样的过程

    程序员所接触的是语言提供的标准接口, 经过编译之后编程字节码或者机器码. 这个编译的过程中, 有很多黑魔法是程序员默认情况下没法干预的. 这就好比优化php/python程序, 会用上 c, 来突破纯语言实现的限制; 如果要优化c,就得针对具体硬件,使用汇编优化.

    但是反过来, 也存在编译器无法预测程序员的行为, 没法主动优化. 需要程序员使用一个抽象层次比较高的语法/基础库, 那么编译器开发者可以尽可能地进行优化.
    也就是说自行编写的代码, 那么可能反而因为没有充分编译优化而比同样的基础库运行效率低.

    搜索和hash都是语言最基础的部分基础库, 因此优化的工作比其他基础库多一些也是应该的. 但是原因都是因为各个语言的工作环境不一致, 换个运行环境得到的结果可能就变了, 所以这种比较都是给开发者一个信心而已..


    以上都是针对单个api而言, 完整的语言性能需要更加多方面的分析.
    LMkillme
        12
    LMkillme  
    OP
       2015-02-08 22:48:15 +08:00
    @hitsmaxft 点赞~ 我其实最想知道的就是语言的性能究竟是由哪些方面决定的~
    otakustay
        13
    otakustay  
       2015-02-09 01:23:31 +08:00
    难道不是由执行环境决定么……

    跟你们举个例子:IE6、Chrome
    LMkillme
        14
    LMkillme  
    OP
       2015-02-09 01:51:51 +08:00
    @otakustay 别扯~
    hitsmaxft
        15
    hitsmaxft  
       2015-02-09 14:12:27 +08:00   ❤️ 1
    @LMkillme 这个得反推

    ## 首先必须是高效的字节码+虚拟机

    像 php 这种没有 jit 的, 从起跑线上就输了,得靠 c 扩展补上,相当于手动给虚拟机打补丁。

    ## 然后是执行模式和基础库高效

    比如 node/actor/goroutine 可以优化 io依赖比较高的场景,但是如果是偏计算的场景,又退化到拼虚拟机了。
    再说php, fpm 的多进程执行+每次请求完毕 fullgc 的模式决定了在高并发的情况下很浪费资源,又得靠c扩展补,接着打补丁,或者用 reactor 等其他执行模式重新开发。
    相比之下, java 的多线程模式对于资源重用是比较高效的,但是又老占内存,有时候跟 c 系不见得能比。

    这部分比较模糊,只要提供一个合理高效的库,即使不是语言默认支持的执行模式, 也可以达到目的。
    这里还是没开发者什么事, 关键在于选对架构。
    开发者能选的,无非是语言自带基础库和第三方库,里面也是各种猫腻, 有的是纯语言实现,有些用 c 等低级语言实现,搞不清楚用错的, 就呵呵了。

    ## 最后才是语言效率

    连 a=1 这样的语句, 在不同语言里面解释或者编译之后生成的机器码,也是不同的。
    写代码的时候要合理优化写法,选用高效的方式实现业务逻辑,或者根据版本升级,合理重构是必须的。
    比如 php 的部分数据结构实现和基础库是比较低效的,最近几个版本都在拼了老命优化, 但是有弱类型等天生短板在那里,注定了没其他强类型的性能高,加上 jit 无望。

    像 汇编+c 这种天生开挂的语言,以上所有事情都能自己实现,纯粹看人的技术实力,大不了自己实现虚拟机。比如 mozilla ,先实现一门语言 rust , 再重写浏览器核心。

    我们的 web 应用从 php 迁移到 java。在优化的手段和基础库的选择上多了很多选择, qps 是原来的3倍,
    但是相应的, 在优化和框架设计的成本上增加了 N 倍,而且是在代码质量上严格审查,各种 review 打回的基础上实现的。


    最后,黑了 php 这么多, 回下血。php 面向 web 应用的开发效率很高, 在一定场景下可以推翻以上123点,吊打其他语言,但是得优雅地绕过所有的坑。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1086 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 22:46 · PVG 06:46 · LAX 15:46 · JFK 18:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.