V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
MonkLuf
V2EX  ›  问与答

算 1 到 10 亿的所有自然数的和,c 用时 4.4's, java 用时 3.8's,python 用时 302.9's,已吓尿,求解释

  •  
  •   MonkLuf · 2014-10-18 16:37:36 +08:00 · 12882 次点击
    这是一个创建于 3678 天前的主题,其中的信息可能已经有所发展或是发生改变。
    算1到10亿的所有自然数的和,c用时4.4's, java用时3.8's,python用时302.9's。

    吓尿!!!

    java居然这么快,居然比c都快!!python居然慢了将近100倍也太夸张了吧!!这个速度突然毁掉了我的世界观。。。。。

    求懂java的人带详细理由的告诉我为什么java会这么快,python为何慢这么多(慢得太离谱了。。。)
    106 条回复    2014-10-20 10:10:04 +08:00
    1  2  
    GordianZ
        1
    GordianZ  
    MOD
       2014-10-18 16:39:18 +08:00
    [Citation needed]
    yuelang85
        2
    yuelang85  
       2014-10-18 16:39:23 +08:00
    没有代码啥也没法说
    liprais
        3
    liprais  
       2014-10-18 16:41:20 +08:00 via iPad   ❤️ 1
    不贴代码就说结果就是耍流氓
    caizixian
        4
    caizixian  
       2014-10-18 16:46:34 +08:00
    别告诉我你用了range
    loading
        5
    loading  
       2014-10-18 16:46:50 +08:00
    java用求和公式, python用 for 一个个加?
    MonkLuf
        6
    MonkLuf  
    OP
       2014-10-18 16:47:21 +08:00
    @yuelang85
    @liprais 这种代码有啥好说的?既然你要看,那就给你:

    python3:

    def sum():
    i = 0
    s = 0
    start = time.time()
    while i < 1000000000:
    i+= 1
    s += i
    end = time.time()
    print("sum: {0}, use time: {1}'s".format(
    s,
    end-start))
    sum()


    java:

    public class Sum {

    public static void main(String[] args) {
    long startTime=System.currentTimeMillis(); //获取开始时间
    long i = 0, sum = 0;
    while (i++ < 1000000000){
    sum += i;
    }
    long endTime=System.currentTimeMillis(); //获取结束时间
    System.out.format("sum: %d, use time: %f's", sum,
    (endTime - startTime)/1000.0);
    }

    }

    c:

    #include <stdio.h>
    #include <stdlib.h>
    #include <sys/time.h>

    int main(){
    struct timeval start, end;
    gettimeofday(&start, NULL);

    long long i = 0, sum = 0;
    while (i++ < 1000000000){
    sum += i;
    }
    gettimeofday(&end, NULL);

    printf("sum: %lld, time used: %f 's",
    sum,
    end.tv_sec - start.tv_sec + (end.tv_usec - start.tv_usec)/1000000.0);
    }
    MonkLuf
        7
    MonkLuf  
    OP
       2014-10-18 16:49:26 +08:00
    当然c加上-O3优化之后1.7s解决
    FreeBTC123
        8
    FreeBTC123  
       2014-10-18 16:49:38 +08:00
    Python 2.7.5 (default, Mar 9 2014, 22:15:05)
    Type "copyright", "credits" or "license" for more information.

    IPython 2.2.0 -- An enhanced Interactive Python.
    ? -> Introduction and overview of IPython's features.
    %quickref -> Quick reference.
    help -> Python's own help system.
    object? -> Details about 'object', use 'object??' for extra details.

    In [1]: timeit sum(xrange(1, 1000000001))
    1 loops, best of 3: 9.26 s per loop

    In [2]:
    MonkLuf
        9
    MonkLuf  
    OP
       2014-10-18 16:50:27 +08:00
    @loading java用求和公式什么意思?
    loading
        10
    loading  
       2014-10-18 16:52:16 +08:00
    你前面不给代码,我也只能这样猜!
    kyangc
        11
    kyangc  
       2014-10-18 16:58:13 +08:00
    Java和C是有编译器优化在里面的
    python编译器不了解,不过看这样子应该是没的……
    zts1993
        12
    zts1993  
       2014-10-18 17:01:57 +08:00
    我觉得可能是python3 int 无限精度引起的。。谁来解释一下。
    iscraft
        13
    iscraft  
       2014-10-18 17:02:20 +08:00
    php for 结果对不?
    ----5.0000000006711E+17--------103.5865240097秒----
    likexian
        14
    likexian  
       2014-10-18 17:16:54 +08:00
    python2
    sum(xrange(1, 1000000001))
    烂笔记本,用了15s
    zts1993
        15
    zts1993  
       2014-10-18 17:18:29 +08:00
    @iscraft php得用gmp吧?
    MonkLuf
        16
    MonkLuf  
    OP
       2014-10-18 17:25:26 +08:00
    @iscraft 对的,和是500000000500000000
    shiny
        17
    shiny  
       2014-10-18 17:25:46 +08:00
    @iscraft 我这里结果和 python 的一样,PHP 5.5.14,耗时比 python2 少一半多。
    shiny
        18
    shiny  
       2014-10-18 17:26:43 +08:00
    可惜 OS X 下没有 hacklang/hhvm,不知道会是什么样的结果。
    ifishman
        19
    ifishman  
       2014-10-18 17:31:31 +08:00
    换了个算法,在树梅派上1/20000秒,这算不算作弊?
    MonkLuf
        20
    MonkLuf  
    OP
       2014-10-18 17:32:58 +08:00
    @shiny
    @iscraft 不能这么对比,毕竟机器不一样,待我再测测php的,不过同样可以参考一下这篇文章的测试数据,用快排对比java/python/c的IO和计算速度:

    http://fantasyorg.blog.163.com/blog/static/109276109201223031127384/
    MonkLuf
        21
    MonkLuf  
    OP
       2014-10-18 17:34:18 +08:00
    @ifishman 用个公式会快多了好吧,这个测试本来就是用来判断这几个语言的计算速度的,你又淘气了。。。。
    RIcter
        22
    RIcter  
       2014-10-18 17:36:30 +08:00 via Android
    python本来就不是拼速度的,何必呢。
    不如手算?
    shiny
        23
    shiny  
       2014-10-18 17:38:02 +08:00
    @MonkLuf 当然是在自己机器上跑 python 再跑 php,然后对比时间。
    regmach
        24
    regmach  
       2014-10-18 17:40:48 +08:00
    float 5.0000000006711E+17
    65.392sec
    LINAICAI
        25
    LINAICAI  
       2014-10-18 17:43:03 +08:00
    这个。。。为什么我感觉没必要争论,py是解析语言,c和java经过编译器优化。
    hjc4869
        26
    hjc4869  
       2014-10-18 17:47:22 +08:00
    你试试用c语言写个高精度加法的再去跟python比。
    sneezry
        27
    sneezry  
       2014-10-18 17:51:32 +08:00 via iPhone
    好不好js现在都比py快了……
    sneezry
        28
    sneezry  
       2014-10-18 17:51:57 +08:00 via iPhone
    搞不好,打错了
    robbielj
        29
    robbielj  
       2014-10-18 17:54:46 +08:00
    我觉得为什么要有numpy,为什么要有cython很好地解释了你这个问题
    yuelang85
        30
    yuelang85  
       2014-10-18 17:55:25 +08:00
    前面好多人都贴了sum,sum应该是c写的吧?

    我能想到的几种方式:

    https://gist.github.com/0e3f2b106a1ec41da2c9.git
    yuelang85
        31
    yuelang85  
       2014-10-18 17:55:42 +08:00
    barbery
        32
    barbery  
       2014-10-18 17:57:23 +08:00
    @sneezry 按我之前的经验,js肯定比py快啊
    pimin
        33
    pimin  
       2014-10-18 18:06:52 +08:00
    c用时4.4's肯定是编译时没开优化,我电脑上跑是0.86s
    ysjdx
        34
    ysjdx  
       2014-10-18 18:07:46 +08:00
    试试pypy 会快很多
    ZavierXu
        35
    ZavierXu  
       2014-10-18 18:11:33 +08:00
    写代码从来就一个要求, 能跑就行, 追求速度不如想想如何不出错
    ysjdx
        36
    ysjdx  
       2014-10-18 18:12:07 +08:00
    @ysjdx

    sum(xrange(1000000001))

    在我的电脑上面,pypy用时

    1.27434396744
    ChiangDi
        37
    ChiangDi  
       2014-10-18 18:14:55 +08:00 via Android
    @sneezry 快多了,不是一个级别的。
    anheiyouxia
        38
    anheiyouxia  
       2014-10-18 18:16:51 +08:00   ❤️ 3
    楼主,你很幸运,以前我看过一篇也是python浮点运算慢的文章,然后现在我又找出来给你了:
    http://bbs.byr.cn/#!article/Focus/69820


    =============华丽的分割线=============
    举一个例子。对于整数加法,C语言很简单,只要一个机器指令ADD就可以了,最多不过再加一些内存读写。

    但是,对于Python来说,a+b这样的简单二元运算,可就真的很麻烦了。Python是动态语言,变量只是对象的引用,变量a和b本身都没有类型,而它们的值有类型。所以,在相“加”之前,必须先判断类型。

    1. 判断a是否为整数,否则跳到第9步
    2. 判断b是否为整数,否则跳到第9步
    3. 将a指向的对象中的整数值读出来
    4. 将b指向的对象中的整数值读出来
    5. 进行整数相加
    6. 生成一个新整数对象
    7. 将运算结果存进去
    8. 返回这个对象,完成!
    9. 判断a是否为字符串,否则跳到第13步
    10. 判断b是否为字符串,否则跳到第13步
    11. 进行字符串串接操作,生成一个新字符串对象
    12. 返回这个对象,完成!
    13. 从a的字典里取出__add__方法
    14. 调用这个方法,将a和b作为参数传入
    15. 返回上述方法的返回值。

    这还只是简化版的,实际中还要考虑溢出问题等。

    可想而知,如果对于每一次加法运算,C语言只需要一个机器指令,而Python要做这么多操作,Python显然要比C慢得太多。再加上官方的CPython是一个解释器,还要加上每次读指令、指令译码的代价,就更慢了。
    =============华丽的分割线=============
    cctvsmg
        39
    cctvsmg  
       2014-10-18 18:21:13 +08:00
    @ysjdx
    root@ubuntu:~# pypy test.py
    sum_raw: 500000000500000000, use time: 1.45206093788's
    sum_1: 500000000500000000, use time: 1.4495549202's
    sum_2: 500000000500000000, use time: 1.45537519455's
    sum_3: 500000000500000000, use time: 1.45463609695's
    pH
        40
    pH  
       2014-10-18 18:51:00 +08:00
    我一直期待有人来汇编呢
    bigtan
        41
    bigtan  
       2014-10-18 18:53:02 +08:00
    import numpy as np
    %timeit np.sum(np.arange(1,1000000000))
    1 loops, best of 3: 5.12 s per loop

    不用pypy用numpy也可以跑到一个数量级
    xavierskip
        42
    xavierskip  
       2014-10-18 19:18:37 +08:00
    In [12]: start = time.time();sum(xrange(1,100000001));print time.time()-start
    1.27270293236


    慢吗?
    ifishman
        43
    ifishman  
       2014-10-18 19:30:25 +08:00
    @xavierskip 确实慢,1秒和1/20000秒,慢了不只一点点。算法的不同而已。其实我不懂python……:-P
    cloverstd
        44
    cloverstd  
       2014-10-18 19:34:04 +08:00
    > python sum.py
    sum_raw: 500000000500000000, use time: 77.362965107's
    sum_1: 500000000500000000, use time: 78.8294119835's
    sum_2: 500000000500000000, use time: 46.696573019's
    sum_3: 500000000500000000, use time: 12.4079239368's

    pypy 快好多啊
    > pypy sum.py
    sum_raw: 500000000500000000, use time: 0.948999881744's
    sum_1: 500000000500000000, use time: 1.04911208153's
    sum_2: 500000000500000000, use time: 1.19244813919's
    sum_3: 500000000500000000, use time: 1.18416213989's
    dant
        45
    dant  
       2014-10-18 19:51:44 +08:00
    来个 Ruby 的。
    lushl9301
        46
    lushl9301  
       2014-10-18 19:56:21 +08:00
    @cloverstd pypy真是快。。。

    to others:
    我这里同样java最快,c其次。
    对于c来说,++i 要比 i++快一点;i 从 1000000000减到 0 比从0加到1000000000稍微快一点。
    对于java不成立。

    python的确很慢。
    猜测原因是Cpython的int是immutable的。

    每次sum += i都会放一个新的内存位置给他。
    再加上垃圾处理机制,就会更慢了。。

    可以用31楼的sum_1来测试。1到100加和,每次print id(s)看一下。
    ovear
        47
    ovear  
       2014-10-18 20:07:04 +08:00
    我也来一个版本,运行时决定累加数目

    Scanner scanner = new Scanner(System.in);
    int target = scanner.nextInt();
    for (int c = 0; c < 11; c++) {
    long startTime = System.currentTimeMillis(); //获取开始时间
    long i = 0, sum = 0;
    while (i++ < target) {
    sum += i;
    }
    long endTime = System.currentTimeMillis(); //获取结束时间
    System.out.format("sum: %d, use time: %f's\r\n", sum,
    (endTime - startTime) / 1000.0);
    }
    //使用sum的方法
    long startTime = System.nanoTime(); //获取开始时间
    long result = ((1L + target) * target) / 2L; //求和公式
    long endTime = System.nanoTime(); //获取结束时间
    System.out.format("sum: %d, use time: %f'ms(may be inaccurate due to the kernel)\r\n", result,
    (endTime - startTime) / 1000000.0);

    output

    1000000000
    sum: 500000000500000000, use time: 0.647000's
    sum: 500000000500000000, use time: 0.647000's
    sum: 500000000500000000, use time: 0.648000's
    sum: 500000000500000000, use time: 0.645000's
    sum: 500000000500000000, use time: 0.645000's
    sum: 500000000500000000, use time: 0.643000's
    sum: 500000000500000000, use time: 0.644000's
    sum: 500000000500000000, use time: 0.642000's
    sum: 500000000500000000, use time: 0.642000's
    sum: 500000000500000000, use time: 0.644000's
    sum: 500000000500000000, use time: 0.645000's
    sum: 500000000500000000, use time: 0.000293'ms(may be inaccurate due to the kernel)
    ovear
        48
    ovear  
       2014-10-18 20:14:38 +08:00
    @ovear nanotime不准。。之后都是0.0000了。。奇葩
    NahN2Regh
        49
    NahN2Regh  
       2014-10-18 20:41:26 +08:00
    rust开启优化后, 与C没差别了, 都很快:

    编译器 优化 时间
    gcc -- real:0m3.930s, user:0m3.916s, sys:0m0.008s
    gcc -O1 real:0m0.630s, user:0m0.624s, sys:0m0.000s
    gcc -O2 real:0m0.002s, user:0m0.000s, sys:0m0.000s
    rustc -- real:0m4.172s, user:0m4.000s, sys:0m0.020s
    rustc --opt-level=1 real:0m0.003s, user:0m0.000s, sys:0m0.000s

    gcc 的版本是4.9.1
    rust版本是0.12

    源代码:
    [code]
    $ cat sum.c
    #include <stdio.h>

    int main(int argc, char *argv[]) {

    long i = 0;
    long s = 0;
    long limit = 1000000000;
    while (i < limit) {
    s = s + i;
    i = i + 1;
    }
    printf("%ld\n", s);

    return 0;
    }
    [/code]
    [code]
    $ cat sum.rs

    fn main() {
    let mut i = 0i64;
    let mut s = 0i64;
    let limit = 1000000000i64;
    while i < limit {
    s = s + i;
    i = i + 1;
    }
    println!("{}", s);
    }
    [/code]
    Shared
        50
    Shared  
       2014-10-18 21:39:12 +08:00
    如果要用 Python 做这种事情要么用 PyPy,要么写个 C 扩展呗。
    P.S. 这种比较好没意思
    davidli
        51
    davidli  
       2014-10-18 21:47:39 +08:00
    Python下能用内置函数的情况下一定要用内置函数.
    ant_sz
        52
    ant_sz  
       2014-10-18 22:08:05 +08:00
    我觉得从上面的回答已经可以看得出来:

    语言本身的性能决定了运行时间的下限,但是程序员写程序的水平决定了运行时间的上限。

    同样一个功能,不同的人写出来性能能有百倍的差距。

    因此,一些情况下,语言本身的性能并没有开发效率和易用性更重要。
    icedx
        53
    icedx  
       2014-10-18 22:26:37 +08:00   ❤️ 1
    efen
        54
    efen  
       2014-10-18 22:51:06 +08:00   ❤️ 2
    @icedx 一本正经的跑题,哈哈哈
    ggarlic
        55
    ggarlic  
       2014-10-18 23:21:53 +08:00
    @lushl9301 现在的编译器,++i跟i++产生的汇编是一样的了,不信你-S一下。
    takato
        56
    takato  
       2014-10-18 23:28:51 +08:00
    我觉得用O(n)的算法去解决一个O(1)就能解决的问题,真是用牛刀了- -
    efen
        57
    efen  
       2014-10-18 23:38:52 +08:00
    Lisp大法好 ( ̄(工) ̄)

    尾递归版本46s,普通递归版本把8g内存全吃光,跑了7分多钟没结果,哈哈哈
    wdlth
        58
    wdlth  
       2014-10-19 00:10:39 +08:00
    C的那段程序结果

    gcc 4.8.3 不加参数
    sum: 500000000500000000, time used: 2.358622 's
    gcc -O3
    sum: 500000000500000000, time used: 0.424286 's
    Intel C Compiler 14.0不加参数
    sum: 500000000500000000, time used: 0.412634 's
    Intel C Compiler -O3
    sum: 500000000500000000, time used: 0.407397 's
    Intel C Compiler -O3 -mtune=corei7 -march=corei7
    sum: 500000000500000000, time used: 0.375456 's

    Intel大 好
    iam36
        59
    iam36  
       2014-10-19 00:45:57 +08:00 via Android
    仅用数学运算来比对太片面了。
    webjin
        60
    webjin  
       2014-10-19 00:58:42 +08:00
    不错哦
    NathanInMac
        61
    NathanInMac  
       2014-10-19 01:37:04 +08:00
    go不到500ms。。
    Sharuru
        62
    Sharuru  
       2014-10-19 02:11:03 +08:00 via iPhone   ❤️ 1
    从看到这贴就好奇,楼主好坏是在一台电脑上用不同的语言做了测试,得出消耗时间不同的结论。
    但是其他诸位仅做了一种语言的测试。
    同样的代码不同电脑跑完全是不一样的计算结果。
    辣鸡的代码在流弊的电脑上可以跑1s,高效的代码在辣鸡代码上却要跑10s…
    一本正经的不明所以。
    MonkLuf
        63
    MonkLuf  
    OP
       2014-10-19 02:24:25 +08:00 via Android
    @Shared
    @iam36
    @takato
    @icedx
    @ant_sz
    @davidli
    嗯,此帖并不是说为了解决某个问题而讨论各种语言的效率,也不是为了证明语言之间的优劣,而只是就单纯的运算速度而言给这几种语言一个直观的认识。

    以前只知道python运算效率低,没想到这么低,低个几百倍。。。java效率低,但是看起来好像没低多少。。。
    Shared
        64
    Shared  
       2014-10-19 02:32:29 +08:00
    @MonkLuf 效率取决于场景(context)
    konakona
        65
    konakona  
       2014-10-19 03:08:42 +08:00
    我本来想打开xcode来一段swift的……可是xcode死机了……
    icedx
        66
    icedx  
       2014-10-19 03:17:05 +08:00 via Android
    @MonkLuf 但是…我也觉得这个低Python 的不科学
    msg7086
        67
    msg7086  
       2014-10-19 05:37:24 +08:00
    @pH 既然你诚心诚意地问了……下略

    https://gist.github.com/msg7086/b5de7cb128d8ef109808
    msg7086
        68
    msg7086  
       2014-10-19 06:21:05 +08:00
    楼上的代码本来是用 AVX Intrinsics 写的,但是在不启用优化的情况下编译器会自作主张改写汇编语句结构。所以这里老老实实重写成了 inline asm 代码。要看 Intrinsics 版本的,可以去看 Gist 的提交历史。
    wwqgtxx
        69
    wwqgtxx  
       2014-10-19 07:06:51 +08:00 via Android
    想知道js的运行速度
    在chrome/ie/firefox下试试?
    efen
        70
    efen  
       2014-10-19 08:16:50 +08:00 via iPhone
    @MonkLuf 其实主要的点是,和一般的语言不同很反直觉的是,Python的操作中,加减恰恰是最慢的,而带来的好处嘛,数值计算上实在是方便得多
    Sharuru
        71
    Sharuru  
       2014-10-19 09:57:54 +08:00 via iPhone
    不过人类最强计算器Python算大数什么的倒是非常惬意。
    hitsmaxft
        72
    hitsmaxft  
       2014-10-19 09:58:21 +08:00
    不能这么比的, c 跟 java 有编译时优化, python 就只能拼人肉优化了..
    mille
        73
    mille  
       2014-10-19 11:16:19 +08:00
    sum: 500000000500000000, time used: 3.141718 's

    还是我oc拯救世界😄
    Actrace
        74
    Actrace  
       2014-10-19 11:16:55 +08:00
    Actrace
        75
    Actrace  
       2014-10-19 11:17:09 +08:00
    Actrace
        76
    Actrace  
       2014-10-19 11:18:33 +08:00
    Actrace
        77
    Actrace  
       2014-10-19 11:18:52 +08:00
    终于懂贴代码了~
    gihnius
        78
    gihnius  
       2014-10-19 11:46:37 +08:00
    common lisp 直接算:

    ```
    CL-USER> (time (loop for i from 1 to 1000000000 sum i))
    Evaluation took:
    2.877 seconds of real time
    2.888336 seconds of total run time (2.878674 user, 0.009662 system)
    100.38% CPU
    6,603,209,056 processor cycles
    32,912 bytes consed

    500000000500000000


    CL-USER> (time (let ((sum 0)) (dotimes (x 1000000001) (incf sum x)) sum))
    Evaluation took:
    2.883 seconds of real time
    2.894640 seconds of total run time (2.884340 user, 0.010300 system)
    100.42% CPU
    6,616,544,771 processor cycles
    33,296 bytes consed

    500000000500000000

    ```
    ptyfork
        79
    ptyfork  
       2014-10-19 12:55:00 +08:00
    $ ikarus

    Ikarus Scheme version 0.0.4-rc1+, 64-bit (revision 1870, build 2014-10-07)
    Copyright (c) 2006-2009 Abdulaziz Ghuloum

    > (time
    (let lp ((i 0) (sum 0))
    (if (<= i 1000000000)
    (lp (+ 1 i) (+ i sum))
    sum)))
    running stats for (let lp ((i 0) (sum 0)) (if (<= i 1000000000) (lp (+ 1 i) (+ i sum)) sum)):
    no collections
    3148 ms elapsed cpu time, including 0 ms collecting
    3155 ms elapsed real time, including 0 ms collecting
    0 bytes allocated
    500000000500000000
    gihnius
        80
    gihnius  
       2014-10-19 13:01:57 +08:00
    @gihnius 稍微优化一下:

    ```
    CL-USER> (time (let ((sum 0)) (declare (type fixnum sum)) (dotimes (x 1000000001) (incf sum x)) sum))
    Evaluation took:
    0.606 seconds of real time
    0.609144 seconds of total run time (0.607192 user, 0.001952 system)
    100.50% CPU
    1,392,562,529 processor cycles
    0 bytes consed

    500000000500000000

    ```
    geew
        81
    geew  
       2014-10-19 13:20:10 +08:00
    我能说你们好无聊么
    darkmatter
        82
    darkmatter  
       2014-10-19 13:36:02 +08:00
    n(n +1)/2
    ChiangDi
        83
    ChiangDi  
       2014-10-19 13:41:30 +08:00
    Haskell 啊哈哈哈哈

    dingyaguang117
        84
    dingyaguang117  
       2014-10-19 13:47:29 +08:00 via iPhone
    卤煮,你这个不科学,只有python加出来的的是真正的和,其他的32位早就溢出了吧
    msg7086
        85
    msg7086  
       2014-10-19 13:51:18 +08:00
    tywtyw2002
        86
    tywtyw2002  
       2014-10-19 14:07:04 +08:00
    我们比较下 gcc clang 还有icc的速度吧。。。。。然后做一下多核的曲线,这就是一篇paper了。。
    jacob
        87
    jacob  
       2014-10-19 15:03:31 +08:00
    ruby 的存在感这么低吗

    ----------
    def sum
    i,s=0,0
    start=Time.now
    while i<1000000000
    i+=1
    s+=i
    end
    puts "sum of while:#{s},time:#{Time.now-start}"
    end


    sum()

    def sum_of_range
    s=0
    start=Time.now
    digi=1..1000000000
    digi.each do |d|
    s+=d
    end
    puts "sum of range:#{s},time:#{Time.now-start}"
    end

    sum_of_range()
    ------------------------


    sum of while:500000000500000000,time:255.076978
    sum of range:500000000500000000,time:343.893392
    lushl9301
        88
    lushl9301  
       2014-10-19 15:20:31 +08:00 via iPad
    @takato 酱紫。。。不是i++多分配一个临时内存储存一下的么。。。
    ant_sz
        89
    ant_sz  
       2014-10-19 19:15:11 +08:00
    @MonkLuf

    你看了评论竟然还没发现么。不是Python性能低,是你不会写。

    像这样的垃圾帖子每隔一段时间都要在v2ex上刷一回,为何还会有人不断地刷呢。
    lightening
        90
    lightening  
       2014-10-19 20:20:46 +08:00
    @MonkLuf Java 效率低本来就是一种误解。我朋友做的一些证券交易系统的内核用 Java 写,速度和 C 根本不相上下。
    AWSAM
        91
    AWSAM  
       2014-10-19 20:26:27 +08:00
    @jacob ruby 不应该这么写么

    time ruby -e 'puts (1..10e8).inject :+ '

    ------------------------------
    500000000500000000
    ruby -e 'puts (1..10e8).inject :+ ' 155.01s user 0.89s system 98% cpu 2:38.48 total
    gihnius
        92
    gihnius  
       2014-10-19 20:38:52 +08:00
    @MonkLuf
    @lightening
    lisp 效率低也是一种误解。看上面的例子,速度和 C 不相上下。:)
    RelativeLayout
        93
    RelativeLayout  
       2014-10-19 20:57:16 +08:00
    我这儿排序是这样的:

    Java 1.05s
    Node 1.38s
    C 2.93s
    Python 100+s

    Node
    https://gist.github.com/daimajia/dd7bf30f498300fa31e0
    aWangami
        94
    aWangami  
       2014-10-19 21:15:22 +08:00
    skybr
        95
    skybr  
       2014-10-19 21:16:05 +08:00
    js快归快, 答案是错的.
    jacob
        96
    jacob  
       2014-10-19 21:40:13 +08:00
    @AWSAM 看不懂,也不知道怎么运行
    RelativeLayout
        97
    RelativeLayout  
       2014-10-19 21:50:32 +08:00
    @skybr 确实! Node的计算结果是错误的!
    RelativeLayout
        98
    RelativeLayout  
       2014-10-19 21:53:24 +08:00
    @skybr 找到错误原因了, JavaScript最大的数只能到
    9007199254740992
    而答案是:
    500000000500000000

    http://stackoverflow.com/a/307200
    barbery
        99
    barbery  
       2014-10-19 22:08:50 +08:00
    擦,这帖子竟然还没沉。。。好吧,讨论得那么激烈,怎么能少得了golang版本的呢

    https://gist.github.com/Barbery/9a5d2caf0915f370acdd.js
    barbery
        100
    barbery  
       2014-10-19 22:09:37 +08:00
    golang版本的只要0.82秒哦,亲!
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1099 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 22:44 · PVG 06:44 · LAX 14:44 · JFK 17:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.