-
Notifications
You must be signed in to change notification settings - Fork 4k
GH-43719: [C++] Clarify the way SIMD-enabled agg kernels come from the same code in different compilation units #43720
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
|
@kou where would I change CMake code to skip the installation of |
|
I checked binary size impact: |
|
Could you add arrow/cpp/cmake_modules/BuildUtils.cmake Lines 956 to 958 in 2767dc5
|
I |
|
I thought the rule only matched on |
|
@ursabot please benchmark command=cpp-micro --suite-filter=arrow-acero-aggregate-benchmark --benchmark-filter=MinMaxKernel* --iterations=3 |
|
Benchmark runs are scheduled for commit ff39f8482bd772d70d337349fe0c9eb43566a337. Watch https://buildkite.com/apache-arrow and https://conbench.ursa.dev for updates. A comment will be posted here when the runs are complete. |
|
Thanks for the changes! |
|
Thanks for your patience. Conbench analyzed the 0 benchmarking runs that have been run so far on PR commit ff39f8482bd772d70d337349fe0c9eb43566a337. None of the specified runs were found on the Conbench server. The full Conbench report has more details. |
|
Seems lint failed |
It's the |
|
Hey @felipecrv, I recently made changes to the @ursabot and forgot to update the help message, sorry! You don't need to add the |
|
@ursabot please benchmark command=cpp-micro --suite-filter=arrow-acero-aggregate-benchmark --benchmark-filter=MinMaxKernel* |
|
Benchmark runs are scheduled for commit a36a8d04f618b6ee1fe62e1756cea880e6996435. Watch https://buildkite.com/apache-arrow and https://conbench.ursa.dev for updates. A comment will be posted here when the runs are complete. |
|
Thanks for your patience. Conbench analyzed the 3 benchmarking runs that have been run so far on PR commit a36a8d04f618b6ee1fe62e1756cea880e6996435. There weren't enough matching historic benchmark results to make a call on whether there were regressions. The full Conbench report has more details. |
eb64fde to
2c9a588
Compare
|
@austin3dickey can I run something on my machine to test these benchmark filters? I'm confused about why they don't match any benchmark here. EDIT: I misunderstood the message. There aren't baselines to compare, but the benchmarks ran. |
|
Yeah @felipecrv, it looks like they ran. I just noticed we don't run this suite on the |
Yes, you can install archery and do |
|
Okay, I ran a similar run on the latest There isn't a z-score comparison because we don't have a distribution of baseline results to compare to; just the one. But you can look at the percent change column. |
pitrou
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay @felipecrv . This looks good to me, thanks!
|
@github-actions crossbow submit -g cpp |
|
Revision: 447fbc9 Submitted crossbow builds: ursacomputing/crossbow @ actions-7e561de588 |
|
After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 6ce2af7. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. |
…rom the same code in different compilation units (apache#43720) ### Rationale for this change More than once I've been confused about how the `SimdLevel` template parameters on these kernel classes affect dispatching of kernels based on SIMD support detection at runtime [1] given that nothing in the code changes based on the parameters. What matters is the compilation unit in which the templates are instantiated. Different compilation units get different compilation parameters. The SimdLevel parameters don't really affect the code that gets generated (!), they only serve as a way to avoid duplication of symbols in the compiled objects. This PR organizes the code to make this more explicit. [1] apache#7871 (comment) ### What changes are included in this PR? - Introduction of aggregate_basic-inl.h - Moving of the impls in `aggregate_basic-inl.h` to an anonymous namespace - Grouping of code based on the function they implement (`Sum`, `Mean`, and `MinMax`) ### Are these changes tested? By the compilation process, existing tests, and benchmarks. * GitHub Issue: apache#43719 Lead-authored-by: Felipe Oliveira Carvalho <felipekde@gmail.com> Co-authored-by: Antoine Pitrou <antoine@python.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
Rationale for this change
More than once I've been confused about how the
SimdLeveltemplate parameters on these kernel classes affect dispatching of kernels based on SIMD support detection at runtime [1] given that nothing in the code changes based on the parameters.What matters is the compilation unit in which the templates are instantiated. Different compilation units get different compilation parameters. The SimdLevel parameters don't really affect the code that gets generated (!), they only serve as a way to avoid duplication of symbols in the compiled objects.
This PR organizes the code to make this more explicit.
[1] #7871 (comment)
What changes are included in this PR?
aggregate_basic-inl.hto an anonymous namespaceSum,Mean, andMinMax)Are these changes tested?
By the compilation process, existing tests, and benchmarks.