Python很慢？ [英] Python is slow?
问题描述
我最近一直在玩kd-tree来解决post
办公室问题。在12维空间。这是纯粹的cpu绑定
数字运算，我怀疑Python的任务是低效的。
我的原型在使用NumPy的Python 2.5需要0.41秒才能从50,000个样本构建树。不幸的是，搜索它b / b $ b感觉有点慢，找到了11个最近邻居的1000分
花了29.6秒（还有49,000个去）。当然，我把这归咎于Python。如果我使用C ++会快100倍，
对吧？
有了一个可用的Python原型后，我就改写了
$用C ++编写的b $ b程序。 Python原型需要一个小时来制作，调试和验证。 C ++中的同样的事情花了我差不多一天的时间来完成，甚至还有一个工作原型作为模型的
。令我惊讶的是，由此产生的野兽
的C ++需要64.3秒来构建相同的kd树。搜索
树也不快，1000点需要38.8秒。我每天浪费
只是为了发现我的Python原型更快。
我们可能会认为我在编写C ++时很糟糕，但是我怀疑那是
不是这里的情况。虽然微基准可能表明Python比C ++慢100-200倍，但它们可能不适用于真正的b $ b世界。 Python可以非常高效。当与NumPy这样的库结合使用时，用手工制作的C ++打败它的性能很难实现。至少，我用各种语言编程科学
软件的10年经验还不足以用C ++打败我自己的Python
原型。
这并不是说我从未见过C ++的运行速度比Python快得多。
但它往往是非常短的CPU绑定代码，不超过一个
函数或两个。但随着问题的复杂性增加，C ++
积累了太多的膨胀。
I have recently been playing with a kd-tree for solving the "post
office problem" in a 12-dimensional space. This is pure cpu bound
number crunching, a task for which I suspected Python to be
inefficient.
My prototype in Python 2.5 using NumPy required 0.41 seconds to
construct the tree from 50,000 samples. Unfortunately, searching it
felt a bit slow, finding the 11 nearest-neighbours of 1,000 points
took 29.6 seconds (and there were still 49,000 to go). Naturally, I
blamed this on Python. It would be 100 times faster if I used C++,
right?
After having a working Python prototype, I resorted to rewrite the
program in C++. The Python prototype took an hour to make, debug and
verify. The same thing in C++ took me almost a day to complete, even
with a working prototype as model. To my surprise, the resulting beast
of C++ required 64.3 seconds to construct the same kd-tree. Searching
the tree was not faster either, 1,000 points required 38.8 seconds. I
wasted a day, only to find my Python prototype being the faster.
We may conclude that I''m bad at programming C++, but I suspect that is
not the case here. Albeit micro-benchmarks may indicate that Python is
100-200 times slower than C++, they may not be applicable to the real
world. Python can be very efficient. And when combined with libraries
like NumPy, beating it''s performance with hand-crafted C++ is
difficult. At least, my 10 years experience programming scientific
software in various languages was not sufficient to beat my own Python
prototype with C++.
That is not to say I have never seen C++ run a lot faster than Python.
But it tends to be very short pieces of CPU bound code, no more than a
function or two. But as the problem grows in complexity, C++
accumulates too much of its own bloat.
推荐答案
周二，23日2008年9月06:23:12 -0700（PDT），sturlamolden
< st ********** @ yahoo.nowrote：
On Tue, 23 Sep 2008 06:23:12 -0700 (PDT), sturlamolden
<st**********@yahoo.nowrote:
>我最近一直在使用kd-tree来解决post
办公室问题。在12维空间。这是纯粹的cpu绑定数字运算，我怀疑Python的任务效率低下。
>I have recently been playing with a kd-tree for solving the "post
office problem" in a 12-dimensional space. This is pure cpu bound
number crunching, a task for which I suspected Python to be
inefficient.
好吧，python不是一种数字运算语言。不管怎样，我们会像它一样（我们愿意？:-)。没有脚本语言。
开发时间较短，我同意，但是当你有，例如一个
问题需要花费8,31分钟来完成优化的fortran
代码（就像我前几天那样），然后这几乎不重要。
Well, python is not a number crunching language. However much we would
like it to be (we would ? :-). No scripting language is.
Developing time is shorter, I agree, but when you have, for example a
problem which takes 8,31 minutes to go through in optimized fortran
code (like the one I had the other day), then that hardly matters.
>
我的原型在使用NumPy的Python 2.5需要0.41秒来构建50,000个样本的树。不幸的是，搜索它感觉有点慢，找到11个最近邻居的1000点
需要29.6秒（还有49,000个去）。当然，我将此归咎于Python。如果我使用C ++，它会快100倍，对吧？
>
My prototype in Python 2.5 using NumPy required 0.41 seconds to
construct the tree from 50,000 samples. Unfortunately, searching it
felt a bit slow, finding the 11 nearest-neighbours of 1,000 points
took 29.6 seconds (and there were still 49,000 to go). Naturally, I
blamed this on Python. It would be 100 times faster if I used C++,
right?
不一定。
在尝试重写问题之前，请尝试psyco。它有时会加速
。
另外，（我对python还不熟悉，所以我不知道怎么回事
在python中执行此操作，尝试查找计算的瓶颈。
大部分处理时间浪费的循环，或者访问磁盘
，或者......？
Not necessarily.
Before resorting to rewriting the problem try psyco. It speeds up
things sometimes.
Also, (I''m not that familiar with python yet, so I don''t know how to
do it in python), try finding the bottlenecks of your calculation. Are
the loops where most of the processing time is wasted, or disk
accessing, or ... ?
>
在使用了Python原型后，我使用C ++重写了
程序。 Python原型花了一个小时来制作，调试和验证。 C ++中的同样的事情花了我差不多一天才完成，甚至用一个工作原型作为模型。令我惊讶的是，由此产生的C ++野兽需要64.3秒来构建相同的kd树。搜索树也不快，1000点需要38.8秒。我浪费了一天，却发现我的Python原型更快。
>
After having a working Python prototype, I resorted to rewrite the
program in C++. The Python prototype took an hour to make, debug and
verify. The same thing in C++ took me almost a day to complete, even
with a working prototype as model. To my surprise, the resulting beast
of C++ required 64.3 seconds to construct the same kd-tree. Searching
the tree was not faster either, 1,000 points required 38.8 seconds. I
wasted a day, only to find my Python prototype being the faster.
>
我们可能会认为我在编程C ++方面不好，但我怀疑是
不是这里的情况。虽然微基准测试可能表明Python比C ++慢100-200倍，但它们可能不适用于真实的世界。 Python可以非常高效。当与像NumPy这样的库结合使用时，用手工制作的C ++打败它的性能是很困难的。至少，我用各种语言编程科学软件的10年经验不足以用C ++打败我自己的Python原型。
这并不是说我从未见过C ++运行速度比Python快得多。
但它往往是非常短的CPU绑定代码，只不过是一两个功能。但随着问题的复杂性增加，C ++积累了太多自己的膨胀。
>
We may conclude that I''m bad at programming C++, but I suspect that is
not the case here. Albeit micro-benchmarks may indicate that Python is
100-200 times slower than C++, they may not be applicable to the real
world. Python can be very efficient. And when combined with libraries
like NumPy, beating it''s performance with hand-crafted C++ is
difficult. At least, my 10 years experience programming scientific
software in various languages was not sufficient to beat my own Python
prototype with C++.
That is not to say I have never seen C++ run a lot faster than Python.
But it tends to be very short pieces of CPU bound code, no more than a
function or two. But as the problem grows in complexity, C++
accumulates too much of its own bloat.
嗯，个人而言，我试图结合fortran（作为一个堡垒程序员
交易）与python（在过去的几年里），因为我发现fortran to
，两个等级，更适合解决科学问题
然后c（或python，尽管它有它的优点）。
从他的正常能力开始数组处理，
优化和易读性，以及诸如此类。
最好的问候
Bob
Well, personally, I try to combine fortran (being a fortran programmer
by trade) with python (in the last few years), as I find fortran to
be, by two grades, more comfortable for solving scientific problems
then c (or python for that matter, although it has its merits).
Starting from ith his capabilities for "normal" array handling, to
optimisation and easy readability, to whatnot.
Best regards
Bob
2008-09-23，sturlamolden< st ********** @ yahoo.nowrote：
[...]
On 2008-09-23, sturlamolden <st**********@yahoo.nowrote:
[...]
在使用了Python原型后，我使用C ++重写了
程序。 Python原型需要一个小时来制作，调试和验证。 C ++中的同样的事情花了我差不多一天的时间来完成，甚至还有一个工作原型作为模型的
。令我惊讶的是，由此产生的野兽
的C ++需要64.3秒来构建相同的kd树。搜索
树也不快，1000点需要38.8秒。我每天浪费
只是为了发现我的Python原型更快。
我们可能会认为我在编程C ++时很糟糕，
After having a working Python prototype, I resorted to rewrite the
program in C++. The Python prototype took an hour to make, debug and
verify. The same thing in C++ took me almost a day to complete, even
with a working prototype as model. To my surprise, the resulting beast
of C++ required 64.3 seconds to construct the same kd-tree. Searching
the tree was not faster either, 1,000 points required 38.8 seconds. I
wasted a day, only to find my Python prototype being the faster.
We may conclude that I''m bad at programming C++,
AFAICT，_everybody_不善于编程C ++。
人们开始怀疑这不是程序员的错。
-
格兰特爱德华兹格兰特哇！最后，Zippy
驾驶他的1958年RAMBLER
visi.com METROPOLITAN进入
教师餐厅。
AFAICT, _everybody_ is bad at programming C++.
One begins to suspect it''s not the fault of the programmers.
--
Grant Edwards grante Yow! Finally, Zippy
at drives his 1958 RAMBLER
visi.com METROPOLITAN into the
faculty dining room.
9月23日上午9:57，Grant Edwards< gra ... @ visi.comwrote：
On Sep 23, 9:57 am, Grant Edwards <gra...@visi.comwrote:
2008-09- 23，sturlamolden< sturlamol ... @ yahoo.nowrote：
[...]
On 2008-09-23, sturlamolden <sturlamol...@yahoo.nowrote:
[...]
在使用Python原型时，我使用C ++重写了
程序。 Python原型需要一个小时来制作，调试和验证。 C ++中的同样的事情花了我差不多一天的时间来完成，甚至还有一个工作原型作为模型的
。令我惊讶的是，由此产生的野兽
的C ++需要64.3秒来构建相同的kd树。搜索
树也不快，1000点需要38.8秒。我每天浪费
，只是发现我的Python原型更快。
After having a working Python prototype, I resorted to rewrite the
program in C++. The Python prototype took an hour to make, debug and
verify. The same thing in C++ took me almost a day to complete, even
with a working prototype as model. To my surprise, the resulting beast
of C++ required 64.3 seconds to construct the same kd-tree. Searching
the tree was not faster either, 1,000 points required 38.8 seconds. I
wasted a day, only to find my Python prototype being the faster.
我们可能会得出结论，我不擅长编程C ++，
We may conclude that I''m bad at programming C++,
AFAICT ，_everybody_不善于编程C ++。
AFAICT, _everybody_ is bad at programming C++.
+1 QOTW
+1 QOTW
这篇关于Python很慢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
