我有这个C ++函数，我可以使用下面的代码从Python调用它。与运行纯C ++相比，性能只有一半。有没有办法让他们的表现达到同一水平？我用-Ofast -march=native标志编译了两个代码。我不明白我可以在哪里丢失50％，因为大部分时间都应该花在C ++内核上。 Cython是否制作了我可以避免的记忆副本？
namespace diff
{
void diff_cpp(double* __restrict__ at, const double* __restrict__ a, const double visc,
const double dxidxi, const double dyidyi, const double dzidzi,
const int itot, const int jtot, const int ktot)
{
const int ii = 1;
const int jj = itot;
const int kk = itot*jtot;
for (int k=1; k<ktot-1; k++)
for (int j=1; j<jtot-1; j++)
for (int i=1; i<itot-1; i++)
{
const int ijk = i + j*jj + k*kk;
at[ijk] += visc * (
+ ( (a[ijk+ii] - a[ijk ])
- (a[ijk ] - a[ijk-ii]) ) * dxidxi
+ ( (a[ijk+jj] - a[ijk ])
- (a[ijk ] - a[ijk-jj]) ) * dyidyi
+ ( (a[ijk+kk] - a[ijk ])
- (a[ijk ] - a[ijk-kk]) ) * dzidzi
);
}
}
}
我有这个.pyx文件
# import both numpy and the Cython declarations for numpy
import cython
import numpy as np
cimport numpy as np
# declare the interface to the C code
cdef extern from "diff_cpp.cpp" namespace "diff":
void diff_cpp(double* at, double* a, double visc, double dxidxi, double dyidyi, double dzidzi, int itot, int jtot, int ktot)
@cython.boundscheck(False)
@cython.wraparound(False)
def diff(np.ndarray[double, ndim=3, mode="c"] at not None,
np.ndarray[double, ndim=3, mode="c"] a not None,
double visc, double dxidxi, double dyidyi, double dzidzi):
cdef int ktot, jtot, itot
ktot, jtot, itot = at.shape[0], at.shape[1], at.shape[2]
diff_cpp(&at[0,0,0], &a[0,0,0], visc, dxidxi, dyidyi, dzidzi, itot, jtot, ktot)
return None
我在Python中调用这个函数
import numpy as np
import diff
import time
nloop = 20;
itot = 256;
jtot = 256;
ktot = 256;
ncells = itot*jtot*ktot;
at = np.zeros((ktot, jtot, itot))
index = np.arange(ncells)
a = (index/(index+1))**2
a.shape = (ktot, jtot, itot)
# Check results
diff.diff(at, a, 0.1, 0.1, 0.1, 0.1)
print("at={0}".format(at.flatten()[itot*jtot+itot+itot//2]))
# Time the loop
start = time.perf_counter()
for i in range(nloop):
diff.diff(at, a, 0.1, 0.1, 0.1, 0.1)
end = time.perf_counter()
print("Time/iter: {0} s ({1} iters)".format((end-start)/nloop, nloop))
这是setup.py：
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
import numpy
setup(
cmdclass = {'build_ext': build_ext},
ext_modules = [Extension("diff",
sources=["diff.pyx"],
language="c++",
extra_compile_args=["-Ofast -march=native"],
include_dirs=[numpy.get_include()])],
)
这里的C ++参考文件达到了两倍的性能：
#include <iostream>
#include <iomanip>
#include <cstdlib>
#include <stdlib.h>
#include <cstdio>
#include <ctime>
#include "math.h"
void init(double* const __restrict__ a, double* const __restrict__ at, const int ncells)
{
for (int i=0; i<ncells; ++i)
{
a[i] = pow(i,2)/pow(i+1,2);
at[i] = 0.;
}
}
void diff(double* const __restrict__ at, const double* const __restrict__ a, const double visc,
const double dxidxi, const double dyidyi, const double dzidzi,
const int itot, const int jtot, const int ktot)
{
const int ii = 1;
const int jj = itot;
const int kk = itot*jtot;
for (int k=1; k<ktot-1; k++)
for (int j=1; j<jtot-1; j++)
for (int i=1; i<itot-1; i++)
{
const int ijk = i + j*jj + k*kk;
at[ijk] += visc * (
+ ( (a[ijk+ii] - a[ijk ])
- (a[ijk ] - a[ijk-ii]) ) * dxidxi
+ ( (a[ijk+jj] - a[ijk ])
- (a[ijk ] - a[ijk-jj]) ) * dyidyi
+ ( (a[ijk+kk] - a[ijk ])
- (a[ijk ] - a[ijk-kk]) ) * dzidzi
);
}
}
int main()
{
const int nloop = 20;
const int itot = 256;
const int jtot = 256;
const int ktot = 256;
const int ncells = itot*jtot*ktot;
double *a = new double[ncells];
double *at = new double[ncells];
init(a, at, ncells);
// Check results
diff(at, a, 0.1, 0.1, 0.1, 0.1, itot, jtot, ktot);
printf("at=%.20f\n",at[itot*jtot+itot+itot/2]);
// Time performance
std::clock_t start = std::clock();
for (int i=0; i<nloop; ++i)
diff(at, a, 0.1, 0.1, 0.1, 0.1, itot, jtot, ktot);
double duration = (std::clock() - start ) / (double)CLOCKS_PER_SEC;
printf("time/iter = %f s (%i iters)\n",duration/(double)nloop, nloop);
return 0;
}
答案 0 :(得分：5)
这里的问题不是运行期间发生的事情，而是在编译期间发生了哪些优化。
进行哪种优化取决于编译器（甚至版本），并且无法保证每次优化都可以完成。
实际上，cython速度较慢有两个不同的原因，这取决于你使用的是g ++还是clang ++：
-fwrapv，第一期（g ++）：与纯c ++程序的标志相比，Cython编译了不同的标志，因此无法完成某些优化。
如果查看设置日志，您会看到：
x86_64-linux-gnu-gcc ... -O2 ..-fwrapv .. -c diff.cpp ... -Ofast -march=native
正如你所说，-Ofast将赢得-O2，因为它是最后的。但问题是-fwrapv，这似乎阻止了一些优化，因为有符号整数溢出不能被视为UB并且不再用于优化。
所以你有以下选择：
-fno-wrapv添加到extra_compile_flags，缺点是所有文件现在都使用已更改的标记进行编译，这可能是不需要的。第二期（clang ++）在测试cpp程序中内联。
当我用我很老的5.4版g ++编译你的cpp程序时：
g++ test.cpp -o test -Ofast -march=native -fwrapv
-fwrapv的编译相比，它几乎慢了3倍。然而，这是优化器的一个弱点：当内联时，应该看到，没有符号整数溢出是可能的（所有维度大约是256），因此标志-fwrapv不应该有任何影响。
我的旧clang++ - 版本（3.8）似乎在这里做得更好：使用上面的标志我看不到任何性能下降。我需要通过-fno-inline禁用内联来成为一个较慢的代码，但即使没有-fwrapv，它也会变慢，即：
clang++ test.cpp -o test -Ofast -march=native -fno-inline
所以有一个系统的偏见支持你的c ++程序：优化器可以在内联之后优化已知值的代码 - 这是cython无法做到的。
所以我们可以看到：clang ++无法以任意大小优化function diff，但能够针对size = 256优化它。但是，Cython只能使用diff的非优化版本。这就是为什么-fno-wrapv没有积极影响的原因。
我对它的看法：不允许在cpp-tester中内联感兴趣的函数（例如在自己的目标文件中编译），以确保与cython的基础，否则你会看到一个特别的程序的性能针对这一输入进行了优化。
注意：有趣的是，如果所有int都被unsigned int替换，则自然-fwrapv不会扮演任何角色，但unsigned int版本会{ {1}}与int一样慢 - 版本为-fwrapv，这只是合乎逻辑的，因为没有未定义的行为可供使用。