图片推理mnn耗时是pytorch的两倍多近似3倍。

[jtyan123]

图片推理mnn耗时是pytorch的两倍多近似3倍。

[jxt1234]

1. ios 用 opencl 推理无效。应该是回退到了 CPU 单线程，检查一下是否 pytorch 是用的多线程。opencl 建议换成 metal 或 CPU
2. 第一次推理时包括 resize 过程，可能会做权重重排、autotuning 等耗时工作，从第二次推理开始计时，或者创建 module 时，设置 config.shapeMutable = false

[jtyan123]

图片的resize是在预处理阶段用opencv resize的。mnn也会默认在resize一次吗。config.shapeMutable = false这行代码已添加。连着调用两次mdule->onForward(inputs);方法打印时间感觉没有太多改善。为什么呢？。MNN第一次推断耗时: 1.92365 seconds。MNN第二次推断耗时: 1.91053 seconds

[jtyan123]

pytorch也没有用多线程。在手机上跑的。也是cpu推断的。

[jxt1234]

你现在的测试代码是什么？是否用多线程要看下 cpu 占用率

[jxt1234]

另外你运行的 ios 设备是什么？ mnn 是怎么编译的，最好用 release 的 framework

[jtyan123]

是我的问题。我直接下载的release2.8.1。跑的demo。默认mnn库是debug模式。我改成release就比pytorch快很多了。

[jtyan123]

新的模型mnn推断耗时比pytorch推断耗时长。pytorch耗时:1.65418 seconds.mnn耗时:1.7395 seconds.为什么呢？代码如下：

std::vector<MNN::Express::VARP> _mnnInputs;
    _mnnInputs.emplace_back(mnnOutput0[2]);
    _mnnInputs.emplace_back(mnn0);
    _mnnInputs.emplace_back(mnnOutput1[2]);
    _mnnInputs.emplace_back(mnn1);
    
    
    MNN::ScheduleConfig sConfig;
    sConfig.type = MNN_FORWARD_CPU;
    std::shared_ptr<MNN::Express::Executor::RuntimeManager> rtmgr(MNN::Express::Executor::RuntimeManager::createRuntimeManager(sConfig), MNN::Express::Executor::RuntimeManager::destroy);
    rtmgr->setCache(".cachefile");
    
    MNN::Express::Module::Config mdconfig; // default module config
    mdconfig.shapeMutable = false;
    std::unique_ptr<MNN::Express::Module> mnnGlueMdule(MNN::Express::Module::load({ "desc0", "kpts0", "desc1", "kpts1"}, {"matches0", "mscores0"}, model_file.c_str(), nullptr, &mdconfig));
    auto begin = std::chrono::high_resolution_clock::now();
    auto mnnGlueOutputs  = mnnGlueMdule->onForward(_mnnInputs);
    std::chrono::duration<double> end = std::chrono::high_resolution_clock::now() - begin;
    // 打印耗时（以秒为单位）
    std::cout << "MNN匹配推断耗时: " << end.count() << " seconds" << std::endl;

[jxt1234]

新的模型重新提 issue 。这个看上去10%差距像是波动原因。多跑几遍再看性能