-
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
Removing @generated
functions
#66
Comments
Note that I tried to partially fix the length compilation times by minimizing the number of functions we need to use the |
Might be time to put some adult pants on and "just do it" by creating my own Here is
I believe we can just save all the exprs from user fums and splat them all into a big function at the end. I don't know if this will actually cut compile time, but it does...
So we have something like:
This was the original vision for the code.
|
Lots of notes to toss from Slack:
|
Right now, there is a mess of
@generated
functions inrun/fractal_flame.jl
. In principle, these can be removed by...ie, finding some way to iterate through known values with
ntuple
, like: https://github.com/CliMA/ClimateMachine.jl/blob/2e0b6b7d97719e410d12a8596c98d5db7f891dbf/src/Numerics/DGMethods/remainder.jl#L510I couldn't quite figure out how to go from the tuple of ints to an ntuple of vals.
The core issue is that LLVM cannot optimize on the tuple of functions because each function is a unique type, so it cannot be stored as an ntuple to begin with.
This discussion was introduced in #64
The text was updated successfully, but these errors were encountered: