-
Notifications
You must be signed in to change notification settings - Fork 481
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
Speed has decreased #111
Comments
Thanks for report this, you are the second person who report it to me, another person report it to me in telegram. But is good to have this issue here to keep tracking it. Damn is not the first time that i did a mess with the speed, but this time i did not touch the speed counter. The only part that i change is the the related with the bPtable key generation and the bloomfitler multithread access in the previous version i have only one big bloom filter but in the new i made an array of 256 bloomfilters to speed up the multi-thread access. So letme check what is happening and i will try to correct it ASAP. Best regards! |
I just check with defaults values and yes there some decrement but in my case is not the half, is some 8 or 10 %
Can you paste here your test case? Best regards! |
It's strange, but I don't see such a speed difference right now. But I recreated the Bloom filter in the old and new versions. Thanks.
|
here are the speed compare with JLP bsgs. All are single thread. BSGS v1.2 Done: Total time 58s time ./keyhunt -m bsgs -t 1 -f tests/55.txt -r 60000000000000:80000000000000 -n 0x1000000000000 -s 0 real 2m0.006s I use same number baby steps(2^24) to test. |
Nice test, here we are talking about other problem but let me develop your test a little more BSGS has two things to test here, time in solve and memory usage. My program 2 Minutes and 73 MB of RAM and the JLP program 1 minute but 787 MB of RAM, if I use that amount of RAM the program will be 10 times faster with the data loaded from file, even only using 146 MB the program will be 2 times faster. Please considere this, an average user with 4 GB u 8 GB of RAM can get 10x times better speed with my code than the JLP code The code quite similar in some parts but different in others for example use a Bloomfilter and he use a Hashtable. That is why i add the option to save the precalculated data in a files to load it later and save time, with that option the time is very similar and the files can be use if you don't change the Baby Steps. With files i get 1m5.159s and i'm keep using the 73 MB of RAM
Using two times the current amount of RAM (~ 150 MB) and loading data from files only takes 30 seconds
Same amount of RAM of the JLP program (~725 MB) and loading data from files only takes 10 seconds
Internally my program use the same code that JLP but i do others things to get a better speed in the long run Best regards! |
Hi Albertobsd, |
Now i get what are you trying to say. well yes the difference form that time from one program to other is the bloom filter generation it take a little extra time generate it, that is where come from the extra time. But the speed is more o less the same with the same baby step proof of that is in the readme where is i run the same target of 16 publickeys in the JLP readme
A litlle lest time and half of the memory. Any way a think if we are getting something between 10 o 5 % less than the previous version, we still are getting 9x Times more speed than the keyhunt version from some 3 months ago, so i think this is OK. But please someone post replicable example from speed reduction of the 50% from the previous version of keyhunt and this one |
I just recover the 10% of lost speed. |
The problem could not be reproduced on other machines. Maybe it was something with the system or hardware in my case. Best regards! |
Off-topic question: |
No, you don't need to change the files, it is independent of the publickey, just if you change the n or k values the files are going to be created if you have the -S option |
Hi, @albertobsd !
|
Interesting i will open other issue about that problem, thanks for report it. By the way the last update solve your speed problem in bsgs mode? |
i think that this is solved now |
I can say to @albertobsd that on version012 I have speed around 800pkeys from 018 till now speed increases to 1,8Ekeys(same parameter) |
Same command but my output is a bit different. Could you explain this diff?, is there any change in speed ? Thank you
My output: [+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD real 2m0.252s |
Can you run the same command again? The last version remade some files so if you notice the b Points were processed again.
If youn run the same command again it will take less time, i guaranty that. |
The different is |
The new version use less memory |
Hi!
In the latest beta version 0.2.211012 in BGSG mode, the speed decreased exactly 2 times compared to version 0.2.211007. The command line is the same.
The text was updated successfully, but these errors were encountered: