首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >cython内存视图的索引速度很慢

cython内存视图的索引速度很慢
EN

Stack Overflow用户
提问于 2019-01-29 02:45:42
回答 1查看 334关注 0票数 0

我有一个非常稀疏的矩阵,比如说5000x3000,双精度浮点数。这个矩阵的80%是零。我需要计算每一行的和。所有这些都在python/cython中实现。我想加快这个过程。因为我需要计算这个和几百万次,所以我认为如果我对非零元素进行索引,并且只对它们求和,会更快。结果变得比原来的“蛮力”全零求和慢得多。

下面是一个最小的例子:

代码语言:javascript
复制
#cython: language_level=2
import  numpy as np
cimport numpy as np
import time


cdef int Ncells = 5000, KCells = 400, Ne= 350
cdef double x0=0.1, x1=20., x2=1.4, x3=2.8, p=0.2

# Setting up weight
all_weights = np.zeros( (Ncells,KCells) )
all_weights[  :Ne,   :Ne ] = x0
all_weights[  :Ne, Ne:   ] = x1  
all_weights[Ne:  ,   :Ne ] = x2
all_weights[Ne:  , Ne:   ] = x3  
all_weights = all_weights * (np.random.rand(Ncells,KCells) < p)

# Making a memory view
cdef np.float64_t[:,:] my_weights = all_weights

# make an index of non zero weights
x,y    = np.where( np.array(my_weights) > 0.)  
#np_pawid  = np.column_stack( (x   ,y   ) )
np_pawid  = np.column_stack( (x   ,y   ) ).astype(int)
cdef np.int_t[:,:] pawid = np_pawid

# Making vector for column sum
summEE = np.zeros(KCells)
# Memory view
cdef np.float64_t [:] my_summEE = summEE
cdef int cc,dd,i

# brute-force summing
ntm = time.time()
for cc in range(KCells):
    my_summEE[cc] = 0
    for dd in range(Ncells):
        my_summEE[cc] += my_weights[dd,cc]
stm = time.time()
print "BRUTE-FORCE summation        : %f s"%(stm-ntm)

my_summEE[:] = 0
# summing only non zero indices
ntm = time.time()
for dd,cc in pawid:
    my_summEE[cc] += my_weights[dd,cc]
stm = time.time()
print "INDEX summation              : %f s"%(stm-ntm)

my_summEE[:] = 0
# summing only non zero indices unpacked by zip
ntm = time.time()
for dd,cc in zip(pawid[:,0],pawid[:,1]):
    my_summEE[cc] += my_weights[dd,cc]
stm = time.time()
print "ZIPPED INDEX summation       : %f s"%(stm-ntm)

my_summEE[:] = 0
# summing only non zero indices unpacked by zip
ntm = time.time()
for i in range(pawid.shape[0]):
    dd = pawid[i,0]
    cc = pawid[i,1]
    my_summEE[cc] += my_weights[dd,cc]
stm = time.time()
print "INDEXING over INDEX summation: %f s"%(stm-ntm)

# Numpy brute-froce summing
ntm = time.time()
sumwee = np.sum(all_weights,axis=0)
stm = time.time()
print "NUMPY BRUTE-FORCE summation  : %f s"%(stm-ntm)

#>
print
print "Number of brute-froce summs  :",my_weights.shape[0]*my_weights.shape[1]
print "Number of indexing    summs  :",pawid.shape[0]
#<

我在Raspberry Pi 3上运行了它,但在PC上似乎也是一样的结果。

代码语言:javascript
复制
BRUTE-FORCE summation        : 0.381014 s
INDEX summation              : 18.479018 s
ZIPPED INDEX summation       : 3.615952 s
INDEXING over INDEX summation: 0.450131 s
NUMPY BRUTE-FORCE summation  : 0.013017 s

Number of brute-froce summs  : 2000000
Number of indexing    summs  : 400820

NUMPY BRUTE-FORCE in Python  : 0.029143 s

有人能解释一下为什么cython代码比numpy慢3-4倍吗?为什么索引将求和次数从2000000减少到400820,速度要慢45倍?这没有任何意义。

EN

回答 1

Stack Overflow用户

发布于 2019-01-29 03:39:49

  1. ,你在一个函数之外,所以访问全局变量。这意味着Cython必须在每次访问时检查它们的存在,这与它知道不能从其他地方访问的函数局部变量不同。默认情况下,
  2. 处理负索引并执行边界检查。你可以使用turn these off in a number of ways。一种显而易见的方法是将@cython.wraparound(False)@cython.boundscheck(False)作为装饰器添加到函数定义中。请注意它们的实际用途--仅在cdefed numpy数组或类型化内存视图上关闭这些功能,而不适用于其他任何类型(因此,不要将它们应用于所有地方作为货物狂热类型)。

查看问题所在的好方法是运行cython -a <filename>并查看带注释的html文件。带有黄色的区域可能没有优化,您可以展开这些行来查看底层的C代码。显然,在这方面只需要担心频繁调用的函数和循环-事实上,设置Numpy数组的代码包含Python调用是意料之中的,而不是问题。

以下是一些测量结果:

正如你所写的

代码语言:javascript
复制
BRUTE-FORCE summation        : 0.008625 s
INDEX summation              : 0.713661 s
ZIPPED INDEX summation       : 0.127343 s
INDEXING over INDEX summation: 0.002154 s
NUMPY BRUTE-FORCE summation  : 0.001461 s

在函数中

代码语言:javascript
复制
BRUTE-FORCE summation        : 0.007706 s
INDEX summation              : 0.681892 s
ZIPPED INDEX summation       : 0.123176 s
INDEXING over INDEX summation: 0.002069 s
NUMPY BRUTE-FORCE summation  : 0.001429 s

在关闭了boundscheck和wraparound的函数中:

代码语言:javascript
复制
BRUTE-FORCE summation        : 0.005208 s
INDEX summation              : 0.672948 s
ZIPPED INDEX summation       : 0.124641 s
INDEXING over INDEX summation: 0.002006 s
NUMPY BRUTE-FORCE summation  : 0.001467 s

我的建议确实有帮助,但不是太戏剧性。我的差异并不像您看到的那样显著(即使对于未更改的代码也是如此)。Numpy仍然赢了--猜一猜:

我怀疑它在整个数组上的multithreading.

  • a直接求和将具有可预测的内存访问模式,这可能使其比使用不可预测的内存访问的较少数量的操作更有效
票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/54408389

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档