Add FAQs and Common Issues doc page #7547
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/7547
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit e8e0865 with merge base 6c9b9b6 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
|
|
||
| We are actively working to improve the out-of-box behavior, but the above APIs can be used to improve mobile performance as workaround until deeper changes for performant core detection land. | ||
|
|
||
| ### Erroa setting input: 0x10 / Attempted to resize a bounded tensor... |
|
|
||
| ### Duplicate Kernel Registration Abort | ||
|
|
||
| This manifests as a crash call stack including ExecuTorch kernel registration and failing with an `et_pal_abort`. This typically means there are multiple `gen_operators_lib` targets linked into the applications. There must be only one generated lib per target, though each model can have its own `gen_selected_ops/generate_bindings_for_kernels` call. |
There was a problem hiding this comment.
generated lib -> generated operator library
|
|
||
| ### Performance Troubleshooting | ||
|
|
||
| Ensure the model is delegated. If not targeting a specific accelerator, use the XNNPACK delegate for CPU performance. Undelegated operators will typically fall back to the ExecuTorch portable library, which is designed as a platform-independent fallback, and is not optimized for specific hardware. |
There was a problem hiding this comment.
ExecuTorch portable library, which is designed as a platform-independent fallback, and is not optimized for specific hardware.
which is design to serve as a reference implementation/fallback and not intended to be used in a performance sensitive production scenarios.
|
|
||
| Ensure the model is delegated. If not targeting a specific accelerator, use the XNNPACK delegate for CPU performance. Undelegated operators will typically fall back to the ExecuTorch portable library, which is designed as a platform-independent fallback, and is not optimized for specific hardware. | ||
|
|
||
| Additionally, thread counts are a common source of performance issues. While we are working to improve the default behavior, ExecuTorch will currently use as many threads as there are cores. On some heterogenous mobile SOCs, this can be slow. Consider setting the thread count to cores / 2, or just set to 4. This will lead to a speedup (or maintain parity) on almost all mobile devices. |
There was a problem hiding this comment.
This will lead to a speedup (or maintain parity) on almost all mobile devices.
This might lead to a speedup?
Because if it always will, why this is not a default?
There was a problem hiding this comment.
Also I would probably add a reference to a function other document that explain how CPU parallelism can be configured
There was a problem hiding this comment.
There is no way to this in OSS at the moment except for the unsafe API
Summary
Add "FAQs and Common Issues" page to the ExecuTorch docs. This summarizes common issues that we've seen when users adopt ExecuTorch.
I've tentatively put this under the Getting Started section, as that seems like the most reasonable place to put it, but I'm open to suggestions.
Test plan
New doc page preview: https://docs-preview.pytorch.org/pytorch/executorch/7547/getting-started-faqs.html