[wasm] Managed Wide-Vector (256, 512) SIMD Fallbacks are Very Expensive in Size

Đang mở
  • Có gì không ổn?
#136,741 4 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, wasm
Lĩnh vực
compilers, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

arch-wasm area-CodeGen-coreclr tenet-performance

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 v128 locals; i.e., accessing elements of a Vector512 struct will end up as many separate loads and stores of v128. 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
Ngôn ngữ chính
C#
Star
18.4k
Fork
5.8k
Merge trung bình
2 ngày 15 giờ
Pull request đã merge (30 ngày)
596

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/runtime

Tất cả issue của dotnet/runtime

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.