vectorization

Guides authoring and reviewing SIMD and hardware-intrinsics code in dotnet/runtime.

18.2k|5.6k|Updated Sep 24, 2019
One-click install
npx skills add https://github.com/dotnet/runtime --skill vectorization
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: vectorization
Source: https://github.com/dotnet/runtime/tree/main/.github/skills/vectorization
Command: npx skills add https://github.com/dotnet/runtime --skill vectorization

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Writing or reviewing vectorized .NET code is error-prone: remainder handling, unsigned offset underflow, GC holes from stray references, and untested fallback paths cause subtle bugs. This Skill distills the dotnet/runtime vectorization guidelines into concrete authoring, testing, and review checklists.

Core Features & Use Cases

  • Authoring checklist: Structure code from Vector128<T> down to scalar fallbacks, use span-based loads/stores, handle empty buffers via MemoryMarshal.GetReference, and guard against nuint underflow.
  • Testing checklist: Cover Vector256/Vector128/scalar paths, toggle acceleration with DOTNET_EnableAVX2=0 and DOTNET_EnableHWIntrinsic=0, and use BoundedMemory to catch out-of-bounds reads.
  • Review checklist: Verify correctness against the scalar contract, remainder handling, memory safety, cross-platform consistency, and benchmark-backed performance claims.
  • Use Case: When vectorizing a scalar search algorithm with Vector128<byte>, apply the checklist to overlap the final vector for the remainder, guard with IsHardwareAccelerated, and validate with BoundedMemory tests under each DOTNET_Enable* setting.

Quick Start

Ask the AI to review or write a vectorized implementation of your algorithm using Vector128<T> with proper remainder handling and hardware-acceleration fallbacks.

Frequently Asked Questions about vectorization

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I vectorize a scalar algorithm in .NET?

Start with Vector128<T>, the widest API accelerated on the broadest hardware, and structure code from that width down to a scalar fallback. Guard each path with IsHardwareAccelerated and Vector128<T>.IsSupported, then handle the remainder by reprocessing the last full vector.

How do I handle the remainder in a vectorized loop?

Reprocess the last full vector's worth of elements, overlapping what the loop already did. For idempotent operations like searches, fold the overlap in directly; for non-idempotent operations like sums, mask the overlap to the identity with ConditionalSelect.

Should I use Vector128, Vector256, or platform intrinsics in .NET?

Prefer the cross-platform Vector128/Vector256 APIs, which lower to optimal instructions per target. Drop to System.Runtime.Intrinsics.X86/Arm/Wasm only when a specific instruction measurably beats the portable form, guarded by the class's IsSupported check.

How do I test SIMD code paths without AVX2 hardware?

Run the test suite with DOTNET_EnableAVX2=0 to disable Vector256 paths and DOTNET_EnableHWIntrinsic=0 to force the software fallback. Use BoundedMemory.Allocate<T> to place a no-access page after buffers so out-of-bounds reads fault instead of silently succeeding.

Why does my vectorized code read out of bounds or corrupt memory?

Common causes are nuint underflow when subtracting the vector count from a short buffer length, and transient references pointing outside their buffer during backwards iteration, which creates GC holes. Always check buffer length before offset arithmetic and never let a ref stray outside its buffer.

When should I not hand-write SIMD code in .NET?

Avoid hand-rolling when higher-level APIs already vectorize the operation, such as Span<T> and string methods, TensorPrimitives, or LINQ operators like Sum, Max, Min, and Average. Also skip vectorization without benchmark evidence that it pays off, since small buffers can be slower.