Python比C快 [英] Python is faster than C

问题描述

嗨！


这是对Python解释器优化趋势的咆哮。


随机排序100000个整数列表订单需要：


* 0.75秒在Python 2.1

* 0.51秒在Python 2.2

* 0.46秒在Python 2.3


Tim Peters在优化list.sort（）方面做得很好。如果我尝试使用

简单，非稳定的纯Python快速排序实现，在Python 2.3中：


* 4.83秒

* Psyco的0.21秒


迈向世界统治高级语言的第一步:-)


Psyco成功跑赢的理由C实现不是那么gcc是一个糟糕的编译器（它比Psyco的好10倍）。

原因是C实现必须使用通用''<''运算符

比较元素，而Psyco版本很快就发现它可以期望在列表中找到整数;它仍然需要检查这个

的假设，但这很便宜，然后用一台

单机指令进行比较。


类似地，这里有一些关于heapq模块的结果，这是在Python 2.4的CVS树中用C重写的
：


l = [随机。 random（）for x in range（200000）]

heapq.heapify（l）


此代码在我的笔记本电脑上执行：
< Python 2.3（纯Python）上的
* 1.96秒
Python 2.4cvs上的
* 0.18秒（用C重写）

* 0.16秒在Python上2.3与Psyco一起


所以这不是Psyco的插件，而是对当前改写标准模块C的当前趋势进行咆哮。过早优化和

所有这些。


更糟糕，更重要的是，优化开始变得可见

给程序员。例如，迭代器在有限的情况下是很好的

但我认为它们的引入在

语言中是一个重要的复杂因素;在此之前，你可以期待某个函数，你可以期望序列返回一个列表。 Python是所有列表和

dicts，其中dicts用作名称空间。现在你要小心了。
要小心。此外，更难解释：

Hi!

This is a rant against the optimization trend of the Python interpreter.

Sorting a list of 100000 integers in random order takes:

* 0.75 seconds in Python 2.1
* 0.51 seconds in Python 2.2
* 0.46 seconds in Python 2.3

Tim Peters did a great job optimizing list.sort(). If I try with a
simple, non-stable pure Python quicksort implementation, in Python 2.3:

* 4.83 seconds
* 0.21 seconds with Psyco

First step towards world domination of high-level languages :-)

The reason that Psyco manages to outperform the C implementation is not
that gcc is a bad compiler (it is about 10 times better than Psyco''s).
The reason is that the C implementation must use a generic ''<'' operator
to compare elements, while the Psyco version quickly figures out that it
can expect to find ints in the list; it still has to check this
assumption, but this is cheap and then the comparison is done with a
single machine instruction.

Similarily, here are some results about the heapq module, which is
rewritten in C in the CVS tree for Python 2.4:

l = [random.random() for x in range(200000)]
heapq.heapify(l)

This code executes on my laptop in:

* 1.96 seconds on Python 2.3 (pure Python)
* 0.18 seconds on Python 2.4cvs (rewritten in C)
* 0.16 seconds on Python 2.3 with Psyco

So this is not so much a plug for Psyco as a rant against the current
trend of rewriting standard modules in C. Premature optimization and
all that.

Worse, and more importantly, the optimization starts to become visible
to the programmer. Iterators, for example, are great in limited cases
but I consider their introduction a significant complication in the
language; before, you could expect that some function from which you
would expect a sequence returned a list. Python was all lists and
dicts, with dicts used as namespaces here and there. Nowadays you have
to be careful. Moreover, it is harder to explain:

zip（[1,2,3]，[4,5] ，6]）＃易于理解和解释
[（1,4），（2,5），（3,6）]

枚举（[6,7,8， 9]）#uh？

zip([1,2,3], [4,5,6]) # easy to understand and explain [(1, 4), (2, 5), (3, 6)]
enumerate([6,7,8,9]) # uh ?

<枚举对象位于0x401a102c>


我知道你可以随时列表（_）。我的观点是，这是一个用户可见的优化。 enumerate（）应该返回一个正常的列表，并且

它应该是别人的工作，以确保它被正确优化

如果可能的话（和我''甚至没有谈论Psyco，它可以在当前的Python实现中以合理数量的
努力完成

。

抗议 - 你好，


Armin

<enumerate object at 0x401a102c>

