AdamNiederer / AdamNiederer/faster

Faster and std::simd

未关闭
#53 5 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
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

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。