 |
GordianZOct 18, 2014
1
[Citation needed]
|
 |
yuelang85Oct 18, 2014
2
没有代码啥也没法说
|
 |
3
不贴代码就说结果就是耍流氓
|
 |
caizixianOct 18, 2014
4
别告诉我你用了range
|
 |
loadingOct 18, 2014
5
java用求和公式， python用 for 一个个加？
|
 |
6
@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
当然c加上-O3优化之后1.7s解决
|
 |
FreeBTC123Oct 18, 2014
8
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]: |
|
loadingOct 18, 2014
10
你前面不给代码，我也只能这样猜！
|
 |
kyangcOct 18, 2014
11
Java和C是有编译器优化在里面的
python编译器不了解，不过看这样子应该是没的…… |
 |
zts1993Oct 18, 2014
12
我觉得可能是python3 int 无限精度引起的。。谁来解释一下。
|
 |
iscraftOct 18, 2014
13
php for 结果对不?
----5.0000000006711E+17--------103.5865240097秒---- |
 |
likexianOct 18, 2014
14
python2
sum(xrange(1, 1000000001)) 烂笔记本，用了15s |
 |
18
可惜 OS X 下没有 hacklang/hhvm，不知道会是什么样的结果。
|
 |
ifishmanOct 18, 2014
19
换了个算法，在树梅派上1/20000秒，这算不算作弊？
|
|
20
@shiny
@iscraft 不能这么对比，毕竟机器不一样，待我再测测php的，不过同样可以参考一下这篇文章的测试数据，用快排对比java/python/c的IO和计算速度： http://fantasyorg.blog.163.com/blog/static/109276109201223031127384/ |
 |
RIcterOct 18, 2014 via Android
22
python本来就不是拼速度的，何必呢。
不如手算？ |
 |
regmachOct 18, 2014
24
float 5.0000000006711E+17
65.392sec |
 |
LINAICAIOct 18, 2014
25
这个。。。为什么我感觉没必要争论，py是解析语言，c和java经过编译器优化。
|
 |
hjc4869Oct 18, 2014
26
你试试用c语言写个高精度加法的再去跟python比。
|
 |
sneezryOct 18, 2014 via iPhone
27
好不好js现在都比py快了……
|
|
sneezryOct 18, 2014 via iPhone
28
搞不好，打错了
|
 |
robbieljOct 18, 2014
29
我觉得为什么要有numpy，为什么要有cython很好地解释了你这个问题
|
|
yuelang85Oct 18, 2014
30
|
|
yuelang85Oct 18, 2014
31
|
 |
piminOct 18, 2014
33
c用时4.4's肯定是编译时没开优化，我电脑上跑是0.86s
|
 |
ysjdxOct 18, 2014
34
试试pypy 会快很多
|
 |
ZavierXuOct 18, 2014
35
写代码从来就一个要求, 能跑就行, 追求速度不如想想如何不出错
|
 |
38
楼主，你很幸运，以前我看过一篇也是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是一个解释器，还要加上每次读指令、指令译码的代价，就更慢了。 =============华丽的分割线============= |
 |
cctvsmgOct 18, 2014
39
|
 |
pHOct 18, 2014
40
我一直期待有人来汇编呢
|
 |
bigtanOct 18, 2014
41
import numpy as np
%timeit np.sum(np.arange(1,1000000000)) 1 loops, best of 3: 5.12 s per loop 不用pypy用numpy也可以跑到一个数量级 |
 |
C0VNOct 18, 2014
42
In [12]: start = time.time();sum(xrange(1,100000001));print time.time()-start
1.27270293236 慢吗？ |
|
ifishmanOct 18, 2014
43
@xavierskip 确实慢，1秒和1/20000秒，慢了不只一点点。算法的不同而已。其实我不懂python……:-P
|
 |
cloverstdOct 18, 2014
44
> 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 |
 |
dantOct 18, 2014
45
来个 Ruby 的。
 |
 |
lushl9301Oct 18, 2014
46
@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)看一下。 |
 |
ovearOct 18, 2014
47
我也来一个版本，运行时决定累加数目
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) |
 |
NahN2ReghOct 18, 2014
49
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] |
 |
SharedOct 18, 2014
50
如果要用 Python 做这种事情要么用 PyPy，要么写个 C 扩展呗。
P.S. 这种比较好没意思 |
 |
davidliOct 18, 2014
51
Python下能用内置函数的情况下一定要用内置函数.
|
 |
ant_szOct 18, 2014
52
我觉得从上面的回答已经可以看得出来：
语言本身的性能决定了运行时间的下限，但是程序员写程序的水平决定了运行时间的上限。 同样一个功能，不同的人写出来性能能有百倍的差距。 因此，一些情况下，语言本身的性能并没有开发效率和易用性更重要。 |
 |
