-
Notifications
You must be signed in to change notification settings - Fork 4
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
Implement low level accelerators for the GGCE backend #57
Comments
This is really important. Having optimized basis construction -- dare I say, even a parallelizable one?? -- would make our code fully scalable and enable us to do crazy things. |
Yeah it's not going to be straightforward though. I'm not super comfortable/familiar with building projects that are not pure Python. The good news is that whatever C++ code we use should be pure C++ plus pybind11 for the Python bindings, so we shouldn't have to worry about including a bunch of other header files or something. That said, I am not entirely sure yet how to properly build the wheels for everything we'd need. If you have any ideas I'm all ears. |
Same here, I am not too experienced with this at the moment. That said, I'd definitely be keen to learn more about Python-C++ integration, so I'd love to work on this together if you think that would be helpful! |
@Chiffafox your help on this would be amazing. Check out the new When we include C++ code for example, we will need to build that ( I am happy to write most of the C++ code (in fact we more or less already have a lot of it in GMA2 or whatever that old repo was), if you can help me figure out how to package it! |
This looks extremely promising as a way to do exactly what we want: https://github.com/pybind/python_example |
This is a major endeavor that will require a lot of work/thought. Essentially we want to do the following: Replace everything in
ggce.models
andggce.engine.system
with low level language accelerators. For example, by usingpybind11
as a submodule we should be able to create Python-importable binaries.As funny as it is, I think that the current solvers we use in NumPy, SciPy and (obviously) PETSc are faster than most of what we could try to get working in a lower level language! So for now, we can stick with those. But the steps of generating the basis are incredibly time-consuming and could be dramatically sped up.
This idea is still very much in the abstract but I want to document that we want to do it. I'm also closing #6 in favor of this, since this feature will do more than just generate the basis, it will also hook into the modules in e.g.
ggce.engine.terms
.The text was updated successfully, but these errors were encountered: