-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Generalize storage of factorizations. #42594
Conversation
This will also be nice for the day when we finally get around to implementing arbitrary-axis support for appropriate parts of linear algebra. |
CI seems OK with this, so let's try PkgEval: @nanosoldier Note that I haven't updated all factorizations, so this may result in too positive of a report. |
This comment has been minimized.
This comment has been minimized.
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
None of the test errors are related to this change so it might actually be fine go move forward with this in 1.x |
9c97ccf
to
901b229
Compare
That's encouraging. I've updated the PR to include the remaining factorizations; I'll do another PkgEval run when CI passes. |
901b229
to
1740e23
Compare
I wouldn't have expected errors, actually. I think the one major concern about adding type parameters is that when these are types of fields, the formely concrete types become unsufficiently parametrized and hence abstract, which may affect performance. But I'm not proficient enough with our package search engine to find out if that's a common pattern in the ecosystem. |
@nanosoldier |
Yes, I think we have avoided adding extra type parameters for this reason in the past. |
I wouldn't expect there to be many structs capturing factorizations, but there exist some at least. From a quick look at JuliaHub, filtering out instances that are currently abstract already:
I'd be happy to take a closer look and submit PRs to packages if that's an argument in favor. |
I think this change is worth it even if some structs become weakly typed. This is something that was requested before 1.0 but we didn't get around to so if it can be done without breaking code then I think we should move forward. |
We added a type-parameter to |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
1740e23
to
122d385
Compare
122d385
to
f547262
Compare
Rebased. Let's do another PkgEval run to see if there isn't any unexpected breakage since last time: @nanosoldier With the 1.8 feature freeze soon, do we want to consider this? Comments above seemed positive, PkgEval fallout minimal, and for the few packages that do regress (in terms of functionality of performance) I can create PRs to fix them. |
SGTM |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
Package test failures are related, but respectively in HomotopyContinuation:
Pathfinder:
Some packages generate warnings, but don't cause test failures:
So all in, this looks reasonable, and I think we can merge this for 1.8. I'll deal with the fallout, and once it's merged look at fixing or improving packages. |
The ambiguity in Pathfinder.jl is due to the fact that type inference believes there can be a |
Introduce additional type parameters to remove hard-coded arrays from structures.
f547262
to
6e35e9f
Compare
Another rebase to confirm CI failures are unrelated (tester_linux64 had a linalg failure, but the log was not clear). |
GC failure is known issue with ASAN after the recent effects PR, so this looks good to go. |
Introduce additional type parameters to remove hard-coded arrays from structures.
Introduce additional type parameters to remove hard-coded arrays from structures.
Introduce additional type parameters to remove hard-coded arrays from structures.
…uliaLang#45935) Accidentally introduced by JuliaLang#42594.
…uliaLang#45935) Accidentally introduced by JuliaLang#42594.
Our current Factorization structures often hard-code the storage of indices, coefficients, ... resulting in downstream packages like CUDA.jl or StaticArrays.jl having to re-implement these structures for compatibility. For example, https://github.com/JuliaArrays/StaticArrays.jl/blob/559134c9edda3b8ee9a71938386d2904338d7cc9/src/qr.jl#L1-L6 or https://github.com/JuliaGPU/CUDA.jl/blob/43e0f48b135325b97415cd1c8802e47732de85c6/lib/cusolver/linalg.jl#L77-L81. This is unfortunate, since it requires duplicating a lot of functionality, and requires special-casing in packages like ChainRules.jl.
This PR explores adding additional type parameters to a couple of factorization structures (more to be added) to explore the fallout such a change. It's unlikely that we can do this in Julia 1.x, but maybe PkgEval tells otherwise...
cc @andreasnoack, ref JuliaGPU/CUDA.jl#1194 (comment).