53
|
 |
takatoOct 18, 2014
56
我觉得用O(n)的算法去解决一个O(1)就能解决的问题，真是用牛刀了- -
|
 |
efenOct 18, 2014
57
Lisp大法好 (￣(工)￣)
尾递归版本46s，普通递归版本把8g内存全吃光，跑了7分多钟没结果，哈哈哈 |
 |
wdlthOct 19, 2014
58
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大 好 |
 |
iam36Oct 19, 2014 via Android
59
仅用数学运算来比对太片面了。
|
 |
webjinOct 19, 2014
60
不错哦
|
 |
NathanInMacOct 19, 2014
61
go不到500ms。。
|
 |
62
从看到这贴就好奇，楼主好坏是在一台电脑上用不同的语言做了测试，得出消耗时间不同的结论。
但是其他诸位仅做了一种语言的测试。 同样的代码不同电脑跑完全是不一样的计算结果。 辣鸡的代码在流弊的电脑上可以跑1s，高效的代码在辣鸡代码上却要跑10s… 一本正经的不明所以。 |
|
63
|
 |
konakonaOct 19, 2014
65
我本来想打开xcode来一段swift的……可是xcode死机了……
|
 |
msg7086Oct 19, 2014
67
|
|
msg7086Oct 19, 2014
68
楼上的代码本来是用 AVX Intrinsics 写的，但是在不启用优化的情况下编译器会自作主张改写汇编语句结构。所以这里老老实实重写成了 inline asm 代码。要看 Intrinsics 版本的，可以去看 Gist 的提交历史。
|
 |
wwqgtxxOct 19, 2014 via Android
69
想知道js的运行速度
在chrome/ie/firefox下试试？ |
|
efenOct 19, 2014 via iPhone
70
@MonkLuf 其实主要的点是，和一般的语言不同很反直觉的是，Python的操作中，加减恰恰是最慢的，而带来的好处嘛，数值计算上实在是方便得多
|
|
SharuruOct 19, 2014 via iPhone
71
不过人类最强计算器Python算大数什么的倒是非常惬意。
|
 |
hitsmaxftOct 19, 2014
72
不能这么比的, c 跟 java 有编译时优化, python 就只能拼人肉优化了..
|
 |
milleOct 19, 2014
73
sum: 500000000500000000, time used: 3.141718 's
还是我oc拯救世界😄 |
 |
ActraceOct 19, 2014
74
|
|
ActraceOct 19, 2014
75
|
|
ActraceOct 19, 2014
76
|
|
ActraceOct 19, 2014
77
终于懂贴代码了~
|
 |
gihniusOct 19, 2014
78
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 ``` |
 |
ptyforkOct 19, 2014
79
$ 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 |
|
gihniusOct 19, 2014
80
@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 ``` |
 |
geewOct 19, 2014
81
我能说你们好无聊么
|
 |
darkmatterOct 19, 2014
82
n(n +1)/2
|
 |
ChiangDiOct 19, 2014
83
Haskell 啊哈哈哈哈
 |
 |
dingyaguang117Oct 19, 2014 via iPhone
84
卤煮，你这个不科学，只有python加出来的的是真正的和，其他的32位早就溢出了吧
|
|
msg7086Oct 19, 2014
85
@dingyaguang117 64位
|
 |
tywtyw2002Oct 19, 2014
86
我们比较下 gcc clang 还有icc的速度吧。。。。。然后做一下多核的曲线，这就是一篇paper了。。
|
 |
jacobOct 19, 2014
87
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 |
|
ant_szOct 19, 2014
89
|
 |
lighteningOct 19, 2014
90
@MonkLuf Java 效率低本来就是一种误解。我朋友做的一些证券交易系统的内核用 Java 写，速度和 C 根本不相上下。
|
 |
AWSAMOct 19, 2014
91
@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 |
|
gihniusOct 19, 2014
92
|
 |
RelativeLayoutOct 19, 2014
93
我这儿排序是这样的：
Java 1.05s Node 1.38s C 2.93s Python 100+s Node https://gist.github.com/daimajia/dd7bf30f498300fa31e0 |
 |
aWangamiOct 19, 2014
94
|
 |
skybrOct 19, 2014
95
js快归快, 答案是错的.
|
|
RelativeLayoutOct 19, 2014
97
@skybr 确实! Node的计算结果是错误的！
|
|
RelativeLayoutOct 19, 2014
98
@skybr 找到错误原因了， JavaScript最大的数只能到
9007199254740992 而答案是： 500000000500000000 http://stackoverflow.com/a/307200 |
 |
barberyOct 19, 2014
99
|
|
barberyOct 19, 2014
100
golang版本的只要0.82秒哦，亲！
|
1
Select Language