---
# System prepended metadata

title: Portable SIMD 2020-10-05 Meeting
tags: [Minutes, Portable SIMD]

---

# Portable SIMD 2020-10-05 Meeting

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

[Last Week] | [This Week's Chat] | [Next Week]

[Last Week]: https://hackmd.io/kYH3ozJ_Q1yCwIiAHeKRBA?view
[This Week's Chat]: https://rust-lang.zulipchat.com/#narrow/stream/257879-project-portable-simd/topic/2020-10-05.20meeting/near/212343708
[Next Week]: https://hackmd.io/h5Coi4l8RZWS6T1Esw5WKQ?view

- Jubilee
- Lokathor
- Caleb Zulawski
- Oliver
- Thom Chiovoloni

## Sync

Question regarding aarch64's Neon support resolved in https://rust-lang.zulipchat.com/#narrow/stream/242906-t-compiler.2Farm/topic/Is.20aarch64.20lit.20with.20Neon.3F/near/211907057 as "yes for all known aarch64 targets and likely into the future because aarch64 is ARMv8-A and ARMv8-A is Neon-enabled."

exercise caution with simd_extract and simd_insert until this is fixed: https://github.com/rust-lang/rust/issues/77477

## Agenda

1. Testing crates
    - test-case crate allows parameterized tests
    - quickcheck, et alia allow testing with reducers
2. Organizing help (reports of "I want to help but I don't know what I can help with? Who is working on what?")

## Resolutions

1. Don't quickcheck yet (but proptest/hypothesis maybe later?)
    - focus on edge case testing and parameterization
2. We need to lay out a welcome mat for stdsimd as well.
	- a CONTRIBUTING.md
	- links to Zulip, FAQ, etc.
    - Lokathor has volunteered to help chunk issues

## Extra
Discussions of Julia
- well-regarded API but maybe too high level?
- maybe reference their test cases?

## Summary update

https://rust-lang.zulipchat.com/#narrow/stream/257879-project-portable-simd/topic/2020-10-05.20meeting

### Testing

- There are a lot of moving parts in a portable SIMD API we need to test. There's a bit of a state explosion to manage to make sure everything actually does work portably.
- Using property testing and fuzzing is something we'd like to do. `quickcheck` has been used in the past for sanity-checking SIMD code, but wasn't enough on its own.
- With a good set of edge-case inputs we can probably cover a lot of interesting cases without a lot of test infrastructure.

### Contributing docs

- People want to get on board and help out, but it's not totally clear how they can yet. We need some more docs and coordination of work that's up-for-grabs.

### Runtime detection

- This one comes up pretty regularly, and is currently considered out-of-scope for an initial release.
- We don't want to paint ourselves into a corner and not be able to add it, but don't want to commit to it beyond existing `#[target_feature]` support in `core::arch`.
- We need to communicate what is and isn't in-scope better.

### Julia

- Julia's [portable SIMD API](https://github.com/eschnett/SIMD.jl) is considered very good, but quite high-level. They have some interesting test cases we should look at.

### Shuffles

- We don't actually have a concrete design for shuffles yet, besides wanting to use const generics for the indexes. There's a [bug in Miri](https://github.com/rust-lang/rust/issues/77477) where invalid const indexes are UB instead of compile errors.

### Portable nomenclature

- We're feeling the need to come up with consistent and portable terms to discuss SIMD. There's a lot of vendor-specific stuff to try abstract over.