JuliaArrays / JuliaArrays/FillArrays.jl
Optimize + for OneElement
Nobody has claimed this yet.
- Dominant language
- Julia
- Stars
- 187
- Forks
- 41
- Avg merge
- 17h 29m
- Merged PRs (30d)
- 1
Description
There is a significant optimization we can make to + where one of the arguments is a OneElement
I wrote out the general case for it here:
https://github.com/JuliaDiff/ChainRules.jl/pull/717/files#diff-3ebfe4c6177a89aaa1620d8565d89c551d882f7def080c63c343779c16366741R114-R124
though that uses ChainRulesCore.is_inplaceable_destination to workout if an array can be mutated which would need to be stripped before porting. Since there has been arguments against directly depending on CRC in this package in the past.
For this case on a 300x300 array it gives a 3x speedup (https://github.com/JuliaDiff/ChainRules.jl/pull/717#issuecomment-1556575490)
But there are even more optimal cases when both elements are OneElement (at cost of complete type stability)
And possibly other types too.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked ChainRules.jl implementation and inspect the existing + methods involving OneElement in FillArrays.jl. Determine how the optimization can avoid a direct ChainRulesCore dependency, then compare the relevant array cases, including two OneElement operands. Done means the supported cases are optimized without compromising the package's intended type-stability tradeoffs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- performance
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100