[wasm] Managed Wide-Vector (256, 512) SIMD Fallbacks are Very Expensive in Size
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- csharp, wasm
- 领域
- compilers, performance
调研方向
Start by examining the Wasm fallback for Vector512.FusedMultiplyAdd<float> and compare its generated code size with the x64 example described in the issue. The issue names no files or tests, so first trace the fallback and its nested vector operations in the runtime codebase. Done means identifying and addressing one of the listed causes of oversized Wasm output, with code size and performance checked.
由索引模型根据 Issue 内容生成。
描述
This is a broader issue that came up while investigating Wasm size outliers in System.Private.CoreLib as compared to x64 R2R codegen. Nearly all the statistical size outliers were in vector fallback code. For example, the fallback code for Vector512.FusedMultiplyAdd<float> is massive on Wasm; it's around 1.8 KB in size, as compared to only 47 bytes on x64. The comparison isn't fair necessarily because x64 has vector intrinsics that Wasm simply does not have, but this example exposes several things we might want to look into:
- We don't seem to decompose larger vector widths into
v128locals; i.e., accessing elements of a Vector512 struct will end up as many separate loads and stores ofv128. This could be complicated to improve but it is definitely a factor in the large code size and likely has significant negative perf impacts as well. - We null check addresses for loads of individual vector elements in stack allocated vectors which should be in bounds for the current stack frame;
- We aggressively inline nested managed fallbacks which leads to a very large code size expansion. In this example we have the inline tree of
Vector512.FusedMultiplyAdd -> 2*Vector256.FusedMultiplyAdd -> 2*Vector128.FusedMultiplyAdd -> 2*Vector64.FusedMultiplyAdd -> 2*Vector64.GetElementUnsafe
- 主要语言
- C#
- 星标
- 18.4k
- 派生
- 5.8k
- 平均合并
- 2 天 15 小时
- 30 天内合并 PR
- 596
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
dotnet/runtime 的其他 Issue
-
area-Extensions-FileSystem untriaged
难度 2/5 1-3 小时 新手友好度 78/100
dotnet/runtime#136989 · 1 条评论 ·
维护者通常 1 天内回复
-
area-Extensions-Configuration bug source-generator untriaged
难度 2/5 1-3 小时 新手友好度 78/100
dotnet/runtime#136972 · 1 条评论 ·
维护者通常 1 天内回复
-
[wasi] .NET 10: WasmEnableSIMD with AOT fails because WasiApp.targets has -msimd128 commented out未关闭area-Build-mono untriaged
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
area-System.ComponentModel untriaged
难度 2/5 1-3 小时 新手友好度 65/100
dotnet/runtime#136608 · 2 条评论 ·
维护者通常 1 天内回复
-
MemoryMappedFile (Windows): failed MEM_COMMIT is ignored, accessor over reserved memory crashes the process可能已有人在做 @RutulPatel8 于 4 天前认领。 未关闭area-System.IO bug untriaged
难度 2/5 1-3 小时 新手友好度 78/100
dotnet/runtime#136599 · 1 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 80/100
Unity-Technologies/unity-agent-plugin#118 ·
维护者通常 1 天内回复
-
The Recommended preset turns on Import Uno DSP, which only works with the Material theme可能已有人在做 @agneszitte 今天认领。 未关闭
难度 1/5 1 小时以内 新手友好度 92/100
unoplatform/uno.templates#2388 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 77/100
eyalgolan/statecraft-israel#2732 ·
维护者通常 1 天内回复
-
要トリアージ
难度 2/5 1-3 小时 新手友好度 64/100
维护者通常 1 天内回复
-
kind/chore status/draft
难度 2/5 1-3 小时 新手友好度 65/100
Altinn/altinn-events#1158 ·
维护者通常 1 天内回复