transform_reduce algorithms - #4523
Open
roystgnr wants to merge 15 commits into
Open
Conversation
This simplifies the code a bit in DenseVector, and might optimize it a bit in DenseMatrix
We'd like to support user types as type T, but user types are supposed to use ADL for these things, not put things in namespace std.
In theory it's possible for a seq (default) STL reduce to be slower than a hand-coded loop; in practice I've found one case (plain integer accumulation) where g++ slows down by 20% (though clang++ gets it right), and for pretty much everything else the STL is like 50% faster or more, even in sequential mode, if only because using "reduce()" tells the compiler that we don't care about element ordering and so it can do SIMD tricks that treat FP arithmetic as associative.
Otherwise our tests trip one for me when built with -march=native
GiudGiud
reviewed
Aug 16, 2026
| return my_min; | ||
| return std::transform_reduce | ||
| (_val.begin(), _val.end(), std::numeric_limits<T>::max(), | ||
| [](auto a, auto b){using std::min; return min(a,b);}, |
Contributor
There was a problem hiding this comment.
should we do references? in case we end up doing DenseMatrix
Member
Author
There was a problem hiding this comment.
I had to "Copy Markdown" to see DenseMatrix<ADReal>, but yeah, you're quite right.
| return my_max; | ||
| return std::transform_reduce | ||
| (_val.begin(), _val.end(), std::numeric_limits<T>::lowest(), | ||
| [](auto a, auto b){using std::max; return max(a,b);}, |
Member
Author
|
Well, aside from the I'll add a shim as a workaround for now, I think. |
This might be a big deal later if we use e.g. AD types for T.
I like this version better.
We don't want to pull <numeric> into every single libMesh file... yet!
roystgnr
changed the title
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
3 participants
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.
I haven't created benchmarks for these specific changes in libMesh, but in some test code the results were surprisingly awesome.
In theory it's possible for a seq (default) STL reduce to be slower than a hand-coded loop; in practice I've found one case (plain integer accumulation) where g++ slows down by 20% (though clang++ gets it right), and for pretty much everything else the STL is like 50% faster or more, even in sequential mode, if only because using "reduce()" tells the compiler that we don't care about element ordering and so it can do SIMD tricks that treat FP arithmetic as associative.
I'm hoping to eventually get good enough with these algorithms to do GPGPU tricks with nvc++ in new code paths, but even before then we can probably get some great threaded and some decent serial speedup in slightly-updated existing code paths.
Edit: I'm going to restrict this PR to the serial simplification+speedup, especially since it now requires configure tests just to be sure we can use std::transform_reduce at all. Parallelizing C++17 algorithms requires TBB with g++/clang++, so I'll need some more configure tweaking before we turn that on.
Edit 2: My tests on -O2 builds of real work are ranging from 2%-50% faster, and now I see that trying -O3 and/or -march only makes them help a bit more, but with -O0 on tiny kernels I'm seeing ~60% slowdown over hand-coded loops. Our dbg mode is already expected to be quite slow, but if we start using these everywhere it's not going to help.