Consider further speeding up division by `const`-generic specialization.
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ái cấu trúc
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- rust
- Lĩnh vực
- performance
Hướng nghiên cứu
Bắt đầu từ phần triển khai phép chia độ chính xác tùy ý ieee::sig::div và kiểm tra xem benchmark "from decimal" hiện có có bao phủ các trường hợp liên quan hay không. Thêm các benchmark trước khi thay đổi phần triển khai, sau đó đánh giá các specialization const-generic cho những số chia được sử dụng phổ biến. Hoàn tất khi hành vi của phép chia được giữ nguyên và các benchmark cho thấy tốc độ được cải thiện đáng kể.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The main implementation of the ieee::sig::div "arbitrary-precision division" function could be made into a separate function with a const SPECIALIZE_FOR_KNOWN_DIVISOR: u128 const-generic parameter, which it would use as such:
// The parameter being `0` is like `None` - could use `Option<NonZeroU128>` in the future.
if SPECIALIZE_FOR_KNOWN_DIVISOR != 0 {
assert_eq!(divisor[0], SPECIALIZE_FOR_KNOWN_DIVISOR);
assert!(is_all_zeros(&divisor[1..]));
}
(Hopefully this is enough for the rest of the body to be specialized by LLVM, but it can be further forced if necessary)
Then ieee::sig::div would become a "dispatch" fn, which invokes N+1 different instantiations of the const-generic implementation, for N "commonly used divisors" (10 comes to mind, tho there may be a whole sequence of powers of 5 for the conversion from decimal strings IIRC), and one 0 instantiation (which isn't specialized at all), and because the code still does the same division, we're only relying on the optimizer to actually turn the divisions into multiplications.
Whatever we do to the division algorithm, we shouldn't forget to add benchmarks first (unless the "from decimal" benchmark would cover enough interesting cases).
- Ngôn ngữ chính
- Rust
- Star
- 23
- Fork
- 18
- Merge trung bình
- 14 giờ 13 phút
- Pull request đã merge (30 ngày)
- 2
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của rust-lang/rustc_apfloat
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
rust-lang/rustc_apfloat#44 · 3 bình luận ·
-
Overflow flag when result is larget finite valueCó thể đã có người làm @Garfield1002 đã nhận 47 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
rust-lang/rustc_apfloat#36 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 45/100
rust-lang/rustc_apfloat#20 ·
-
Support squareRootĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
rust-lang/rustc_apfloat#14 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 45/100
rust-lang/rustc_apfloat#10 · 7 bình luận ·
Tất cả issue của rust-lang/rustc_apfloat
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
521xueweihan/HelloGitHub#4023 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
nautechsystems/nautilus_trader#5365 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
IntersectMBO/developer-experience#347 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
registrystack/registry-stack#2168 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug crate: 3d help wanted triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
kornia/kornia-rs#1203 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày