explain SIMD terminology and commonly-confused terms#535
Closed
enthropy7 wants to merge 1 commit into
Closed
Conversation
|
|
||
| **Lane vs. field vs. element.** A *lane* is a position in the vector, numbered `0` to `N-1`, like an index into an array. An *element* is the value that currently occupies a lane. So "lane 2" is a slot, and "the element in lane 2" is its contents. *Field* is a third word you'll occasionally see — usually in older or vendor-specific writing — for the same idea; it carries no separate meaning here, and this guide sticks to *lane* for the position and *element* for the value. | ||
|
|
||
| **Scalar vs. vector.** A *scalar* is a single value, the ordinary `f32` or `i32` you're already used to. A *vector* is a fixed-size group of those values that the CPU operates on together — an `f32x4` is four `f32` scalars packed into one register. The whole point of SIMD is to replace many scalar operations with one vector operation, so "scalar code" is the non-SIMD baseline you're comparing against. |
Member
There was a problem hiding this comment.
on some architectures and target features (RISC-V V and Arm SVE), vectors are inherently variable-size (with the size determined by the programmer and/or the cpu, depending on the architecture) and portable-simd's fixed-size types are converted by the compiler to variable-size instructions when those are better. portable-simd doesn't yet have variable-size types.
programmerjake
approved these changes
Jun 24, 2026
Member
|
See #534 (comment) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #29. Second PR in the series.
This PR broadens the beginner vocabulary and adds new terms, bringing the guide closer to how the finished documentation should look.
Addresses these checklist items:
New
Termsentries:Element,Splat,Mask,Horizontal, andIntrinsic(covering both vendorcore::archintrinsics and compiler/LLVM intrinsics, so readers can see what intrinsics actually look like). New "Words That Are Easy to Mix Up" section for the four distinctions above.Splat/Mask/Horizontalaren't on the checklist, but they're core beginner-facing vocabulary for this crate (splat appears in the README's hello-world, masks have a whole README section, and horizontal pairs with the existing "vertical" term), so I included them while we're here.