算 1 到 10 亿的所有自然数的和，c 用时 4.4's, java 用时 3.8's，python 用时 302.9's，已吓尿，求解释
MonkLuf · 2014-10-18 16:37:36 +08:00 · 12899 次点击这是一个创建于 3687 天前的主题，其中的信息可能已经有所发展或是发生改变。
算1到10亿的所有自然数的和，c用时4.4's, java用时3.8's，python用时302.9's。
吓尿！！！
java居然这么快，居然比c都快！！python居然慢了将近100倍也太夸张了吧！！这个速度突然毁掉了我的世界观。。。。。
求懂java的人带详细理由的告诉我为什么java会这么快，python为何慢这么多（慢得太离谱了。。。）
吓尿！！！
java居然这么快，居然比c都快！！python居然慢了将近100倍也太夸张了吧！！这个速度突然毁掉了我的世界观。。。。。
求懂java的人带详细理由的告诉我为什么java会这么快，python为何慢这么多（慢得太离谱了。。。）
 |
1
GordianZ MOD [Citation needed]
|
 |
2
yuelang85 2014-10-18 16:39:23 +08:00
没有代码啥也没法说
|
 |
3
liprais 2014-10-18 16:41:20 +08:00 via iPad  1
不贴代码就说结果就是耍流氓
|
 |
4
caizixian 2014-10-18 16:46:34 +08:00
别告诉我你用了range
|
 |
5
loading 2014-10-18 16:46:50 +08:00
java用求和公式， python用 for 一个个加？
|
 |
6
MonkLuf OP @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); } |
|
7
MonkLuf OP 当然c加上-O3优化之后1.7s解决
|
 |
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]: |
|
10
loading 2014-10-18 16:52:16 +08:00
你前面不给代码，我也只能这样猜！
|
 |
11
kyangc 2014-10-18 16:58:13 +08:00
Java和C是有编译器优化在里面的
python编译器不了解，不过看这样子应该是没的…… |
 |
12
zts1993 2014-10-18 17:01:57 +08:00
我觉得可能是python3 int 无限精度引起的。。谁来解释一下。
|
 |
13
iscraft 2014-10-18 17:02:20 +08:00
php for 结果对不?
----5.0000000006711E+17--------103.5865240097秒---- |
 |
14
likexian 2014-10-18 17:16:54 +08:00
python2
sum(xrange(1, 1000000001)) 烂笔记本，用了15s |
 |
18
shiny 2014-10-18 17:26:43 +08:00
可惜 OS X 下没有 hacklang/hhvm，不知道会是什么样的结果。
|
 |
19
ifishman 2014-10-18 17:31:31 +08:00
换了个算法，在树梅派上1/20000秒，这算不算作弊？
|
|
20
MonkLuf OP @shiny
@iscraft 不能这么对比，毕竟机器不一样，待我再测测php的，不过同样可以参考一下这篇文章的测试数据，用快排对比java/python/c的IO和计算速度： http://fantasyorg.blog.163.com/blog/static/109276109201223031127384/ |
 |
22
RIcter 2014-10-18 17:36:30 +08:00 via Android
python本来就不是拼速度的，何必呢。
不如手算？ |
 |
24
regmach 2014-10-18 17:40:48 +08:00
float 5.0000000006711E+17
65.392sec |
 |
25
LINAICAI 2014-10-18 17:43:03 +08:00
这个。。。为什么我感觉没必要争论，py是解析语言，c和java经过编译器优化。
|
 |
26
hjc4869 2014-10-18 17:47:22 +08:00
你试试用c语言写个高精度加法的再去跟python比。
|
 |
27
sneezry 2014-10-18 17:51:32 +08:00 via iPhone
好不好js现在都比py快了……
|
|
28
sneezry 2014-10-18 17:51:57 +08:00 via iPhone
搞不好，打错了
|
 |
29
robbielj 2014-10-18 17:54:46 +08:00
我觉得为什么要有numpy，为什么要有cython很好地解释了你这个问题
|
|
30
yuelang85 2014-10-18 17:55:25 +08:00
|
|
31
yuelang85 2014-10-18 17:55:42 +08:00
|
 |
33
pimin 2014-10-18 18:06:52 +08:00
c用时4.4's肯定是编译时没开优化，我电脑上跑是0.86s
|
 |
34
ysjdx 2014-10-18 18:07:46 +08:00
试试pypy 会快很多
|
 |
35
ZavierXu 2014-10-18 18:11:33 +08:00
写代码从来就一个要求, 能跑就行, 追求速度不如想想如何不出错
|
 |
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是一个解释器，还要加上每次读指令、指令译码的代价，就更慢了。 =============华丽的分割线============= |
 |
39
cctvsmg 2014-10-18 18:21:13 +08:00
|
 |
40
pH 2014-10-18 18:51:00 +08:00
我一直期待有人来汇编呢
|
 |
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也可以跑到一个数量级 |
 |
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 慢吗？ |
|
43
ifishman 2014-10-18 19:30:25 +08:00
@xavierskip 确实慢，1秒和1/20000秒，慢了不只一点点。算法的不同而已。其实我不懂python……:-P
|
 |
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 |
 |
45
dant 2014-10-18 19:51:44 +08:00
来个 Ruby 的。
 |
 |
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)看一下。 |
 |
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) |
 |
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] |
 |
50
Shared 2014-10-18 21:39:12 +08:00
如果要用 Python 做这种事情要么用 PyPy，要么写个 C 扩展呗。
P.S. 这种比较好没意思 |
 |
51
davidli 2014-10-18 21:47:39 +08:00
Python下能用内置函数的情况下一定要用内置函数.
|
 |
