[GitHub] [tvm] petersalas commented on pull request #8995: [Autoscheduler] Reduce task weight coercion overhead

[GitBox <gi...@apache.org>]

petersalas commented on pull request #8995:
URL: https://github.com/apache/tvm/pull/8995#issuecomment-918441903


   @junrushao1994 the (hidden) place this ends up getting hit is this function:
   
   ```python
   self.objective_func = lambda costs: sum(c * w for c, w in zip(costs, task_weights))
   ```
   
   because `extract_tasks` was returning `IntImm` for task weights (rather than `int`) every multiplication went down a numpy reflection path with a stack like:
   
   ```
   > _dl_addr (/lib/x86_64-linux-gnu/libc-2.27.so:0)
   > backtrace_symbols (/lib/x86_64-linux-gnu/libc-2.27.so:0)
   > dmlc::StackTrace[abi:cxx11] (/usr/hulk/3rdparty/tvm/build/libtvm.so:0)
   > tvm::runtime::Backtrace[abi:cxx11] (/usr/hulk/3rdparty/tvm/build/libtvm.so:0)
   > tvm::runtime::detail::LogFatal::Entry::Finalize (/usr/hulk/3rdparty/tvm/build/libtvm.so:0)
   > tvm::ReflectionVTable::GetAttr (/usr/hulk/3rdparty/tvm/build/libtvm.so:0)
   > tvm::NodeGetAttr (/usr/hulk/3rdparty/tvm/build/libtvm.so:0)
   > std::_Function_handler<void (tvm::runtime::TVMArgs, tvm::runtime::TVMRetValue*), void (*)(tvm::runtime::TVMArgs, tvm::runtime::TVMRetValue*)>::_M_invoke (/usr/hulk/3rdparty/tvm/build/libtvm.so:0)
   > TVMFuncCall (/usr/hulk/3rdparty/tvm/build/libtvm.so:0)
   > ffi_call_unix64 (/usr/lib/x86_64-linux-gnu/libffi.so.6.0.4:0)
   > ffi_call (/usr/lib/x86_64-linux-gnu/libffi.so.6.0.4:0)
   > _ctypes_callproc (/usr/lib/python3.7/lib-dynload/_ctypes.cpython-37m-x86_64-linux-gnu.so:0)
   > 0x7ffb404bf9e3 (/usr/lib/python3.7/lib-dynload/_ctypes.cpython-37m-x86_64-linux-gnu.so:0)
   > __call__ (/usr/tvm/python/tvm/_ffi/_ctypes/packed_func.py:233)
   > __getattr__ (/usr/tvm/python/tvm/runtime/object.py:65)
   > PyArray_FromArrayAttr (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > _array_from_array_like (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > PyArray_DiscoverDTypeAndShape_Recursive (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > PyArray_DiscoverDTypeAndShape (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > PyArray_FromAny (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > get_ufunc_arguments (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > PyUFunc_GenericFunction_int (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > ufunc_generic_call (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > array_multiply (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > double_multiply (/usr/local/lib/python3.7/dist-packages/numpy/core/_multiarray_umath.cpython-37m-x86_64-linux-gnu.so:0)
   > <genexpr> (/usr/tvm/python/tvm/auto_scheduler/task_scheduler.py:226)
   > <lambda> (/usr/tvm/python/tvm/auto_scheduler/task_scheduler.py:226)
   > _compute_score (/usr/tvm/python/tvm/auto_scheduler/task_scheduler.py:483)
   ```
   
   Note that either part of this change is sufficient to make the cost negligible. The open question is whether there may be other scenarios where the `LOG(FATAL)` could cause the same issue elsewhere. I don't have a lot of context with which to evaluate that perf/debuggability tradeoff so I'll defer to reviewers on that.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org