Say "shuffle sequence" rather than "ladder" in the transpose comments

Comment-only: both headers are byte-identical once comments are stripped,
and clang-format is no worse than HEAD on each.

An earlier pass dropped "ladder" from the commit messages as a coined word
for what is just a sequence of shuffles, but left it in the code comments,
so the two disagreed. All eight occurrences now read "shuffle sequence",
"shuffles", or in the tabulated instruction count for an 8x8 block,
"sequence" -- the (24 shuffles) column keeps its position.

The 512-bit note is the one that changes meaning slightly: "needs vpermi2d
ladders" becomes "needs vpermi2d shuffles", which is what vpermi2d is.

Author: sfc-gh-pgaur

cpp/src/arrow/util/fastlanes/interleaved_pfor.h

@@ -155,12 +155,12 @@ inline size_t InterleavedPforMaxEncodedSize(size_t n) {
 //
 //   for each 8-lane slice lb, for each 8-row block rb:
 //     eight registers <- unpack rows rb..rb+7, lanes lb..lb+7   (8-16 loads)
-//     the unpacklo/unpackhi/permute2x128 ladder                 (24 shuffles)
+//     the unpacklo/unpackhi/permute2x128 sequence               (24 shuffles)
 //     eight 32-byte stores across out[lb..lb+7][rb..rb+7]       (8 stores)
 //
 // Load and store counts per block are then identical to the file-order kernel's
 // (each packed word read once, each output value written once); the only thing
-// FL_ORDER pays over file order is the shuffle ladder. lb is the outer loop on
+// FL_ORDER pays over file order is the shuffles. lb is the outer loop on
 // purpose: a fixed lb writes out[lb * 32, lb * 32 + 256), one contiguous 1 KiB
 // run, whereas rb outer would stride 128 bytes across the whole 4 KiB block.
 // ---------------------------------------------------------------------------
@@ -172,8 +172,8 @@ namespace internal {
 // needs it too, and that header is upstream of this one.
 
 // One 8x8 tile: unpack eight rows' worth of an 8-lane slice, transpose in
-// registers, store across eight output rows. The ladder is the same one
-// Transpose32x32Avx2 uses; only the source of r0..r7 differs.
+// registers, store across eight output rows. The shuffle sequence is the same
+// one Transpose32x32Avx2 uses; only the source of r0..r7 differs.
 template <uint32_t w, bool kHasBias, uint32_t rb>
 ARROW_FORCE_INLINE void FlUnpackTile(const uint32_t* ARROW_RESTRICT packed,
                                      int32_t* ARROW_RESTRICT out, size_t lb,
@@ -255,7 +255,8 @@ namespace internal {
 
 // One 4x4 tile, the NEON counterpart of FlUnpackTile: unpack four rows' worth of
 // a 4-lane slice, transpose in registers, store across four output rows. The
-// ladder is the one Transpose32x32Neon uses; only the source of r0..r3 differs.
+// shuffle sequence is the one Transpose32x32Neon uses; only the source of
+// r0..r3 differs.
 // Four-wide rather than eight-wide because that is the register width, which
 // costs four times as many tiles per block but the same number of loads and
 // stores -- a 16-byte store of four output values either way.

cpp/src/arrow/util/fastlanes/transposed_delta.h

@@ -445,13 +445,13 @@ inline void Transpose32x32Neon(const uint32_t* ARROW_RESTRICT grid,
 
 #ifdef ARROW_TRANSPOSED_DELTA_AVX2
 // Sixteen 8x8 transposes, each done entirely in registers: eight 32-byte loads
-// down a column of the grid, an unpack ladder, eight 32-byte stores across a row
+// down a column of the grid, a shuffle sequence, eight 32-byte stores across a row
 // of the output. A permutation is the one thing in this file the autovectorizer
 // cannot do -- it is not a lane-wise operation, and GCC lowers the scalar
 // version below to 1024 four-byte loads at a 128-byte stride plus 1024 scalar
 // stores. This issues 128 loads and 128 stores instead, so the block costs
 // shuffle throughput rather than memory-op throughput. 256-bit and not 512-bit
-// on purpose: a 16x16 register block needs vpermi2d ladders to cross the extra
+// on purpose: a 16x16 register block needs vpermi2d shuffles to cross the extra
 // lane boundary, and on this microarchitecture 512-bit buys nothing for the
 // unpack either.
 inline void Transpose32x32Avx2(const uint32_t* ARROW_RESTRICT grid,
@@ -570,7 +570,7 @@ inline void PrefixSumAndTransposeNeon(const uint32_t* ARROW_RESTRICT grid,
 // The loop nest is the transpose's, with the blocking order swapped: lane block
 // outer, row block inner, so one accumulator register carries eight lanes'
 // running sums down all 32 rows and never spills. Each 8x8 register block is
-// eight loads, eight adds along the chain, the same unpack ladder
+// eight loads, eight adds along the chain, the same shuffle sequence
 // Transpose32x32Avx2 uses, and eight 32-byte stores across a row of the output.
 // The adds are the only addition to the transpose's instruction stream, and they
 // sit on the load-to-shuffle path rather than after it.
@@ -658,7 +658,7 @@ inline void PrefixSumAndTransposeAvx2(const uint32_t* ARROW_RESTRICT grid,
 // of from memory, so each packed word is read once and each output value written
 // once, and the block never exists. Nothing else changes -- the accumulator
 // still carries eight lanes' running sums down all 32 rows in one register, and
-// the ladder is still the one Transpose32x32Avx2 uses.
+// the shuffle sequence is still the one Transpose32x32Avx2 uses.
 //
 // kHasBias is true here rather than folded into the accumulator: the wire format
 // stores min-subtracted deltas, so every one of the 32 values in a lane's chain