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

Refactored version and efficiency #76

Open
jacobwilliams opened this issue Feb 10, 2024 · 4 comments
Open

Refactored version and efficiency #76

jacobwilliams opened this issue Feb 10, 2024 · 4 comments

Comments

@jacobwilliams
Copy link

FYI

I've refactored the Fortran code to modern standards, and you can find it here if you are interested: https://github.com/jacobwilliams/radbelt

Your Python version is very inefficient, I believe because it is reading all the data files every time the get_flux function is called? Unless I'm reading it wrong or calling it incorrectly. See my test case.

Compare to my refactored version:

Python version runtime:           3.514 sec.     409 (cases/sec) <-- reading the files every time
Fortran Function version runtime: 1.622 sec.    1198 (cases/sec) <-- reading the files every time
Fortran Class version runtime:    0.017 sec.  112259 (cases/sec) <-- caching the data from the files

The class version of mine will only read the files once, and store the data in the class so that subsequent calls don't have to read it again. That results in a huge speedup. Something like that could be implemented for the Python wrapper I believe.

@lpsinger
Copy link
Contributor

That's great. Yes, I was aware of this inefficiency; I know C and Python (among other languages) but I don't know enough Fortran to have undertaken that kind of surgery on the code. Will your fpm package build and install a shared library? If so then I should be able to wrap it with Python straightforwardly and replace the crap that I have here.

@jacobwilliams
Copy link
Author

yeah I'm using my fork as an experiment to learn about f2py and how to wrap modern fortran. work in progress.

@lpsinger
Copy link
Contributor

@jacobwilliams, I think that I can wrap what you have. If I do it in a clean-room manner I can release a new Python wrapper under more favorable terms for third-party contribution. Are you planning to do a release of your fpm package in the near future?

@jacobwilliams
Copy link
Author

Feel free to use it or get whatever inspiration you need from it. Sure, I'll probably release it as an FPM package at some point.

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