-
Notifications
You must be signed in to change notification settings - Fork 1
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
Full automatic differentiation applications and gradient sharing #27
Comments
+1 |
+1 good point, a topic by itself! It maybe goes together with backends in general (yes, API is one but also JIT for example). |
+1 of course! There's certainly some blue sky thinking needed in order to determine what to do with the gradient information assuming we have it accessible. Most things have focused on a Just stirring the pot a bit, I have no good answers yet :) |
+1 I'm particularly interested in how to do this at scale, perhaps identifying where network or serialization bottlenecks may occur in developing such a system with where there might be checkpointing or the fitter (or some other thing interested in gradients) could be a distributed object in the network/cluster. |
+1 |
+1 Interested in general for MC generator applications. |
+1 |
This topic doesn't seem to be fully represented across any of the other Issues yet, though there are connections between it and:
As far as I understand in the ecosystem we don't really have the ability to fully use and share gradient information (with the notable exception of
neos
). pyhf uses automatic differentiation but this information is all internal, and not something that is currently accessible from outside of the calculation (again c.f. neos).I'm biased as this topic is something directly related to the IRIS-HEP Analysis Systems goals, but I would be very interested to know:
(Though he won't be able to attend in person (c.f. #5 (comment)) it would be useful to include @phinate in these discussions.)
The text was updated successfully, but these errors were encountered: