Avoid decoding long runs in a single thread

[gerashegalov]

Description

Split long runs among threads

Lead Co-authored-by: @abellina
Co-authored-by: @gerashegalov

Benchmarks

Generated files with a single integer column comprised of logically ~1 billion rows valued 1.

• 4 pages. with 250 million rows per page
• 32 pages, with 33 million rows per page
• 1024 pages, 1 million row per page
• 4475 pages, 240 thousand rows

The benchmark Spark app iterates these files and executes

spark.read.parquet(path).selectExpr("SUM(ones)") 

gpuDecodePageDataGeneric nsys the PR branch vs branch-24.10

branch	time	registers per thread	shared mem executed	theoretical occupancy	latency
24.10	1.762 s	72	32,768	87.5 %	9.632 μs
PR	1.911 s	64	65,536	100 %	10.028 μs

ncu:

branch	compute throughput	memory throughput
24.10	0.21	0.21
PR	0.24	0.24

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[gerashegalov]

Investigating a bug in this PR where batch_len goes negative on a 33M-row run:

DEBUG thread=96 warp_id=3 warp_lane=0 => batch_len=-8 negative=1 (size=33554423 remaining=96 max_count=526848, last_run_pos=526856)

[gerashegalov]

Negative batch fixed with 09dd99e

[gerashegalov]

If the benchmark is scaled 100x by replicating the the 4 pages-x-250-million file the PR branch performance drops significantly

Base wall clock for the query: 360 seconds
PR wall clock: 433 seconds