Skip to content
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

@fastmath log is slower #36214

Closed
kwdye opened this issue Jun 9, 2020 · 13 comments
Closed

@fastmath log is slower #36214

kwdye opened this issue Jun 9, 2020 · 13 comments
Labels
maths Mathematical functions

Comments

@kwdye
Copy link

kwdye commented Jun 9, 2020

I'm finding the fastmath implementation of log() to actually be slower than the non-fastmath version.

julia> lottalogs(x) = log.(x)
julia> lottalogsfast(x) = @fastmath log.(x)
julia> zz = rand(100000);
julia> @btime lottalogs(zz);
  497.300 μs (2 allocations: 781.33 KiB)
julia> @btime lottalogsfast(zz);
  778.857 μs (2 allocations: 781.33 KiB)

This was done on Julia 1.4.2 on an AMD 3900X in Fedora Linux.

@KristofferC
Copy link
Member

Same with cbrt for me. The trend seems to be that the ones we have native Julia implementations of are faster than the @fastmath ones that just calls into libm.

@yuyichao
Copy link
Contributor

yuyichao commented Jun 9, 2020

Ref #26434 ref #24031 .... The PR's that changes the non-fastmath implementation never changes the fastmath one..... And I was pretty sure there was a specific issue for this but maybe not....

@simonbyrne
Copy link
Contributor

Can we just get rid of @fastmath?

(but not @fastmath)

@kimikage
Copy link
Contributor

This is a separate problem, but the non-fastmath version of cbrt can cause performance issues with precompilation (#35972). Please be aware of the issue when benchmarking.

@musm
Copy link
Contributor

musm commented Jun 10, 2020

I agree with @simonbyrne suggestions. I have thought about this before and glad it has been brought up.

@ChrisRackauckas
Copy link
Member

Not sure about in general. @fastmath abs(z) on a complex number is still significantly faster, though maybe that could just be improved on the Julia side.

@pkofod
Copy link
Contributor

pkofod commented Jun 11, 2020

And I was pretty sure there was a specific issue for this but maybe not....

I think it's just been discussed many times on all the PRs for libm features, but I also thought there was an issue.

For log specifically, it would make sense if fastmath calls openlibm, but log calls the table based method.

@yuyichao
Copy link
Contributor

Getting rid of @fastmath might be good, not because of this issue, but because it's too loosely defined. People use it for all sort of different reasons (which all make code run "fast"). But before doing/evaluating that the replacement should go in first. e.g. #31862 and from the way people would like to use these this is certainly not trivial, and it'll likely always involve authors of the math function to do the right thing.

@oscardssmith
Copy link
Member

Is it time for taking fastmath seriously?

@simonbyrne
Copy link
Contributor

There are other issues: @fastmath operates syntactically which can cause unexpected reults (#26828); --math-mode=fast doesn't do syntactic rewriting, instead just enables the compiler optimizations, which leads to other bizarre behavior (#30073).

Both are giant footguns.

@StefanKarpinski
Copy link
Member

Where "taking fastmath seriously" means "deleting fastmath" 😁

@musm musm added the maths Mathematical functions label Jun 11, 2020
@ViralBShah
Copy link
Member

fastmath is now a no-op with #41638

@oscardssmith
Copy link
Member

This is about the macro, not the mode. However the actual issue has also been fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maths Mathematical functions
Projects
None yet
Development

No branches or pull requests