I know you can always do list(_). My point is that this is a
user-visible optimization. enumerate() should return a normal list, and
it should be someone else''s job to ensure that it is correctly optimized
away if possible (and I''m not even talking about Psyco, it could be done
in the current Python implementation with a reasonable amount of
effort).
Protesting-ly yours,

Armin

推荐答案

嗨！


4月1日，它结束了。

Hi !

For the 1st April, it''s finish.

Michel Claveau / Hamster写道：

Michel Claveau/Hamster wrote:

4月1日，它结束了。

For the 1st April, it''s finish.

自己检查一下。找到一台英特尔机器并从 http：//psyco.sf获取Psyco

.NET 。以下是我测试的来源：


#Magget Quickort由Magnus Lie Hetland撰写

＃ http://www.hetland.org/python/quicksort.html


def _partition（list，start，end）：

pivot = list [end]

bottom = start-1

top = end


done = 0

未完成时：


未完成时：

bottom =底部+ 1


如果底部==顶部：

完成= 1

休息


如果枢轴< list [bottom]：

list [top] = list [bottom]

break


没有完成：

top = top-1


如果top == bottom：

done = 1

break


如果列表[top]< pivot：

list [bottom] = list [top]

break


list [top] = pivot

返回顶部

def _quicksort（列表，开始，结束）：

如果开始<结束：

split = _partition（list，start，end）

_quicksort（list，start，split-1）

_quicksort（list，拆分+ 1，结束）


def quicksort（列表）：

if len（list）> 1：

_quicksort（list，0，len（list）-1）


＃__________________________________________________ __________


随机导入，时间，psyco

l =范围（100000）

random.shuffle（l）


#TIMEIT =" l.sort（）"

#TIMEIT =" quicksort（l）"

TIMEIT =" psyco.proxy（quicksort）（l）"

打印TIMEIT，''：''，

t = time.time（）

exec TIMEIT

打印时间.time（） - t


断言l ==范围（100000）

Check it for yourself. Find yourself an Intel machine and grab Psyco
from http://psyco.sf.net. Here is the source of my test:

# Python Quicksort Written by Magnus Lie Hetland
# http://www.hetland.org/python/quicksort.html

def _partition(list, start, end):
pivot = list[end]
bottom = start-1
top = end

done = 0
while not done:

while not done:
bottom = bottom+1

if bottom == top:
done = 1
break

if pivot < list[bottom]:
list[top] = list[bottom]
break

while not done:
top = top-1

if top == bottom:
done = 1
break

if list[top] < pivot:
list[bottom] = list[top]
break

list[top] = pivot
return top
def _quicksort(list, start, end):
if start < end:
split = _partition(list, start, end)
_quicksort(list, start, split-1)
_quicksort(list, split+1, end)

def quicksort(list):
if len(list) > 1:
_quicksort(list, 0, len(list)-1)

# __________________________________________________ __________

import random, time, psyco
l = range(100000)
random.shuffle(l)

#TIMEIT = "l.sort()"
#TIMEIT = "quicksort(l)"
TIMEIT = "psyco.proxy(quicksort)(l)"
print TIMEIT, '':'',
t = time.time()
exec TIMEIT
print time.time() - t

assert l == range(100000)

Armin Rigo< ar *** @ tunes.org>写道：

Armin Rigo <ar***@tunes.org> writes:

enumerate（[6,7,8,9]）#uh？

enumerate([6,7,8,9]) # uh ?

<枚举对象0x401a102c>

我知道你总是可以做列表（_）。我的观点是，这是一个用户可见的优化。 enumerate（）应该返回一个正常的列表，并且
它应该是别人的工作，以确保它被正确优化
如果可能的话（我甚至不是在谈论Psyco，它可以在当前的Python实现中以合理的努力量完成
。

<enumerate object at 0x401a102c>

I know you can always do list(_). My point is that this is a
user-visible optimization. enumerate() should return a normal list, and
it should be someone else''s job to ensure that it is correctly optimized
away if possible (and I''m not even talking about Psyco, it could be done
in the current Python implementation with a reasonable amount of
effort).

我认为枚举（xrange（1000000000））返回一个正常的列表会在一些后来的优化器有机会做任何事情之前耗尽内存。

用它。

I think enumerate(xrange(1000000000)) returning a normal list would
exhaust memory before some later optimizer had a chance to do anything
with it.

这篇关于Python比C快的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！