Escolhendo uma largura SIMD

The SIMD width is how many lanes you process per instruction. Picking it well is key to real performance.

Your CPU has vector registers of a fixed size. A good SIMD width matches the lanes that hardware can run at once.

A width of 1 ignores the CPU's vector units entirely. You leave most of the chip's throughput sitting idle.

If a width is larger than the hardware supports, Mojo splits it into smaller chunks. That still works but adds overhead.

Mojo can report the ideal width for a type on this machine through simdwidthof, so you do not have to guess.

Because simdwidthof is known at compile time, you can feed it straight into a SIMD type as its width.

Smaller elements fit more lanes in the same register. So float32 usually gets a bigger native width than float64.

Using simdwidthof means your code adapts to each machine automatically. The same source stays fast and portable.

Data that comes in clean multiples of your width vectorizes neatly, with no leftover lanes to handle as a remainder.

When a count is not a multiple of the width, a few tail elements remain. You finish those with a small scalar step.

A safe default is simdwidthof for your DType. Measure later, but the native width is almost always a strong start.

You want a SIMD width that fits this CPU's float32 lanes without hardcoding a guess. What helps?

Match the SIMD width to the hardware: simdwidthof gives the native lane count per DType, and a scalar tail cleans up leftover elements. 🎯