Skip to content

Conversation

@mikmoore
Copy link
Contributor

@mikmoore mikmoore commented Jan 5, 2023

hypot(::IEEEFloat...) can be made faster for 3+ arguments.

using BenchmarkTools

t3 = ntuple(_->randn(), 3)
t4 = ntuple(_->randn(), 4)
t8 = ntuple(_->randn(), 8)
t16 = ntuple(_->randn(), 16)

@btime hypot($t3...)
@btime hypot($t4...)
@btime hypot($t8...)
@btime hypot($t16...)

# master
  9.810 ns (0 allocations: 0 bytes)
  10.110 ns (0 allocations: 0 bytes)
  19.759 ns (0 allocations: 0 bytes)
  50.203 ns (0 allocations: 0 bytes)

# SHA 1a0340c
  7.808 ns (0 allocations: 0 bytes)
  8.008 ns (0 allocations: 0 bytes)
  10.010 ns (0 allocations: 0 bytes)
  14.529 ns (0 allocations: 0 bytes)

The notable savings here come from casting to integers before computing maximum(abs,...) (same result but faster comparisons) and re-associating the final sum (see #48129).

@giordano
Copy link
Member

giordano commented Jan 5, 2023

Does this help with #47917?

@mikmoore
Copy link
Contributor Author

mikmoore commented Jan 5, 2023

Does this help with #47917?

It appears that issue should be closed on the current master -- probably by #44357. You can see from the timings presented above that 3 not slower than 4 (although it's only marginally faster) on both master and this PR.

@giordano
Copy link
Member

giordano commented Jan 6, 2023

It appears that issue should be closed on the current master -- probably by #44357.

#44357 is already in v1.9, where #47917 was reported on.

@KristofferC
Copy link
Member

I don't see the issue having been reprod on beta2.

@sethaxen
Copy link
Contributor

sethaxen commented Jan 7, 2023

I don't see the issue having been reprod on beta2.

Yes, I still see the specific issues in #47917 (comment) and #47917 (comment) on v1.9.0-beta2

@mikmoore
Copy link
Contributor Author

mikmoore commented Jan 7, 2023

In any case, the issue was fixed before any efforts from this PR (or otherwise never existed on my architecture). If someone's ambitious, they can try to find the responsible PR and see if it'll be accepted as a backport to 1.9.

@vtjnash vtjnash requested a review from oscardssmith January 22, 2023 05:28
@ViralBShah
Copy link
Member

Merge?

@mikmoore
Copy link
Contributor Author

There isn't anything else I was planning to do with this unless someone had additional comments. It's good to merge on my end.

@oscardssmith oscardssmith merged commit 80f6f2a into JuliaLang:master Jan 28, 2023
@IanButterworth
Copy link
Member

I think this broke build. Was CI green on it?

math.jl
error during bootstrap:
LoadError("sysimg.jl", 3, LoadError("Base.jl", 328, LoadError("math.jl", 844, LoadError("math.jl", 851, UndefVarError(Symbol("@fastmath"))))))
ijl_undefined_var_error at /home/ian/Documents/GitHub/julia/src/rtutils.c:132

IanButterworth added a commit that referenced this pull request Jan 28, 2023
DilumAluthge pushed a commit that referenced this pull request Jan 28, 2023
@oscardssmith
Copy link
Member

CI was green but possibly got rebase broken

@mikmoore
Copy link
Contributor Author

mikmoore commented Feb 7, 2023

So I'm guessing the issue here is that @fastmath is not defined at the point this code is loaded. It's significant to the performance here, due to #48129. Does someone have a suggestion for how to resolve this?

@giordano
Copy link
Member

giordano commented Feb 7, 2023

Move hypot to another file which is included in Base after fastmath?

Edit: ah, but this is inside the Math module....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

maths Mathematical functions performance Must go faster

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants