Fixed-width SIMD: v128 values and the operations on them. Read this before you add a vector instruction, or when you want to know what one costs.

Why a 16-byte binary

A v128 is a 16-byte binary. The alternative was a 128-bit integer, and the choice was measured rather than assumed. Per operation, 200,000 iterations, minimum of five runs:

Bit syntax truncates each field to its declared width, so lane wrapping is free where the integer form needs an explicit mask per lane, and a binary is built in one allocation where a shift-and-or chain allocates an intermediate bignum per lane. The integer form wins only on v128.and, and only by 12%.

Why lanes are matched, not iterated

Every lane operation matches all its lanes in one pattern. The obvious binary_to_list, lists:zip, comprehension route costs 182 ns for i8x16.add against 14.6 ns; a binary comprehension with a zip generator is worse still at 253 ns.

Writing all 240 operations out at full width would be some thousands of lines, so the lane split is done once per shape in zip16/3 and friends and the operations are ordinary funs. That costs 1.4x to 1.8x against inlining (i8x16.add 30.3 ns rather than 17.2 ns) and is still six times better than iterating. Specialising a hot shape later is a local change.

Floats

Float lanes are not matched with :32/float. Erlang cannot represent NaN or Infinity as a float, and those bit patterns do not match a float field at all, so a lane holding a NaN would fail to match rather than compare unequal. Lanes are extracted as integer bit patterns and converted through wasm_num, giving the same hybrid representation the scalar instructions use, and so the same NaN propagation and quieting rules for free.