AdamNiederer / AdamNiederer/faster
Faster and std::simd
- 主要语言
- Rust
- 星标
- 1.6k
- 派生
- 52
- PR 合并指标
- 30 天内没有已合并 PR
描述
Opening another ticket since this is a separate discussion from #47 and might be more controversial:
The more I look into the upcoming `std::simd`, the more I wonder if `faster` should not become a thinner "SIMD-friendly iteration" library that neatly plugs into `std::simd` and is really good at handling variable slices, zipping, ... instead of providing a blanket implementation over `std::arch`.
Right now it seems that many common intrinsics and operations faster provides on packed types are or might be implemented in `std::simd` (compare [coresimd/ppsv](https://github.com/rust-lang-nursery/stdsimd/tree/master/coresimd/ppsv)).
At the same time, for things that won't be in `std::simd` (and will be more platform specific), faster will have a hard time providing a consistent performance story anyway.
By that reasoning I see a certain appeal primarily focusing on a more consistent cross-platform experience with a much lighter code base (e.g., imagine faster without `arch/` and `intrin/` and using mostly `std::simd` instead of `vektor`).
Faster could also integrate `std::arch` specific functions and types, but rather as extensions and helpers (e.g., for striding) for special use cases, instead of using them as internal fundamentals.
贡献指南
这个仓库没有索引到贡献指南
调研方向
Start by reading the related discussion in #47 and comparing the arch/, intrin/, and vektor areas named here with the stdsimd coresimd/ppsv reference. Done means reaching an agreed architecture and implementation scope for std::simd integration; this issue does not name a specific test or entry point to run.
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- rust
- 领域
- performance
- Issue 类型
- 重构
- 难度
- 5/5
- 预计耗时
- 一周以上
- 活跃度
- 停滞
- 描述清晰度
- 需要澄清
- 新手友好度
- 25/100