Pythonのネイティブsum
関数とNumPyのnumpy.sum
を使用した場合のパフォーマンスと動作の違いは何ですか? sum
はNumPyの配列で機能し、numpy.sum
はPythonリストで機能し、両方とも同じ効果的な結果(オーバーフローなどのEdgeケースはテストしていません)を返しますが、タイプは異なります。
>>> import numpy as np
>>> np_a = np.array(range(5))
>>> np_a
array([0, 1, 2, 3, 4])
>>> type(np_a)
<class 'numpy.ndarray')
>>> py_a = list(range(5))
>>> py_a
[0, 1, 2, 3, 4]
>>> type(py_a)
<class 'list'>
# The numerical answer (10) is the same for the following sums:
>>> type(np.sum(np_a))
<class 'numpy.int32'>
>>> type(sum(np_a))
<class 'numpy.int32'>
>>> type(np.sum(py_a))
<class 'numpy.int32'>
>>> type(sum(py_a))
<class 'int'>
編集:ここでの私の実際的な質問は、Python整数のリストでnumpy.sum
を使用することは、Python独自のsum
を使用するよりも速いでしょうか?
さらに、Python整数とスカラーnumpy.int32
を使用することの意味(パフォーマンスを含む)は何ですか?たとえば、a += 1
の場合、a
のタイプがPython整数またはnumpy.int32
の場合、動作またはパフォーマンスに違いはありますか? Pythonコードで多くの値を加算または減算する値にnumpy.int32
などのNumPyスカラーデータ型を使用する方が速いかどうか興味があります。
明確にするために、私はバイオインフォマティクスのシミュレーションに取り組んでいます。これは、多次元のnumpy.ndarray
sを単一のスカラー和に折り畳み、さらに処理することで部分的に構成されています。 Python 3.2およびNumPy 1.6を使用しています。
前もって感謝します!
私は興味を持ち、それを計りました。 _numpy.sum
_は、numpy配列でははるかに高速に見えますが、リストでははるかに低速です。
_import numpy as np
import timeit
x = range(1000)
# or
#x = np.random.standard_normal(1000)
def pure_sum():
return sum(x)
def numpy_sum():
return np.sum(x)
n = 10000
t1 = timeit.timeit(pure_sum, number = n)
print 'Pure Python Sum:', t1
t2 = timeit.timeit(numpy_sum, number = n)
print 'Numpy Sum:', t2
_
x = range(1000)
の場合の結果:
_Pure Python Sum: 0.445913167735
Numpy Sum: 8.54926219673
_
x = np.random.standard_normal(1000)
の場合の結果:
_Pure Python Sum: 12.1442425643
Numpy Sum: 0.303303771848
_
私はPython 2.7.2およびNumpy 1.6.1を使用しています
[...]ここでの私の[...]の質問は、Python整数のリストで_
numpy.sum
_を使用すると、Python独自のsum
を使用するよりも速くなります。
この質問に対する答えは「いいえ」です。
リストではPythonの合計が速くなり、配列ではNumPysの合計が速くなります。私は実際にタイミングを示すベンチマークを行いました(Python 3.6、NumPy 1.14):
_import random
import numpy as np
import matplotlib.pyplot as plt
from simple_benchmark import benchmark
%matplotlib notebook
def numpy_sum(it):
return np.sum(it)
def python_sum(it):
return sum(it)
def numpy_sum_method(arr):
return arr.sum()
b_array = benchmark(
[numpy_sum, numpy_sum_method, python_sum],
arguments={2**i: np.random.randint(0, 10, 2**i) for i in range(2, 21)},
argument_name='array size',
function_aliases={numpy_sum: 'numpy.sum(<array>)', numpy_sum_method: '<array>.sum()', python_sum: "sum(<array>)"}
)
b_list = benchmark(
[numpy_sum, python_sum],
arguments={2**i: [random.randint(0, 10) for _ in range(2**i)] for i in range(2, 21)},
argument_name='list size',
function_aliases={numpy_sum: 'numpy.sum(<list>)', python_sum: "sum(<list>)"}
)
_
これらの結果で:
_f, (ax1, ax2) = plt.subplots(1, 2, sharey=True)
b_array.plot(ax=ax1)
b_list.plot(ax=ax2)
_
左:NumPy配列。右:Pythonリスト上。ベンチマークは非常に広範囲の値をカバーするため、これは対数プロットです。ただし、定性的な結果の場合:低いほど良いことを意味します。
これは、リストのPython sum
が常に高速であることを示していますが、配列の_np.sum
_またはsum
メソッドは高速です(Python sum
が高速な非常に短い配列を除く) 。
これらを互いに比較することに興味がある場合のために、それらすべてを含むプロットも作成しました。
_f, ax = plt.subplots(1)
b_array.plot(ax=ax)
b_list.plot(ax=ax)
ax.grid(which='both')
_
興味深いことに、numpy
がPythonおよびリストと配列上で競合できるポイントは、およそ200個の要素です!この数値は、Python/NumPyバージョンなど、多くの要因に依存する可能性があることに注意してください。文字通りに取りすぎないでください。
言及されていないのは、この違いの理由です(関数が単に一定のオーバーヘッドを持っている短いリスト/配列の違いではなく、大規模な違いを意味します)。 CPythonがPythonリストである場合、Pythonオブジェクト(この場合はPython整数)へのポインターのC(言語C)配列のラッパーです。これらの整数は、C整数のラッパーとして見ることができます(Python整数は任意に大きくなるため、実際には正しくないため、単純にone C整数を使用できませんが、十分に近いです)。
たとえば、_[1, 2, 3]
_のようなリストは、次のように保存されます(概略的に、いくつかの詳細を省略しました)。
ただし、NumPy配列は、C値を含むC配列のラッパーです(この場合、int
またはlong
は32ビットまたは64ビットに依存し、オペレーティングシステムに依存します)。
したがって、np.array([1, 2, 3])
のようなNumPy配列は次のようになります。
次に理解すべきことは、これらの機能がどのように機能するかです。
sum
は、反復可能オブジェクト(この場合はリストまたは配列)を反復処理し、すべての要素を追加します。sum
method格納されたC配列を反復処理し、これらのC値を追加し、最後にその値をPython型(この場合は_numpy.int32
_(または_numpy.int64
_)を返します。sum
functionは、入力をarray
に変換し(少なくとも配列ではない場合)、次にNumPy sum
method。C配列からC値を追加することはPythonオブジェクトを追加するよりもはるかに速いため、NumPy関数canははるかに高速です(上の2番目のプロット、NumPy関数は配列は、大きな配列ではPython合計をはるかに上回る)。
ただし、PythonリストをNumPy配列に変換するのは比較的遅いため、C値を追加する必要があります。 listsがPython sum
の方が高速になるのはそのためです。
残っている唯一の未解決の問題は、なぜsum
上のPython array
が非常に遅いかです(比較されるすべての関数の中で最も遅い)。そして、それは実際にPythonが合計を渡すことを単純に繰り返すという事実に関係しています。リストの場合は保存されますPythonオブジェクトですが、1D NumPy配列の場合は保存されませんPythonオブジェクト、C値のみ、Python&NumPyは各要素に対してPythonオブジェクト(_numpy.int32
_または_numpy.int64
_)を作成し、次にこれらのPythonオブジェクトを追加する必要があります。 C値のラッパーを作成すると、本当に遅くなります。
さらに、Python整数とスカラーnumpy.int32を使用することの意味(パフォーマンスを含む)は何ですか?たとえば、a + = 1の場合、aのタイプがPython整数またはnumpy.int32の場合、動作またはパフォーマンスの違いはありますか?
いくつかのテストを行い、スカラーの加算と減算については、Python整数に固執する必要があります。キャッシングが行われている可能性がありますが、これは次のテストが完全に代表的ではない可能性があることを意味しています。
_from itertools import repeat
python_integer = 1000
numpy_integer_32 = np.int32(1000)
numpy_integer_64 = np.int64(1000)
def repeatedly_add_one(val):
for _ in repeat(None, 100000):
_ = val + 1
%timeit repeatedly_add_one(python_integer)
3.7 ms ± 71.2 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
%timeit repeatedly_add_one(numpy_integer_32)
14.3 ms ± 162 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
%timeit repeatedly_add_one(numpy_integer_64)
18.5 ms ± 494 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
def repeatedly_sub_one(val):
for _ in repeat(None, 100000):
_ = val - 1
%timeit repeatedly_sub_one(python_integer)
3.75 ms ± 236 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
%timeit repeatedly_sub_one(numpy_integer_32)
15.7 ms ± 437 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
%timeit repeatedly_sub_one(numpy_integer_64)
19 ms ± 834 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
_
NumPyスカラーよりもPython整数でスカラー演算を行う方が3〜6倍高速です。なぜそうなのかは確認していませんが、NumPyスカラーはめったに使用されず、おそらくパフォーマンスのために最適化されていない可能性があります。
両方のオペランドがnumpyスカラーである算術演算を実際に実行する場合、違いは少し小さくなります。
_def repeatedly_add_one(val):
one = type(val)(1) # create a 1 with the same type as the input
for _ in repeat(None, 100000):
_ = val + one
%timeit repeatedly_add_one(python_integer)
3.88 ms ± 273 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
%timeit repeatedly_add_one(numpy_integer_32)
6.12 ms ± 324 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
%timeit repeatedly_add_one(numpy_integer_64)
6.49 ms ± 265 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
_
その後、わずか2倍遅くなります。
単にfor _ in range(...)
を使用できたのに、なぜここで_itertools.repeat
_を使用したのか疑問に思った場合のために。その理由は、repeat
の方が高速であり、ループごとのオーバーヘッドが少ないためです。加算/減算時間にのみ興味があるので、実際には、ループのオーバーヘッドがタイミングに干渉しないようにすることをお勧めします(少なくともそれほどではありません)。
Numpyは、特にデータが既にnumpy配列である場合、はるかに高速になるはずです。
Numpy配列は、標準C配列上の薄い層です。 numpy sumがこれを繰り返し処理するとき、型チェックは行わず、非常に高速です。速度は、標準Cを使用して操作を行うのと同等でなければなりません。
それに比べて、pythonのsumを使用して、最初にnumpy配列をpython配列に変換してから、その配列を反復処理する必要があります。何らかの型チェックを行う必要があり、通常は遅くなります。
python sumがnumpy sumより遅い正確な量は、python sumは、 pythonで独自の合計関数。
Python多次元numpy配列の合計は、最初の軸に沿った合計のみを実行することに注意してください。
sum(np.array([[[2,3,4],[4,5,6]],[[7,8,9],[10,11,12]]]))
Out[47]:
array([[ 9, 11, 13],
[14, 16, 18]])
np.sum(np.array([[[2,3,4],[4,5,6]],[[7,8,9],[10,11,12]]]), axis=0)
Out[48]:
array([[ 9, 11, 13],
[14, 16, 18]])
np.sum(np.array([[[2,3,4],[4,5,6]],[[7,8,9],[10,11,12]]]))
Out[49]: 81
これは Akavallによる上記の回答投稿 の拡張です。その答えから、np.sum
はnp.array
オブジェクトに対して高速に実行され、sum
はlist
オブジェクトに対して高速に実行されることがわかります。それを拡張するには:
np.sum
オブジェクトに対してnp.array
を実行するとVs。sum
オブジェクトに対してlist
彼らは首から首までを実行するようです。
# I'm running IPython
In [1]: x = range(1000) # list object
In [2]: y = np.array(x) # np.array object
In [3]: %timeit sum(x)
100000 loops, best of 3: 14.1 µs per loop
In [4]: %timeit np.sum(y)
100000 loops, best of 3: 14.3 µs per loop
上記のsum
はnp.array
よりもtinyビット高速ですが、時々np.sum
タイミングが14.1 µs
も。しかし、ほとんどの場合、14.3 µs
です。