[POC] Back libcudf scalars with Arrow-compatible column storage - #23765
Draft
GregoryKimball wants to merge 14 commits into
Draft
[POC] Back libcudf scalars with Arrow-compatible column storage#23765GregoryKimball wants to merge 14 commits into
GregoryKimball wants to merge 14 commits into
Conversation
Cover numeric, decimal, string, and list materialization before replacing their independent storage representations.
Unify fixed-width, decimal, string, list, and struct scalar ownership with Arrow-compatible column storage so scalar views are allocation-free and host validity checks no longer synchronize.
Pass the scalar's owned one-row view directly so AST literals avoid materializing an auxiliary column while retaining exact nullability.
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
Keep zero-copy storage for AST literals whose owners outlive execution while materializing internally synthesized scalars such as rescale parameters.
Remove scalar conversion allocations and const casts by consuming owned one-row views directly, including null-aware string operations.
Remove scalar conversion allocations and const casts by comparing directly against owned one-row column views.
Read sequence inputs through one-row column device views, removing typed scalar adapters and const casts.
Retain scalar-backed column device views at call sites and broadcast row zero through standard column iterators, removing typed scalar adapters and const casts.
Read separators and null replacements through retained one-row column device views, removing string scalar adapters and const casts.
Expose mutable one-row column views for scalar value producers while keeping host null counts authoritative and requiring explicit reconciliation after device mask writes.
Keep scalar validity coherent through host metadata and ordered mask updates, matching the column producer contract without a scalar-specific synchronization API.
Avoid one-row materialization and typed scalar device views by consuming the scalar's owned column storage directly.
Update developer and API guidance to describe one-row column storage and column device views as the preferred access path.
Measure construction latency and peak memory for nullable numeric and variable-size string scalars.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
cudf::scalarandcudf::columncurrently use incompatible device layouts:scalar::is_valid()synchronizes with the device (#8064), and scalar validity cannot safely be interpreted as a column bitmask (#22757).These are different logical abstractions, but they do not need different physical storage. A scalar can own the same Arrow-compatible layout as a one-row column while retaining scalar-specific constructors and accessors.
This implements the central storage proposal from #19465.
Summary
cudf::columnstorage.scalar::is_valid()no longer synchronizes.const_casts from migrated consumers.Benchmark results
For order-32 FLOAT32 polynomials, the JIT path improves most because it avoids per-literal one-row materialization. AST and binary-op paths show smaller gains because they already used lightweight scalar adapters.
Checklist