-
Notifications
You must be signed in to change notification settings - Fork 87
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
Mining refactor with new features #37
base: main
Are you sure you want to change the base?
Conversation
@armstrys can you (or anyone else) drop in some rough performance calcs here? i.e. "hashes" (guesses) per second. I had been working on my own vanity key brute forcing library in python, but completely abandoned it once I saw rana's performance. My M1 Macbook Pro was doing something like 1 mil guesses in two minutes in python. By running multiple instances I could hit maybe 6x that. Rana is hitting 340k per second! I think it probably makes more sense to try to write python bindings for rana's Rust code and PR into rana whatever mods that might require. |
If you pull this branch you should be able to run I suspect you’re right that investigating python bindings to another solution might make more sense here! I hadn’t thought of that. |
So for vanity gen it's about 34x slower than rana -- but that's with rana using all 8 cores. If we manually run 8 instances of python and assume no performance loss per thread (more or less true based on my earlier testing with my own python vanity gen), we roughly cut that to rana being somewhere around 4x faster. |
This is a rather large PR that I fully expect to be reworked, but wanted to share because I think it adds some useful features. I've tried to break the commits up into logical steps so we can choose to only apply a subset if needed.
mine_vanity_key
intopow.py
to avoid circular imports when adding other features