-
-
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
enable inline allocation of structs with pointers #34126
Conversation
@nanosoldier |
Ah, forgot to add Nanosoldier as a repository collaborator after switching to his account... I pushed the report manually: https://github.com/maleadt/BasePkgEvalReports/blob/master/pkgeval-86ae65b_vs_630a551/report.md (and it's segfault-o-clock). |
86ae65b
to
54133f9
Compare
@nanosoldier |
Your test job has completed - possible new issues were detected. A full report can be found here. cc @maleadt |
Working through this list, will update as I learn more:
time limited: numeric and other problems with tests as written (these should be filed as issues against their respective packages): |
54133f9
to
23159b0
Compare
@nanosoldier |
Your test job has completed - possible new issues were detected. A full report can be found here. cc @maleadt |
23159b0
to
539cbf1
Compare
I've seen it deadlock sometimes in PkgEval. My guess is that it is this test that hangs: https://github.com/KristofferC/OhMyREPL.jl/blob/70927549f78591e9b572714b5ed5b8e3a25f795a/test/flicker.jl#L5-L19. It is most likely unrelated to this PR though. |
f029e3c
to
b497e44
Compare
b497e44
to
b9de078
Compare
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt |
Found the issue in EfficientGlobalOptimization. NLopt has an array of immutable structs of two pointers (references) each ( |
198567a
to
b7347ba
Compare
@nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan |
That's looking super. Only one I wondered about (if it's real) was:
|
It looks like |
b7347ba
to
13a62dc
Compare
Exciting!! |
* origin/master: (833 commits) Improve typesubtract for tuples (#35600) Make searchsorted*/findnext/findprev return values of keytype (#32978) fix buggy rand(RandomDevice(), Bool) (#35590) remove `Ref` allocation on task switch (#35606) Revert "partr: fix multiqueue resorting stability" (#35589) exclude types with free variables from `type_morespecific` (#35555) fix small typo in NEWS.md (#35611) enable inline allocation of structs with pointers (#34126) SparseArrays: Speed up right-division by diagonal matrices (#35533) Allow hashing 1D OffsetArrays NEWS item for introspection macros (#35594) Special case empty covec-diagonal-vec product (#35557) [GCChecker] fix a few tests by looking through casts Use norm instead of abs in generic lu factorization (#34575) [GCChecker,NFC] run clang-format -style=llvm [GCChecker] fix tests and add Makefile Add introspection macros support for dot syntax (#35522) Specialize `union` for `OneTo` (#35577) add pop!(vector, idx, [default]) (#35513) bump Pkg version (#35584) ...
From what I understand, this would close #14955, @JeffBezanson ? If so, I'd update the docs of UnsafeArrays, which I guess would then be largely obsolete when using Julia v1.5. This is exciting! |
Yes. Would be interesting to see how performance now compares with a non-trivial use of UnsafeArrays. |
And add load/store alignment annotations, because LLVM now prefers that we try to specify those explicitly, even though it's not required. This does not yet include correct load/store behaviors for objects with inlined references (the recent #34126 PR).
@JeffBezanson , it's not a very involved benchmark, but looks like the result is dramatic, in a very positive way: JuliaArrays/UnsafeArrays.jl#8 |
And add load/store alignment annotations, because LLVM now prefers that we try to specify those explicitly, even though it's not required. This does not yet include correct load/store behaviors for objects with inlined references (the recent #34126 PR).
And add load/store alignment annotations, because LLVM now prefers that we try to specify those explicitly, even though it's not required. This does not yet include correct load/store behaviors for objects with inlined references (the recent #34126 PR).
And add load/store alignment annotations, because LLVM now prefers that we try to specify those explicitly, even though it's not required. This does not yet include correct load/store behaviors for objects with inlined references (the recent #34126 PR).
And add load/store alignment annotations, because LLVM now prefers that we try to specify those explicitly, even though it's not required. This does not yet include correct load/store behaviors for objects with inlined references (the recent JuliaLang#34126 PR).
No description provided.