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

MArray is slower than Array in reduction #540

Closed
YingboMa opened this issue Nov 10, 2018 · 6 comments
Closed

MArray is slower than Array in reduction #540

YingboMa opened this issue Nov 10, 2018 · 6 comments
Labels
crazy-slow yikes! performance runtime performance

Comments

@YingboMa
Copy link
Contributor

MWE:

julia> using BenchmarkTools

julia> a = @MArray rand(4);

julia> @btime sum( $(Array(a)) )
  3.896 ns (0 allocations: 0 bytes)
1.5713808992800153

julia> @btime sum( $a )
  30.021 ns (1 allocation: 16 bytes)
1.5713808992800153
@c42f
Copy link
Member

c42f commented Jul 31, 2019

This is still the case on the latest julia. Ultimately it may be due to keyword functions (in this case mapreduce) not getting inlined.

@tkoolen
Copy link
Contributor

tkoolen commented Jul 31, 2019

Yeah, in some of the Base reduce/mapreduce code, NamedTuples are sometimes passed around as positional argument instead of using keyword arguments, probably for this reason.

https://github.com/JuliaLang/julia/blob/cce5a6b3d7303a4ca74a7f630b452d29b06e5903/base/reduce.jl#L39

@mateuszbaran
Copy link
Collaborator

Unfortunately, passing keyword arguments around is relatively slow in Julia (it requires an invoke). The easiest solution is to define a bunch of methods like

@inline sum(a::StaticArray{<:Tuple,T}) where {T} = reduce(+, a)

to avoid passing keyword arguments. I can make a patch if you want.

@c42f
Copy link
Member

c42f commented Sep 19, 2019

I can make a patch if you want.

Yes please!

Did you read the code @tkoolen pointed to above? It seemed to me that might be a way to avoid some of the cost.

@mateuszbaran
Copy link
Collaborator

Did you read the code @tkoolen pointed to above? It seemed to me that might be a way to avoid some of the cost.

Yes, I'm trying to invent a less tedious solution.

@c42f
Copy link
Member

c42f commented Sep 26, 2019

Fixed in #659 (thanks to @mateuszbaran :-) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crazy-slow yikes! performance runtime performance
Projects
None yet
Development

No branches or pull requests

4 participants