-
Notifications
You must be signed in to change notification settings - Fork 102
Add missing parallel=:threads
implementations
#429
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
base: master
Are you sure you want to change the base?
Add missing parallel=:threads
implementations
#429
Conversation
What is the issue with using |
Multithreading typically has lower overhead since it's shared memory. Distributed is usually only worthwhile if you are trying to distribute across multiple machines. |
Also, Distributed is a stdlib, but stdlibs are still dependencies, and as we have started moving stlibs out of the sysimage, they are becoming more like regular packages. |
b5b55a0
to
c109686
Compare
Would this require also bumping the minimum requirement to julia=1.9? I am generally in favor of moving more dependencies to optional dependencies. It makes compilation times much more pleasant as well. |
2e9b9f3
to
a7db672
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #429 +/- ##
==========================================
+ Coverage 97.31% 97.38% +0.07%
==========================================
Files 117 120 +3
Lines 6956 7007 +51
==========================================
+ Hits 6769 6824 +55
+ Misses 187 183 -4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
fc4a1b9
to
cbda59e
Compare
There are compatibility pathways where we only switch to an extension on 1.9+ and keep the hard dependency for earlier versions I think this PR should be ready for review now - it is passing tests for me locally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but I am a bit new to the maintainer team, and this does introduce a new public feature (the parallel
kwarg), so I will wait a bit for dissent from folks with more seniority.
FWIW, that kwarg is already there on a lot of other methods, so it's not a new design choice exactly - it was just never provided for these particular operations (because they only had a |
There is some new multi threaded code here - so we probably should take a bit of time to review it - as it can lead to notoriously difficult to spot bugs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks mostly good to me. I don't see any race condition
I have added some comments. They are mostly suggestions. In addition:
- We probably should write some documentation for the new
parallel
argument. Although I admit that this module is fairly undocumented anyway - and as we don't export anything yet we don't have to be so rigorous.
a99a063
to
5575b3a
Compare
These implementations are extremely basic, but they try to follow the patterns in the other parts of the Parallel module. My real motivation is to be able to move the Distributed implementations into an extension, so that Graphs.jl does not depend on Distributed.
5575b3a
to
d8a8730
Compare
Base.Threads.@threads for i in 1:vlen | ||
d = Graphs.dijkstra_shortest_paths(g, vs[i], distmx) | ||
eccs[i] = maximum(d.dists) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit weird that the end
is not covered by the tests - the code inside the loop is, right? If it is indeed then we might just merge it anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That has been a common issue for me with macro-transformed begin-end
blocks. I have never bothered delving into why it is happening though. Macro-heavy libraries like ResumableFunctions.jl
and ConcurrentSim.jl
suffer from that (and from other more severe macro-covereage issues).
The PR Pre-Commit Bot failure is a problem with the github action, not this PR. (Probably due to this coming from a fork -- I will look into fixing the action) |
Anything else needed from me here? |
These implementations are basic, but I tried to follow the patterns in the other parts of the Parallel module.
My real motivation is to be able to move the Distributed implementations into an extension, so that Graphs.jl does not depend on Distributed.