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

RFC: merging range indexes for faster subarray linear indexing #3778

Closed
wants to merge 1 commit into from
Closed

RFC: merging range indexes for faster subarray linear indexing #3778

wants to merge 1 commit into from

Conversation

timholy
Copy link
Sponsor Member

@timholy timholy commented Jul 21, 2013

I doubt that any sane person will want to review the index gymnastics here, but this provides huge speed improvements for certain types of SubArray operations. It implements a commented TODO (which I deleted a couple of days ago, so I figured I better do it!): using range indexes, when possible, for trailing linear indexing dimensions. It's an optimization that is only applicable under certain conditions, but those conditions arise fairly commonly in practice (e.g., array slices).

Previously:

julia> A = reshape(1:1004*1002*5, 1004, 1002, 5);

julia> s = slice(A, 1:1004, 1:1002, 3);

julia> @time v = s[:];
elapsed time: 1.125853572 seconds (223735572 bytes allocated)

julia> @time v = s[:];
elapsed time: 0.830600176 seconds (216159344 bytes allocated)

(My commit from earlier this morning made this already ~2.5x faster than it was yesterday.)

With this code:

julia> @time v = s[:];
elapsed time: 0.012385493 seconds (8105976 bytes allocated)

julia> @time v = s[:];
elapsed time: 0.009245699 seconds (8049224 bytes allocated)

So about a 100-fold speed improvement, not bad, and indeed it's as fast as A[:,:,3].

The algorithmic details are not fun, but comments on the overall architecture and naming might be useful. For instance, there's a fair amount of overlap between these functions; would it be better to merge them and return 1:0 if the indexes are not mergeable? (One downside is that there would be some additional computational burden on cases where merging fails.) Note also that the code returns either a Range1 or Range, and perhaps that's a bad idea? Finally, feel free to suggest any additional tests that I might have missed.

This only helps when the indexes are commensurate, but when that's true it's a huge benefit
@simonster simonster mentioned this pull request Nov 19, 2013
21 tasks
@ViralBShah
Copy link
Member

Bump. Is this ready to merge?

@timholy
Copy link
Sponsor Member Author

timholy commented Dec 26, 2013

I'm torn. This lies somewhere between "potentially very useful" and "a desperate measure to sidestep a more fundamental problem." If Stefan has fast linear indexing on the way, then there may be no need for this.

@timholy
Copy link
Sponsor Member Author

timholy commented Dec 1, 2014

No longer as relevant as it used to be. Closing.

@timholy timholy closed this Dec 1, 2014
KristofferC added a commit that referenced this pull request Feb 8, 2024
…53220)

Replaces #53216 (I can't push to
that repo branch)

Adds
- making pkgimages for REPLExt
- Fixes PkgCompletionProvider location

Stdlib: Pkg
URL: https://github.com/JuliaLang/Pkg.jl.git
Stdlib branch: master
Julia branch: master
Old commit: f3b81f1aa
New commit: 6dd0e7c9e
Julia version: 1.11.0-DEV
Pkg version: 1.11.0
Bump invoked by: @IanButterworth
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaLang/Pkg.jl@f3b81f1...6dd0e7c

```
$ git log --oneline f3b81f1aa..6dd0e7c9e
6dd0e7c9e Revert "add test for recurring precompile" (#3779)
dbf114fa9 Merge pull request #3777 from JuliaLang/kc/repl_extension
a49d47981 fixup
e3edf3917 avoid prompting for git creds on CI (#3778)
510454343 make the `REPL` specific code into an extension
12d2de14e make `pkgstr` independent of REPL
```

---------

Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
Co-authored-by: Valentin Churavy <vchuravy@users.noreply.github.com>
Co-authored-by: Kristoffer Carlsson <kcarlsson89@gmail.com>
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
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

Successfully merging this pull request may close these issues.

None yet

2 participants