Skip to content
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

Allow a caching object that can cache specific entries #815

Open
zerothi opened this issue Aug 1, 2024 · 6 comments
Open

Allow a caching object that can cache specific entries #815

zerothi opened this issue Aug 1, 2024 · 6 comments

Comments

@zerothi
Copy link
Owner

zerothi commented Aug 1, 2024

Describe the feature

Example.

Once a State has been created with a parent, we might
as well turn it into a cached object, which when calling specific
methods it returns the objects needed fast. Typically users
won't be storing all k-point's eigenstates, and thus one could
get free performance by allowing users to do this:

es = H.eigenstate()
es.velocity() # calls es.parent.dHk()
es.derivative() # calls es.parent.dHk(), again with same arguments.

However, there are some things that shouldn't be cached. For instance
it does not make sense to cache the geometry or sub commands.
So how do we selectively decide which methods to cache, do we need to mark them as "cacheable"?

@pfebrer
Copy link
Contributor

pfebrer commented Aug 1, 2024

Nodes could work nicely for this 🙄

@zerothi
Copy link
Owner Author

zerothi commented Aug 1, 2024

Nodes could work nicely for this 🙄

Ah yeah, good idea! 🚀

What is the overhead here? And can you tell it to not do it all-over? Only on return values?

Seems like an ideal place to start...! :)

@pfebrer
Copy link
Contributor

pfebrer commented Aug 1, 2024

By not all-over you mean that the nodes should not store the inputs?

@zerothi
Copy link
Owner Author

zerothi commented Aug 1, 2024

I seem to recall your nodes would traverse ast, and take everything, what we only want is the inputs, and the output, all in between shouldn't be nodified.

@pfebrer
Copy link
Contributor

pfebrer commented Aug 1, 2024

Nooo, there are two things:

If you convert a function into a node, then the node is simply a wrapper over the function to make the function (optionally) lazy and (optionally) cache the return value based on the inputs, as well as being able to connect it with other nodes so that an update (optionally) flows down the connected nodes.

If you convert it into a workflow, then the function is split into nodes (not recursively, just one level up the stack).

So what we would want here is simply to convert the functions to nodes, so that we can connect the output of dHk() to multiple inputs. To keep exactly the same interface that we have now I think we would need to hide the nodes from the user, but I'm not sure.

@zerothi
Copy link
Owner Author

zerothi commented Aug 2, 2024

nice, I'll play with this soon! Sounds like a perfect fit here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants