faq.md 2.8 KB
Newer Older
L
Liangliang He 已提交
1
Frequently asked questions
L
Liangliang He 已提交
2 3
==========================

L
Liangliang He 已提交
4 5
Does the tensor data consume extra memory when compiled into C++ code?
----------------------------------------------------------------------
L
Liangliang He 已提交
6 7 8
When compiled into C++ code, the tensor data will be mmaped by the system
loader. For the CPU runtime, the tensor data are used without memory copy.
For the GPU and DSP runtime, the tensor data are used once during model
L
Liangliang He 已提交
9
initialization. The operating system is free to swap the pages out, however,
L
Liangliang He 已提交
10
it still consumes virtual memory addresses. So generally speaking, it takes
L
Liangliang He 已提交
11
no extra physical memory. If you are short of virtual memory space (this
L
Liangliang He 已提交
12 13 14
should be very rare), you can use the option to load the tensor data from
data file (can be manually unmapped after initialization) instead of compiled
code.
L
Liangliang He 已提交
15

L
Liangliang He 已提交
16 17 18
Why is the generated static library file size so huge?
-------------------------------------------------------
The static library is simply an archive of a set of object files which are
L
Liangliang He 已提交
19
intermediate and contain many extra information, please check whether the
L
Liangliang He 已提交
20 21 22 23 24 25
final binary file size is as expected.

Why is the generated binary file (including shared library) size so huge?
-------------------------------------------------------------------------
When compiling the model into C++ code, the final binary may contains extra
debug symbols, they usually takes a lot of space. Try to strip the shared
L
Liangliang He 已提交
26 27 28 29 30
library or binary and make sure you are following best practices to reduce
the size of an ELF binary, including disabling C++ exception, disabling RTTI,
avoiding C++ iostream, hidden internal functions etc.
In most cases, the expected overhead should be less than
{model weights size in float32}/2 + 3MB.
L
Liangliang He 已提交
31 32 33 34 35 36 37 38 39

OpenCL allocator failed with CL_OUT_OF_RESOURCES
------------------------------------------------
OpenCL runtime usually requires continuous virtual memory for its image buffer,
the error will occur when the OpenCL driver can't find the continuous space
due to high memory usage or fragmentation. Several solutions can be tried:

* Change the model by reducing its memory usage
* Split the Op with the biggest single memory buffer
L
Liangliang He 已提交
40
* Change from armeabi-v7a to arm64-v8a to expand the virtual address space
L
Liangliang He 已提交
41 42
* Reduce the memory consumption of other modules of the same process

L
Liangliang He 已提交
43
Why is the performance worse than the official result for the same model?
L
Liangliang He 已提交
44 45 46 47
-------------------------------------------------------------------------
The power options may not set properly, see `mace/public/mace_runtime.h` for
details.

L
Liangliang He 已提交
48
Why is the UI getting poor responsiveness when running model with GPU runtime?
L
Liangliang He 已提交
49 50 51 52
------------------------------------------------------------------------------
Try to set `limit_opencl_kernel_time` to `1`. If still not resolved, try to
modify the source code to use even smaller time intervals or changed to CPU
or DSP runtime.