-
-
Notifications
You must be signed in to change notification settings - Fork 718
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
Include NumPy BLAS/LAPACK info in client.get_versions() #1827
Comments
I think it's reasonable to include more things. It's fairly cheap. We
might also keep get_versions as it is, but make a larger get_info function
that has a wider scope
…On Fri, Mar 9, 2018 at 2:14 PM, jakirkham ***@***.***> wrote:
At the risk of overloading client.get_versions() with info, it would be
handy to be able to check the NumPy BLAS/LAPACK linkage in here. This can
be really helpful when debugging a slow computation or a very strange
segfault that might be BLAS or LAPACK related. One way at this info is
numpy.__config__.show(), but that might be too heavy for
client.get_versions(). Open to other ways to include this info if there
are suggestions.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1827>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASszDqpRpSYbYb75M98Y4WC129gU6r4ks5tctSggaJpZM4SkvBu>
.
|
Where the task is largely about gathering information from workers, I was wondering if the right approach might be to modify Client.run() to be able to return values (or futures). Deciding what information to harvest from the workers would then be in the control of the clients, not reliant on changes to distributed. |
Yes, that's doable today from user-space and a fine solution. One reason by get_versions doesn't take this approach (it used to) is that it also gathers information from the scheduler, where we try to avoid depending on pickle. I suspect that in the future, using pickle may be turned off by default in the scheduler. |
Hi, I am first time contributing to open source. Can I wok on it? |
@lalitparate - yes, dask is a community driven open-source project. As such, anyone is welcome to work on anything. Let us know if you need help. |
Are we still aiming to show this worker linkage info in
Or should I build |
As others have commented, adding to |
Sure, thanks. May I ask what exactly do we want to show in |
Another question is how should we fit the various library linkage info into
|
@HsuanTingLu do you have thoughts on a more optimal layout ? |
No, I don't have one, so I'll probably add it anywhere you guys see fit. Back to the second question, how should the info be fitted into |
I am +1 on package::numpy. I understand this to mean something like:
Is that right ? |
Yeah something like this |
@HsuanTingLu do you still want to work on this? Did the comments from Ben answer all your questions? |
@GenevieveBuckley I have a few commits lying around, I think I'll need a few weeks to put them together |
Sounds great, thank you! |
At the risk of overloading
client.get_versions()
with info, it would be handy to be able to check the NumPy BLAS/LAPACK linkage in here. This can be really helpful when debugging a slow computation or a very strange segfault that might be BLAS or LAPACK related. One way at this info isnumpy.__config__.show()
, but that might be too heavy forclient.get_versions()
. Open to other ways to include this info if there are suggestions.The text was updated successfully, but these errors were encountered: