Rework some code logic to reduce iterator and comparator inlining to improve compile time

[davidwendt]

Description

Disables inlining the device code logic for the row operators for nested column types did not work as hoped.
Some files took longer to compile and some functions ran 20% slower for large rows.

Reworking individual source files to break up the code logic into multiple kernels seems to work well for compile time while having a smaller effect on performance. The goal is to only rework the nested column code paths.
Here are some source files that have compile time issues and are improved in this PR.

source file	current	PR
stream_compaction/unique_count.cu	18 min	13 min
groupby/sort/group_nunique.cu	16 min	2 min
stream_compaction/unique.cu	16 min	5 min
groupby/sort/sort_helper.cu	10 min	6.5 min
search/contains_scalar.cu	12 min	4.7 min
sort/is_sorted.cu	9 min	7 min
groupby/sort/group_std.cu	7 min	1.2 min
groupby/sort/group_m2.cu	6 min	1.2 min

Available benchmarks showed minimal impact to performance.

Checklist

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

[PointKernel]

Is it fair to say that we should avoid the below functions to reduce build time?

• cudf::detail::make_counting_transform_iterator
• thrust::make_transform_iterator
• thrust::unique_copy
• thrust::count_if
• thrust::is_sorted

[davidwendt]

Is it fair to say that we should avoid the below functions to reduce build time?

• cudf::detail::make_counting_transform_iterator
• thrust::make_transform_iterator
• thrust::unique_copy
• thrust::count_if
• thrust::is_sorted

Not in general. The transform iterators are certainly not the issue. The copy_if, and is_sorted all end up calling some version of cub:reduce. If the iterators/comparators they are given are more than a few lines of logic, the code bloat can be extreme due to large amount of inlining of the inputs throughout the generated kernel. And unique_copy has similar issues with inlining the comparator.
I will try to work on a more formal document outlining what to avoid and how to get around this problem.

[PointKernel]

LGTM

Looking forward to seeing the build time guideline doc.

[bdice]

This is fantastic. These optimizations look correct and seem sensible, when considering the kernel complexity that we are now able to split up. I'd like a few small comments like the ones I suggested here, to indicate that our choices of algorithms are informed by compile time. That will clear things up for the reader, and help prevent "clever" refactors down the line.

[bdice]

If this compiles faster for nested types, does it also compile faster for non-nested types? If it's possible to unify these and have a single implementation of the algorithms, I would prefer that (rather than one transform + copy_if for nested types and one unique_copy for non-nested types).

If there are considerations like runtime, memory usage, etc. that warrant two separate implementations, then let's inform the reader with some comments explaining this decision.

[davidwendt]

It does compile faster for non-nested types but the performance impact was too large (20-50% increase) for this path.

[bdice]

Love the comments. Thanks for that -- it helps a lot for future readers, and makes us more aware of the process of making compile time improvements.

[ttnghia]

I love this.

[davidwendt]

/merge

[davidwendt]

/merge