52
ant_sz 2014-10-18 22:08:05 +08:00
我觉得从上面的回答已经可以看得出来：
语言本身的性能决定了运行时间的下限，但是程序员写程序的水平决定了运行时间的上限。 同样一个功能，不同的人写出来性能能有百倍的差距。 因此，一些情况下，语言本身的性能并没有开发效率和易用性更重要。 |
 |
53
icedx 2014-10-18 22:26:37 +08:00 1
|
 |
56
takato 2014-10-18 23:28:51 +08:00
我觉得用O(n)的算法去解决一个O(1)就能解决的问题，真是用牛刀了- -
|
 |
57
efen 2014-10-18 23:38:52 +08:00
Lisp大法好 (￣(工)￣)
尾递归版本46s，普通递归版本把8g内存全吃光，跑了7分多钟没结果，哈哈哈 |
 |
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大 好 |
 |
59
iam36 2014-10-19 00:45:57 +08:00 via Android
仅用数学运算来比对太片面了。
|
 |
60
webjin 2014-10-19 00:58:42 +08:00
不错哦
|
 |
61
NathanInMac 2014-10-19 01:37:04 +08:00
go不到500ms。。
|
 |
62
Sharuru 2014-10-19 02:11:03 +08:00 via iPhone 1
从看到这贴就好奇，楼主好坏是在一台电脑上用不同的语言做了测试，得出消耗时间不同的结论。
但是其他诸位仅做了一种语言的测试。 同样的代码不同电脑跑完全是不一样的计算结果。 辣鸡的代码在流弊的电脑上可以跑1s，高效的代码在辣鸡代码上却要跑10s… 一本正经的不明所以。 |
|
63
MonkLuf OP |
 |
65
konakona 2014-10-19 03:08:42 +08:00
我本来想打开xcode来一段swift的……可是xcode死机了……
|
 |
67
msg7086 2014-10-19 05:37:24 +08:00
|
|
68
msg7086 2014-10-19 06:21:05 +08:00
楼上的代码本来是用 AVX Intrinsics 写的，但是在不启用优化的情况下编译器会自作主张改写汇编语句结构。所以这里老老实实重写成了 inline asm 代码。要看 Intrinsics 版本的，可以去看 Gist 的提交历史。
|
 |
69
wwqgtxx 2014-10-19 07:06:51 +08:00 via Android
想知道js的运行速度
在chrome/ie/firefox下试试？ |
|
70
efen 2014-10-19 08:16:50 +08:00 via iPhone
@MonkLuf 其实主要的点是，和一般的语言不同很反直觉的是，Python的操作中，加减恰恰是最慢的，而带来的好处嘛，数值计算上实在是方便得多
|
|
71
Sharuru 2014-10-19 09:57:54 +08:00 via iPhone
不过人类最强计算器Python算大数什么的倒是非常惬意。
|
 |
72
hitsmaxft 2014-10-19 09:58:21 +08:00
不能这么比的, c 跟 java 有编译时优化, python 就只能拼人肉优化了..
|
 |
73
mille 2014-10-19 11:16:19 +08:00
sum: 500000000500000000, time used: 3.141718 's
还是我oc拯救世界😄 |
 |
74
Actrace 2014-10-19 11:16:55 +08:00
|
|
75
Actrace 2014-10-19 11:17:09 +08:00
|
|
76
Actrace 2014-10-19 11:18:33 +08:00
|
|
77
Actrace 2014-10-19 11:18:52 +08:00
终于懂贴代码了~
|
 |
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 ``` |
 |
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 |
|
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 ``` |
 |
81
geew 2014-10-19 13:20:10 +08:00
我能说你们好无聊么
|
 |
82
darkmatter 2014-10-19 13:36:02 +08:00
n(n +1)/2
|
 |
83
ChiangDi 2014-10-19 13:41:30 +08:00
Haskell 啊哈哈哈哈
 |
 |
84
dingyaguang117 2014-10-19 13:47:29 +08:00 via iPhone
卤煮，你这个不科学，只有python加出来的的是真正的和，其他的32位早就溢出了吧
|
|
85
msg7086 2014-10-19 13:51:18 +08:00
@dingyaguang117 64位
|
 |
86
tywtyw2002 2014-10-19 14:07:04 +08:00
我们比较下 gcc clang 还有icc的速度吧。。。。。然后做一下多核的曲线，这就是一篇paper了。。
|
 |
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 |
|
89
ant_sz 2014-10-19 19:15:11 +08:00
|
 |
90
lightening 2014-10-19 20:20:46 +08:00
@MonkLuf Java 效率低本来就是一种误解。我朋友做的一些证券交易系统的内核用 Java 写，速度和 C 根本不相上下。
|
 |
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 |
|
92
gihnius 2014-10-19 20:38:52 +08:00
|
 |
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 |
 |
94
aWangami 2014-10-19 21:15:22 +08:00
|
 |
95
skybr 2014-10-19 21:16:05 +08:00
js快归快, 答案是错的.
|
|
97
RelativeLayout 2014-10-19 21:50:32 +08:00
@skybr 确实! Node的计算结果是错误的！
|
|
98
RelativeLayout 2014-10-19 21:53:24 +08:00
@skybr 找到错误原因了， JavaScript最大的数只能到
9007199254740992 而答案是： 500000000500000000 http://stackoverflow.com/a/307200 |
 |
99
barbery 2014-10-19 22:08:50 +08:00
|
|
100
barbery 2014-10-19 22:09:37 +08:00
golang版本的只要0.82秒哦，亲！
|
Select Language