CLI for measuring execute_cuda encoding perf

[a10y]

Overview of changes

ergonomics/API focused changes

• Introduced a new LaunchStrategy on the execution context. This by default will launch kernels and not track any timing information, but it is pluggable. For example in benchmarks we replace this with a TimedLaunchedStrategy which executes the kernels in blocking mode and logs their execution time.
• Centralized the entrypoint for launching all kernels. They are now forced to be dispatched off of the execution context using the ctx.launch_kernel() method, which accepts a closure that is used to populate kernel arguments

A lot of test and benchmark code needed to be updated to use the new launch methods.

Fused FOR + BP

This has been shelved for a FLUP since this was too big

* I've updated the BP kernel generator to generate bp as FFOR, i.e. fused bitpacking with FOR. In practice, this is just adding a const T reference param. By default the execution for BitPackedArray passes zero, but there is a specialization in the ForArray execution tree where if it detects one of its descendants is BP, it fuses itself with the bit unpacking

GPU tracing tool

There's a new binary in vortex-test-e2e-cuda-scan which takes as input a Vortex file.

It will recompress the file using only GPU-supported encodings, scan it back, and collect timings for how long each column scan took. The results are printed as either pretty text, or as JSON to stdout, which can be piped into duckdb or similar for analysis

Example usage:

FLAT_LAYOUT_INLINE_ARRAY_NODE=true RUST_LOG=vortex_cuda=trace,info cargo run --release --bin vortex-test-e2e-cuda-scan -- ./vortex-bench/data/tpch/1.0/vortex-file-compressed/lineitem_0.vortex

[a10y]

see here: instead of replicating the full launch setup in benchmark code, we can just stub in a launcher that collects timing information across runs

[a10y]

this is where LaunchStrategy is defined and impled

[0ax1]

Couple of questions.

[0ax1]

Why did we change this? This should never fail I think, as the send can only error if the channel does not have sufficient capacity which should never be the case.

[a10y]

I was getting panics during testing bc the last receiver had been dropped. I forgot which operation this was for but making this not panic fixed it

[a10y]

https://docs.rs/kanal/latest/kanal/enum.SendError.html

[codspeed-hq]

Merging this PR will degrade performance by 45.76%

❌ 16 regressed benchmarks
✅ 1041 untouched benchmarks
⏩ 1346 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	bench_dict_mask[(0.01, 0.9)]	1.2 ms	2.2 ms	-44.22%
❌	Simulation	bench_dict_mask[(0.01, 0.01)]	1.2 ms	1.7 ms	-29.6%
❌	Simulation	bench_dict_mask[(0.01, 0.1)]	1.2 ms	1.8 ms	-31.49%
❌	Simulation	bench_dict_mask[(0.01, 0.5)]	1.2 ms	2 ms	-38.64%
❌	Simulation	bench_dict_mask[(0.1, 0.01)]	1.2 ms	1.7 ms	-29.73%
❌	Simulation	bench_dict_mask[(0.1, 0.5)]	1.2 ms	2 ms	-38.65%
❌	Simulation	bench_dict_mask[(0.5, 0.9)]	1.2 ms	2.2 ms	-44.21%
❌	Simulation	bench_dict_mask[(0.1, 0.9)]	1.2 ms	2.2 ms	-44.13%
❌	Simulation	bench_dict_mask[(0.9, 0.01)]	1.2 ms	1.7 ms	-29.57%
❌	Simulation	bench_dict_mask[(0.5, 0.01)]	1.2 ms	1.7 ms	-29.67%
❌	Simulation	bench_dict_mask[(0.1, 0.1)]	1.2 ms	1.8 ms	-31.55%
❌	Simulation	bench_dict_mask[(0.9, 0.1)]	1.2 ms	1.8 ms	-31.48%
❌	Simulation	bench_dict_mask[(0.5, 0.5)]	1.2 ms	2 ms	-38.63%
❌	Simulation	bench_dict_mask[(0.5, 0.1)]	1.2 ms	1.8 ms	-31.51%
❌	Simulation	bench_dict_mask[(0.9, 0.9)]	1.3 ms	2.3 ms	-45.76%
❌	Simulation	bench_dict_mask[(0.9, 0.5)]	1.2 ms	2.1 ms	-41.79%

---

_{Comparing aduffy/gpu-scan-measure (3884af8) with develop (1585f08)}

Footnotes

1. 1346 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