调用numba jit函数时,cProfile会增加很多开销

Question

将纯Python无操作函数与装饰的无操作函数进行比较@numba.jit,即:

import numba

@numba.njit
def boring_numba():
    pass

def call_numba(x):
    for t in range(x):
        boring_numba()

def boring_normal():
    pass

def call_normal(x):
    for t in range(x):
        boring_normal()

如果我们计算时间%timeit,我们会得到以下结果:

%timeit call_numba(int(1e7))
792 ms ± 5.51 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit call_normal(int(1e7))
737 ms ± 2.7 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

一切都很合理; numba函数的开销很小,但并不多.

但是,如果我们使用cProfile这个代码进行分析,我们会得到以下结果:

cProfile.run('call_numba(int(1e7)); call_normal(int(1e7))', sort='cumulative')

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
     76/1    0.003    0.000    8.670    8.670 {built-in method builtins.exec}
        1    6.613    6.613    7.127    7.127 experiments.py:10(call_numba)
        1    1.111    1.111    1.543    1.543 experiments.py:17(call_normal)
 10000000    0.432    0.000    0.432    0.000 experiments.py:14(boring_normal)
 10000000    0.428    0.000    0.428    0.000 experiments.py:6(boring_numba)
        1    0.000    0.000    0.086    0.086 dispatcher.py:72(compile)

cProfile认为调用numba函数有很大的开销.这扩展到"真正的"代码:我有一个函数,简单地称我的昂贵的计算(计算是numba-JIT编译),并cProfile报告包装函数占用了总时间的三分之一左右.

我不介意cProfile添加一些开销,但如果它在增加开销的地方大不一致,那就不是很有帮助了.有没有人知道为什么会发生这种情况,是否有任何可以做的事情,和/或是否有任何其他的分析工具与numba没有严重的交互？

Answer 1

当你创建一个numba函数时,你实际上创建了一个numba Dispatcher对象.该对象"重定向"一个"调用"到boring_numba正确的(就类型而言)内部"jitted"函数.所以即使你创建了一个名为的函数boring_numba- 这个函数没有被调用,所谓的是基于你的函数的编译函数.

只是这样你可以看到函数boring_numba被调用(即使它不是,所谓的是CPUDispatcher.__call__)在分析期间Dispatcher对象需要挂钩到当前线程状态并检查是否有运行的探查器/跟踪器以及是否"是"它使它看起来像boring_numba被调用.这最后一步是产生开销的原因,因为它必须伪造一个"Python堆栈帧" boring_numba.

更技术性:

当你调用numba函数时,boring_numba它实际上调用Dispatcher_Call哪个是包装器call_cfunc,这是主要区别:当你有一个分析器运行时,处理分析器的代码构成了函数调用的大部分(只需将if (tstate->use_tracing && tstate->c_profilefunc)分支与else分支进行比较)如果没有探查器/跟踪器,则正在运行):

static PyObject *
call_cfunc(DispatcherObject *self, PyObject *cfunc, PyObject *args, PyObject *kws, PyObject *locals)
{
    PyCFunctionWithKeywords fn;
    PyThreadState *tstate;
    assert(PyCFunction_Check(cfunc));
    assert(PyCFunction_GET_FLAGS(cfunc) == METH_VARARGS | METH_KEYWORDS);
    fn = (PyCFunctionWithKeywords) PyCFunction_GET_FUNCTION(cfunc);
    tstate = PyThreadState_GET();
    if (tstate->use_tracing && tstate->c_profilefunc)
    {
        /*
         * The following code requires some explaining:
         *
         * We want the jit-compiled function to be visible to the profiler, so we
         * need to synthesize a frame for it.
         * The PyFrame_New() constructor doesn't do anything with the 'locals' value if the 'code's
         * 'CO_NEWLOCALS' flag is set (which is always the case nowadays).
         * So, to get local variables into the frame, we have to manually set the 'f_locals'
         * member, then call `PyFrame_LocalsToFast`, where a subsequent call to the `frame.f_locals`
         * property (by virtue of the `frame_getlocals` function in frameobject.c) will find them.
         */
        PyCodeObject *code = (PyCodeObject*)PyObject_GetAttrString((PyObject*)self, "__code__");
        PyObject *globals = PyDict_New();
        PyObject *builtins = PyEval_GetBuiltins();
        PyFrameObject *frame = NULL;
        PyObject *result = NULL;

        if (!code) {
            PyErr_Format(PyExc_RuntimeError, "No __code__ attribute found.");
            goto error;
        }
        /* Populate builtins, which is required by some JITted functions */
        if (PyDict_SetItemString(globals, "__builtins__", builtins)) {
            goto error;
        }
        frame = PyFrame_New(tstate, code, globals, NULL);
        if (frame == NULL) {
            goto error;
        }
        /* Populate the 'fast locals' in `frame` */
        Py_XDECREF(frame->f_locals);
        frame->f_locals = locals;
        Py_XINCREF(frame->f_locals);
        PyFrame_LocalsToFast(frame, 0);
        tstate->frame = frame;
        C_TRACE(result, fn(PyCFunction_GET_SELF(cfunc), args, kws));
        tstate->frame = frame->f_back;

    error:
        Py_XDECREF(frame);
        Py_XDECREF(globals);
        Py_XDECREF(code);
        return result;
    }
    else
        return fn(PyCFunction_GET_SELF(cfunc), args, kws);
}

我假设这个额外的代码(在分析器运行的情况下)在你进行cProfile时会减慢功能.

有点不幸的是,当您运行探查器时,numba函数会增加很多开销,但如果您在numba函数中执行任何实质性操作,那么减速实际上几乎可以忽略不计.如果你也想for在一个numba函数中移动循环,那么更是如此.

如果您注意到numba函数(运行或不运行探测器)需要花费太多时间,那么您可能会经常调用它.然后你应该检查你是否可以在numba函数中实际移动循环,或者将包含循环的代码包装在另一个numba函数中.

注意:所有这些都是(有点)推测,我实际上没有使用调试符号构建numba并在运行探查器的情况下对C-Code进行分析.但是,如果运行分析器运行的操作量使得这似乎非常合理.所有这一切都假设为numba 0.39,不确定这是否适用于过去的版本.