Skip to content

MAINT: simplify power fast path logic #27901

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.

Sign up for GitHub

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

Merged
merged 28 commits into from
Jan 7, 2025
Merged

MAINT: simplify power fast path logic #27901

Changes from 1 commit
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
6923108
MAINT: remove fast paths from array power
MaanasArora Dec 4, 2024
8196fbb
MAINT: Add fast paths to power loops
MaanasArora Dec 4, 2024
4090a1c
MAINT: Clean loops for integer power in umath
MaanasArora Dec 4, 2024
91dd9dd
MAINT: Remove blocking regression test for power fast paths
MaanasArora Dec 4, 2024
c0e88c8
MAINT: Add helper function for power fast paths
MaanasArora Dec 4, 2024
c00489d
BUG: Change misspelled bitwise and to logical and
MaanasArora Dec 4, 2024
1d9f355
BUG: Fix missing value on power helper return
MaanasArora Dec 4, 2024
4b2920c
BUG: Fix exponent bitwise logic in power fast paths
MaanasArora Dec 4, 2024
dd6e773
MAINT: Add power fast paths to floating point umath
MaanasArora Dec 4, 2024
c95bff2
MAINT: Add fast power paths to array power when exponent is python ob…
MaanasArora Dec 4, 2024
084416e
MAINT: Fix division by zero runtime warning in test regression
MaanasArora Dec 4, 2024
e23423c
MAINT: Adapt object regression test for linalg to power fast paths
MaanasArora Dec 5, 2024
7cad24e
MAINT: Remove incorrect declarations in power fast paths
MaanasArora Dec 5, 2024
c028996
MAINT: Reduce calls to power fast path helper when scalar is ineligible
MaanasArora Dec 5, 2024
3297309
MAINT: Fix missing sliding loop
MaanasArora Dec 5, 2024
455407f
BUG: Fix syntax error
MaanasArora Dec 5, 2024
df6f54a
MAINT: Fix semantic misuse of -1 for non-error returns
MaanasArora Dec 5, 2024
d10bce5
MAINT: Improve error checking in power fast paths to remove PyErr_Clear
MaanasArora Dec 5, 2024
21c12a6
MAINT: Improve type checking in power fast paths
MaanasArora Dec 5, 2024
c9929ff
MAINT: Efficient handling of ones arrays in scalar fast paths
MaanasArora Dec 5, 2024
ed449e7
MAINT: Simplify outer check for scalar power fast paths
MaanasArora Dec 6, 2024
ba24783
MAINT: Reduce code reuse in float power fast paths and add reciprocal
MaanasArora Dec 6, 2024
b5f8a2b
MAINT: Remove Python scalar checking for fast power paths
MaanasArora Dec 10, 2024
023d55a
MAINT: Add benchmarks for power operators in float binary bench
MaanasArora Dec 11, 2024
efbd6b8
MAINT: Add scalar power fast paths
MaanasArora Dec 11, 2024
31418e9
BUG: Add missing pointer cast
MaanasArora Dec 11, 2024
a5d0ef4
BUG: Allow scalar power fast paths only for non-integers
MaanasArora Dec 11, 2024
2e0f6ca
MAINT: Restore outdated changes in regression test to master
MaanasArora Dec 27, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
MAINT: Add fast paths to power loops
  • Loading branch information
@MaanasArora
MaanasArora committed Dec 4, 2024
commit 8196fbb1d275cc7ef58ac1fccfb431f3c865719e
20 changes: 15 additions & 5 deletions numpy/_core/src/umath/loops.c.src
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -525,15 +525,25 @@ NPY_NO_EXPORT void
if (in2 == 0) {
*((@type@ *)op1) = 1;
continue;
}
else if (in2 == 1)
{
*((@type@ *)op1) = *(@type@ *)ip1;
}
else if (in2 == 2)
{
*((@type@ *)op1) = *(@type@ *)ip1 * *(@type@ *)ip1;
}
if (in1 == 1) {
else if (in1 == 1) {
*((@type@ *)op1) = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit confused by the new (and existing) fast paths here. The first branch is the scalar case and it would seem to me that any fast path is even more relevant there?
Should the fast path just be copied? Maybe there should be a second helper with the body so that we can have a if (stride[1] == 0) {call helper()} else {call_helper()} to nudge the compiler to optimize for 0 stride (and assume it'll lift the checks out of the loop then).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, the if (steps[1]==0) { path (sorry, I wrote stride above, the ufunc code here calls it "steps") is the path we need to worry about being fast.

I.e. if the second operand is a scalar, then we will always take that part (I am not 100% sure about scalar**scalar.).

Copy link
Contributor Author

@MaanasArora MaanasArora Dec 4, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I stuck to the original fast path logic but I agree the scalar case is more important for efficiency. I've created a helper function to remove repetition.

continue;
}

int first_bit = in2 & 1;
in2 >>= 1;
*((@type@ *) op1) = _@TYPE@_squared_exponentiation_helper(in1, in2, first_bit);
else
{
int first_bit = in2 & 1;
in2 >>= 1;
*((@type@ *) op1) = _@TYPE@_squared_exponentiation_helper(in1, in2, first_bit);
}
}
}
/**end repeat**/
Expand Down
Loading
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy