在Visual Studio编译器上使用OpenMP的C扩展使用Cython或ctypes调用逐渐变慢了

问题描述

我有一个C函数，它执行一些我想从python脚本调用的I / O操作和解码。

C函数在由Visual Studio命令行C编译器编译时可以正常工作，并且在禁用多线程的情况下通过Cython调用时也可以正常工作。但是，当使用OpenMP多线程进行调用时，它在前几百万个循环中都可以很好地工作，但是随后接下来的数百万个循环中，CPU使用率却缓慢下降，直到最终停止并且没有失败，但也没有继续进行计算

C文件如下：

//block_reader.c

#include "block_reader.h" //contains block_data_t,decode_block,get_block_data
#include <stdio.h>
#include <stdlib.h>

#define NTHREADS 8

int decode_blocks(block_data_t *block_data_array,int num_blocks,int *values){
  int block;
#pragma omp parallel for num_threads(NTHREADS)
  for(block=0; block<num_blocks; block++){
    decode_block(block_data_array[i],values);
  }

}

int main(int argc,char *argv[]) {
  int num_blocks = 250000,block_size = 4096;
  block_data_t *block_data_array = get_block_data();

  int *values = (long long *)malloc(num_blocks * block_size * sizeof(int));

  int i,block;
  for(i=0; i<1000; i++){
    printf("experiment #%d\n",i+1);

    decode_blocks(block_data_array,values)
    }
  }
}

在Visual Studio x64命令行上使用cl /W3 -openmp block_reader.c block_helper.c zstd.lib进行编译时，主函数循环将一直进行＃1000实验，CPU利用率始终为90％（我的机器有8个逻辑线程，我不知道为什么在纯C语言中将其限制为90％，当我从openMP编译指示中删除num_threads（NTHREADS）时，也会遇到相同的问题，但我并不为此担心）。

但是，当我将其包装在Cython中并在python中循环时：

#block_reader_wrapper.pyx

from libc.stdlib cimport malloc
from libc.stdio cimport printf
cimport openmp
cimport block_reader_defns #contains block_data_t

import numpy as np
cimport numpy as np

cimport cython

@cython.boundscheck(False)  # Deactivate bounds checking.
@cython.wraparound(False)   # Deactivate negative indexing.
cpdef tuple read_blocks(block_data_array):

  cdef np.ndarray[np.int32_t,ndim=1] values = np.zeros(size,dtype=np.int32_t)
  cdef int[::1] values_view = values

  decode_blocks(block_data_array,len(block_data_array),num_blocks,&values_view[0])

  return values

cdef extern from "block_reader.h":
  int decode_blocks(char**,b_metadata*,unsigned int,unsigned long long*,long long*,int*)



#setup.block_reader_wrapper.py

from setuptools import setup,Extension
from Cython.Build import cythonize
import numpy

ext_modules = [
    Extension(
        "block_reader_wrapper",["block_reader_wrapper.pyx","block_reader.c","block_helper.c"],libraries=["zstd"],library_dirs=["{dir}/vcpkg/installed/x64-windows/lib"],include_dirs=['{dir}/vcpkg/installed/x64-windows/include',numpy.get_include()],extra_compile_args=['/openmp','-O2'],#Have tried -O2,-O3 and no optimization
        extra_link_args=['/openmp'],#always gets LINK : warning LNK4044: unrecognized option '/openmp'; ignored despite the docs asking for it https://cython.readthedocs.io/en/latest/src/userguide/parallelism.html
    )
]

setup(
    ext_modules = cythonize(ext_modules,gdb_debug=True,annotate=True,)
)


#experiment.py

from block_reader_wrapper import read_blocks
from block_data_gen import get_block_data

for i in range(1000):
  print("experiment",i+1)
  read_blocks(get_block_data())

我进入实验10，CPU使用率为100％（并且运行速度比上限为90％的纯C快），但是然后在实验11-实验16之间，CPU的使用以1逻辑的增量缓慢降低线程价值的资源，直到CPU使用率达到1个逻辑线程的底部为止，但是尽管我的任务管理器声称python正在使用我的CPU使用率的20％左右，但是该进程仍停止输出数据。内存使用率始终很低（〜10％）。

我认为这与Cython的OpenMP链接有关，也许暗含了限制我可以传递给其工作线程的有效负载的数量。

任何见识将不胜感激，我最终需要在Windows 和 Ubuntu上使用它，这就是为什么我首先选择openMP的原因。

编辑1：根据DavidW的建议，我替换了：

cdef np.ndarray[np.int32_t,dtype=np.int32_t)

具有：

cdef array.array values,values_temp
values_temp = array.array('q',[])
values = array.clone(values_temp,size,zero=True)

不幸的是，这不能解决问题。

编辑2和3：在对进程进行“停止”分析后，我发现有大量的CPU时间用于等待。具体来说，模块ucrtbase.dll中的功能free_base和malloc_base

编辑4：我使用ctypes而不是cython重写了包装器，它利用了相同的C-> Python API，因此，存在相同的问题也就不足为奇了（尽管它的运行速度比停顿快了两倍） ctypes超过Cython。

VTune摘要：

Elapsed Time:   285419.416s
    CPU Time:   22708.709s
    Effective Time: 9230.924s
    Spin Time:  13477.785s
    Overhead Time:  0s
    Total Thread Count: 10
    Paused Time:    0s


Top Hotspots
    Function    Module  CPU Time
    free_base   ucrtbase.dll    9061.852s
    malloc_base ucrtbase.dll    8308.887s
    NtWaitForSingleObject   ntdll.dll   1283.721s
    func@0x180020020    USER32.dll  820.759s
    func@0x18001c630    tsc_block_reader.cp38-win_amd64.pyd 753.774s
    [Others]    N/A*    2479.716s

Effective CPU Utilization Histogram
    Simultaneously Utilized Logical CPUs    Elapsed Time    Utilization threshold

    0   279744.7901384001   Idle
    1   5446.2851121    Poor
    2   177.8078306 Poor
    3   40.3033061  Poor
    4   10.2292884  Poor
    5   0   Poor
    6   0   Poor
    7   0   Ok
    8   0   Ideal

即使说大约80％的CPU时间处于空闲状态，但应该在30秒内完成的循环在两天后甚至都没有完成，因此，闲置时间要超过80％。

看起来大部分空闲时间都花在ucrtbase.dll

中

解决方法

暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！

如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。

小编邮箱:dio#foxmail.com (将#修改为@）