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

mapreduce/mapfoldl unrolls fully, failing to compile for large static sizes #1028

Open
chengchingwen opened this issue May 20, 2022 · 5 comments

Comments

@chengchingwen
Copy link

MWE:

julia> x = SizedVector{30000}(randn(30000));

julia> 0.5 in x
ERROR: syntax: invalid syntax (memory-error out of gc handles)
Stacktrace:
 [1] top-level scope
   @ REPL[4]:1
 [2] _mapreduce
   @ ~/.julia/packages/StaticArrays/58yy1/src/mapreduce.jl:113 [inlined]
 [3] in(x::Float64, a::SizedVector{30000, Float64, Vector{Float64}})
   @ StaticArrays ~/.julia/packages/StaticArrays/58yy1/src/mapreduce.jl:267
 [4] top-level scope
   @ REPL[4]:1
 [5] top-level scope
@thchr
Copy link
Collaborator

thchr commented May 31, 2022

This happens because Base.in is forwarded to _mapreduce, which in turn is forwarded to _mapfoldl which is fully unrolled without any size cut-off. I.e., the current implementation does a full unroll of the loop so the code size is out of hand for S = 30000.

The broader problem is discussed in #439.

@thchr thchr changed the title Error when calling Base.in with large SizedArray mapreduce/mapfoldl unrolls fully, failing to compile for large static sizes May 31, 2022
@chengchingwen
Copy link
Author

I see. BTW, I turn into using findfirst as a replacement and it doesn't seem to be forwarded to _mapreduce. I'm curious about would these "find" function also benefit from unrolling?

@mateuszbaran
Copy link
Collaborator

When you have more than 1000 elements in an array, then I doubt there is any function in StaticArrays.jl that would be actually faster than the plain Array implementation. Are you sure you actually need SizedVector?

@chengchingwen
Copy link
Author

I use SizedVector merely for having the length value as type parameter and avoiding push!/pop! operations at the surface level. Maybe there is a better choice for this need?

@mateuszbaran
Copy link
Collaborator

SizedArray would be fine if you accessed the data field, for example 0.5 in x.data instead of 0.5 in x. I don't really know any other types that would work better.

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

No branches or pull requests

3 participants