# Hello, SIMD!

###### tags: `Portable SIMD`

A space to sketch out definitions of things relevant to portable SIMD and come up with a consistent story to communicate.

## References

- [General Notes][jubilee-notes]
- Arm: [Arm Neon], [Neon Programmer's Guide], [SVE vs SVE2]
- [Intel Intrinsics Guide]

[jubilee-notes]: https://hackmd.io/-LaVJuO2SuS53uGX-D76tA
[SVE vs SVE2]: https://developer.arm.com/tools-and-software/server-and-hpc/compile/arm-instruction-emulator/resources/tutorials/sve/sve-vs-sve2/single-page
[Arm Neon]: https://developer.arm.com/architectures/instruction-sets/simd-isas/neon
[Neon Programmer's Guide]: https://static.docs.arm.com/den0018/a/DEN0018A_neon_programmers_guide_en.pdf?_ga=2.112843328.535197283.1547875098-60705264.1529324001
[Intel Intrinsics Guide]: https://software.intel.com/sites/landingpage/IntrinsicsGuide/

## General Thoughts

### SIMD nomenclature
We want standardized names for things as we expose these capabilities to Rustaceans. The current bias in the SIMD universe is to talking about and thinking about things in terms of SSE2 and AVX, ignoring different approaches like Neon, AltiVec, RISCV-V, etc., but there's also GPU / shader and tensor math terminology as well. Using these in a conscious and consistent manner will help.

### Target Support
SIMD ISAs are built on an architecture level but their usage is also about the OS and ABI support: on embedded this is slightly more abstract of a concern, but ultimately if there's no support throughout the target then there's no support for SIMD. Thus, a SIMD ISA is always enabled on a full-target-triple level. This is counterintuitive if you hear people talk mostly about the ISAs.

### FP Math (Speed) Matters

Many SIMD applications use floats. Floats are complicated.

## Open Questions
1. When do we throw code at rustc nightly?
2. stance towards vector length agnostic APIs per https://github.com/rust-lang/stdsimd/issues/22
3. list of non-goals per https://github.com/rust-lang/stdsimd/issues/22