Vectorization POC

[frankmcsherry]

This is a POC written largely by Claude for vectorization of MirScalarExpression, using standard array language / columnar idioms. The expressions are still interpreted, but act on batches of 1024 elements. It does quite a lot of printing as it does the work, and this should all be tidied up, but sharing for discussion.

Here is a summary from Claude of the work, and the next steps:

⏺ Vectorized Batch Evaluation: Summary                                                            
                                                                                                  
  What changed                                                                                    
                                                            
  Vectorized arithmetic fast path — Replaced the previous function-pointer-based checked_add      
  per-element evaluation with true SIMD-friendly loops:                                           
  - Arithmetic uses wrapping_add/wrapping_sub via .iter().zip().map().collect(), which allows LLVM
   to auto-vectorize (confirmed: ~167-208ns for 1024 i64 adds, near the NEON theoretical minimum  
  of ~128ns).
  - Overflow detection uses a two-phase approach: a branchless OR-reduction (fold with |) to
  detect if any overflow occurred, followed by index collection only in the rare case that one
  did. This dropped overflow checking from ~670ns to ~250ns.
  - Multiplication retains checked_mul per-element since there's no cheap bit trick for multiply
  overflow.
  - Result containers are constructed in bulk (vec![discriminant; len] + (0..len).collect() for
  offsets) rather than pushing ColumnDatum variants one at a time.

  Eliminated redundant column copies:
  - evaluate_batch previously copied all input columns element-by-element into an owned
  Vec<DatumColumn> before evaluation. Now it borrows input columns directly.
  - VectorScalarExpr::eval for CallBinary detects when sub-expressions are Column references and
  passes the existing columns through without copying.
  - rows_to_columns now accepts an iterator of &Row instead of requiring a collected Vec<Row>,
  avoiding a clone of every input row.

  Observed performance (1024-element batches, release build, Apple Silicon)

  ┌───────────────────────────┬────────┬──────────────────────────────────────────────────┐
  │           Phase           │  Time  │                      Notes                       │
  ├───────────────────────────┼────────┼──────────────────────────────────────────────────┤
  │ Arithmetic (wrapping add) │ ~200ns │ SIMD-vectorized, near theoretical limit          │
  ├───────────────────────────┼────────┼──────────────────────────────────────────────────┤
  │ Overflow detection        │ ~250ns │ Branchless OR-reduction                          │
  ├───────────────────────────┼────────┼──────────────────────────────────────────────────┤
  │ Container construction    │ ~200ns │ variant + offset arrays                          │
  ├───────────────────────────┼────────┼──────────────────────────────────────────────────┤
  │ Compute total             │ ~0.7us │                                                  │
  ├───────────────────────────┼────────┼──────────────────────────────────────────────────┤
  │ Row packing (col→row)     │ ~10us  │ Per-element index_as_datum + packer.push         │
  ├───────────────────────────┼────────┼──────────────────────────────────────────────────┤
  │ Transpose (row→col)       │ ~58us  │ Per-element row.unpack() + datum_to_column_datum │
  ├───────────────────────────┼────────┼──────────────────────────────────────────────────┤
  │ End-to-end per batch      │ ~77us  │ Dominated by format conversion                   │
  └───────────────────────────┴────────┴──────────────────────────────────────────────────┘

  Next steps

  - columnar crate changes: The columnar container currently requires variant (discriminant) and
  offset arrays even for homogeneous columns. Adding Variants::Uniform(discriminant, len) and
  Offsets::Identity(len) representations would make constructing a homogeneous column from a typed
   Vec<T> O(1) with zero auxiliary allocations, eliminating the ~200ns container overhead.
  - Keep data columnar across operators: The transpose (58us) and row-packing (10us) costs are
  ~99% of the per-batch time. The architectural fix is to keep data in columnar form through
  multiple operators (maps, filters, joins) and only convert back to rows at emission boundaries.
  - Vectorized float operations: Float addition currently falls back to per-element scalar
  evaluation (~67us vs ~19us for integers). Adding vectorized float paths would bring parity.
  - Remove diagnostic timing: The tracing::info! calls with nanosecond breakdowns (arith_ns,
  overflow_ns, container_ns) were added for development and should be removed or gated behind a
  feature flag before merging.

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

[antiguru]

I think this checks out! We should aim at having two different MFP implementations, and a runtime dispatch between them so we only have to pay the price of specializing the MFP once. Then there's a bunch of code that we could integrate into the sqlfunc macro, but no need to block on this.