-snip-
-Slight performance increase (compressed key only) GPU
-snip-
-Slight performance increase (compressed key only) GPU
-snip-
What was the main reason for performance increase?
Topic: VanitySearch (Yet another address prefix finder) - page 36. (Read 32072 times)
What was the main reason for performance increase?
Hi there,
A new release is available (1.17):
-Slight performance increase (compressed key only) GPU
-Fixed counting bug for large grid size
Thanks to test it
Have fun
A new release is available (1.17):
-Slight performance increase (compressed key only) GPU
-Fixed counting bug for large grid size
Thanks to test it
Have fun
please tell me how to run on radeon rx 570?
Hi there,
A new release is available (1.17):
-Slight performance increase (compressed key only) GPU
-Fixed counting bug for large grid size
Thanks to test it
Have fun
A new release is available (1.17):
-Slight performance increase (compressed key only) GPU
-Fixed counting bug for large grid size
Thanks to test it
Have fun
@Jean_Luc , btw..
yeah I can search all keys in 3 days
this is with 1.16
Vanitysearch.exe -b -t 0 -gpu -gpuId 0,1 -g 1088,512,1088,512 -r 10000000 -o found_0.txt -i in.txt
[4544125350086.37 Mkey/s][GPU 4544125350086.37 Mkey/s][Total 2^64.00][Prob 0.0%][50% in 7.06916e+21y][Found 0]
544,512,544,512 still shows korrekt MKeys
yeah I can search all keys in 3 days
this is with 1.16
Vanitysearch.exe -b -t 0 -gpu -gpuId 0,1 -g 1088,512,1088,512 -r 10000000 -o found_0.txt -i in.txt
[4544125350086.37 Mkey/s][GPU 4544125350086.37 Mkey/s][Total 2^64.00][Prob 0.0%][50% in 7.06916e+21y][Found 0]
544,512,544,512 still shows korrekt MKeys
just a bug.. its showing 45000 Trillion Key per second
lol
What a grid size !
Seems an integer overflow.
If you manage to compile, could you try to change:
Vanity.cpp: 1565
counters[thId] += 6 * STEP_SIZE * nbThread; // Point + endo1 + endo2 + symetrics
by
counters[thId] += 6ULL * STEP_SIZE * nbThread; // Point + endo1 + endo2 + symetrics
This should be enough.
What a grid size !
Seems an integer overflow.
If you manage to compile, could you try to change:
Vanity.cpp: 1565
counters[thId] += 6 * STEP_SIZE * nbThread; // Point + endo1 + endo2 + symetrics
by
counters[thId] += 6ULL * STEP_SIZE * nbThread; // Point + endo1 + endo2 + symetrics
This should be enough.
@Jean_Luc , btw..
yeah I can search all keys in 3 days
this is with 1.16
Vanitysearch.exe -b -t 0 -gpu -gpuId 0,1 -g 1088,512,1088,512 -r 10000000 -o found_0.txt -i in.txt
[4544125350086.37 Mkey/s][GPU 4544125350086.37 Mkey/s][Total 2^64.00][Prob 0.0%][50% in 7.06916e+21y][Found 0]
544,512,544,512 still shows korrekt MKeys
yeah I can search all keys in 3 days
this is with 1.16
Vanitysearch.exe -b -t 0 -gpu -gpuId 0,1 -g 1088,512,1088,512 -r 10000000 -o found_0.txt -i in.txt
[4544125350086.37 Mkey/s][GPU 4544125350086.37 Mkey/s][Total 2^64.00][Prob 0.0%][50% in 7.06916e+21y][Found 0]
544,512,544,512 still shows korrekt MKeys
@Jean_Luc
no, 1.15 and 1.16 both do NOT work.. same error when loading lists..
will try with your exe though.. one moment...
what the hell.. im not getting errors on 5 or 6 when using your exe.. could only test for a minute though.. sometimes it took longer to crash
is my compile env gone haywire? I compiled 5 and a few days later 6 with VS19 and only changed the target to my cuda 10.2 env.. was there some change from 10.0?
(ps: no, no compile errors or anything.. just straight forward..)
... will test tonight...
no, 1.15 and 1.16 both do NOT work.. same error when loading lists..
will try with your exe though.. one moment...
what the hell.. im not getting errors on 5 or 6 when using your exe.. could only test for a minute though.. sometimes it took longer to crash
is my compile env gone haywire? I compiled 5 and a few days later 6 with VS19 and only changed the target to my cuda 10.2 env.. was there some change from 10.0?
(ps: no, no compile errors or anything.. just straight forward..)
... will test tonight...
There is only few changes since the 1.14.
Does the 1.15 works also ?
I can imagine that a bug has been introduced with the dynamic grid size in 1.16 but in 1.15 there is only a change that concern P2SH and BECH32 addresses...
You can show changes by looking there:
https://github.com/JeanLucPons/VanitySearch/releases
Does the 1.15 works also ?
I can imagine that a bug has been introduced with the dynamic grid size in 1.16 but in 1.15 there is only a change that concern P2SH and BECH32 addresses...
You can show changes by looking there:
https://github.com/JeanLucPons/VanitySearch/releases
@Jean_Luc , you are right, 1.14 is working fine... do you have an actual changelog somewhere?
So do you think that the standard 18.04 distro will work for GPU? Or would I need to install some specific CUDA software for 18.04?
I think it will work but effectively you may need to install specific CUDA software.
My impression is that 18.04 is required for Vanity Search.
I don't kwon, I'm using ubuntu 18.04.2 LTS with an old quadro and it is working well except that I had to repatch again the cuda driver in order to make it work (quite a nightmare) following a kernel update. Kernel maintainers has again beautified the code breaking the backward compatibility by removing and changing some kernel functions. pfff....
So do you think that the standard 18.04 distro will work for GPU? Or would I need to install some specific CUDA software for 18.04?
I know it works for CPU (as long as you install g++).
My impression is that 18.04 is required for Vanity Search.
I don't kwon, I'm using ubuntu 18.04.2 LTS with an old quadro and it is working well except that I had to repatch again the cuda driver in order to make it work (quite a nightmare) following a kernel update. Kernel maintainers has again beautified the code breaking the backward compatibility by removing and changing some kernel functions. pfff....
In terms of GPU:
My impression is that 18.04 is required for Vanity Search. Is there a particular model of NVIDIA / CUDA that you (or anyone) would recommend?
From the NVIDIA site the options for Ubuntu 18.04 are:
10.2-base, 10.2-base-ubuntu18.04 (10.2/base/Dockerfile)
10.2-runtime, 10.2-runtime-ubuntu18.04 (10.2/runtime/Dockerfile)
10.2-cudnn7-runtime, 10.2-cudnn7-runtime-ubuntu18.04 (10.2/runtime/cudnn7/Dockerfile)
latest,
10.2-devel, 10.2-devel-ubuntu18.04 (10.2/devel/Dockerfile)
10.2-cudnn7-devel, 10.2-cudnn7-devel-ubuntu18.04 (10.2/devel/cudnn7/Dockerfile)
Thanks - again!
My impression is that 18.04 is required for Vanity Search. Is there a particular model of NVIDIA / CUDA that you (or anyone) would recommend?
From the NVIDIA site the options for Ubuntu 18.04 are:
10.2-base, 10.2-base-ubuntu18.04 (10.2/base/Dockerfile)
10.2-runtime, 10.2-runtime-ubuntu18.04 (10.2/runtime/Dockerfile)
10.2-cudnn7-runtime, 10.2-cudnn7-runtime-ubuntu18.04 (10.2/runtime/cudnn7/Dockerfile)
latest,
10.2-devel, 10.2-devel-ubuntu18.04 (10.2/devel/Dockerfile)
10.2-cudnn7-devel, 10.2-cudnn7-devel-ubuntu18.04 (10.2/devel/cudnn7/Dockerfile)
Thanks - again!
How do I configure the -g option? Tell us more.
Tell us more.By default VanitySearch takes 8*(MP number),128 for the grid size.
You can set it up using -g (you need the last release for setting 2D grid size)
ex:
VanitySearch.exe -t 0 -gpu -g 48,256 1TestMe (with a single GPU)
VanitySearch.exe -t 0 -gpu -gpuId 0,1 -g 48,256,64,512 1TestMe (with 2 GPU)
It is good to take the first value as a multiple of the multiprocessor count and the second as a power of 2.
The number of multiprocessor is given with:
VanitySearch.exe -l
GPU #0 GeForce GTX 645 (3x192 cores) (Cap 3.0) (1024.0 MB) (Multiple host threads)
Here 3 is the number of multiprocessor.
If you are using a GPU, play a bit with the -g option in order to adjust your grid size for best performance.
Yes the input file is just a list of prefix to search.
Ex:
People who use hundreds (even millions) of entries likely search for full addresses.
How do I configure the -g option? Yes the input file is just a list of prefix to search.
Ex:
Code:
1Pierre
1PauL
1Jacques
1PauL
1Jacques
People who use hundreds (even millions) of entries likely search for full addresses.
Tell us more.
Hey
@Jean_Luc
I tried my own (new) 2080 Ti.. the same...
@all:
is there anyone with a 2080 Ti or two where this is working with address lists?
@Jean_Luc
I tried my own (new) 2080 Ti.. the same...
@all:
is there anyone with a 2080 Ti or two where this is working with address lists?
If you are using a GPU, play a bit with the -g option in order to adjust your grid size for best performance.
Yes the input file is just a list of prefix to search.
Ex:
People who use hundreds (even millions) of entries likely search for full addresses.
Yes the input file is just a list of prefix to search.
Ex:
Code:
1Pierre
1PauL
1Jacques
1PauL
1Jacques
People who use hundreds (even millions) of entries likely search for full addresses.
Thanks - I'm trying this now.
That seems much quicker!
If you are using a GPU, play a bit with the -g option in order to adjust your grid size for best performance.
Yes the input file is just a list of prefix to search.
Ex:
People who use hundreds (even millions) of entries likely search for full addresses.
Yes the input file is just a list of prefix to search.
Ex:
Code:
1Pierre
1PauL
1Jacques
1PauL
1Jacques
People who use hundreds (even millions) of entries likely search for full addresses.
What are the best options to use for maximum Mkeys/s output?
I assume that -u (search uncompressed addresses) is quicker than -b (search compressed and uncompressed addresses).
For -i (the input file) - I'm unclear about what's in that file. Is it just a list of prefixes you want e.g:
1abc
1def
1ghi
...
Or something else? I see people using input files with hundreds of lines but they don't post the content of those input files.
Can someone give an example, please?
I assume that -u (search uncompressed addresses) is quicker than -b (search compressed and uncompressed addresses).
For -i (the input file) - I'm unclear about what's in that file. Is it just a list of prefixes you want e.g:
1abc
1def
1ghi
...
Or something else? I see people using input files with hundreds of lines but they don't post the content of those input files.
Can someone give an example, please?
This is not exactly the answer to my question - "Is there a number that creates a range that makes up 100% of the pool in which the prefix is located?"
However, thanks for the calculation and explanation.
What the case looks like in case of difficulties 10054102514374868992
What percentage does this number specify? (I can't find an effective calculation method myself)
However, thanks for the calculation and explanation.
What the case looks like in case of difficulties 10054102514374868992
What percentage does this number specify? (I can't find an effective calculation method myself)
I'm not sure to fully understand the question.
If I understand well, there is no way to define a group with a specific size where you are 100% sure that a given prefix is located because addresses are randomly distributed. As said in above posts, the difficulty give the probability to hit a particular prefix after 1 try, nothing more...
63% means that if you make 173346595075428800 tries, you will have 63% of chance to find the desired prefix.
So explaining in the simplest understandable way:
115792089237316195423570985008687907852837564279074904382605163141518161494336 - the size of the entire BTC range
173346595075428800 means as if every "173346595075428800" of spaces appears the prefix searched, but they are not evenly distributed across the full range (i.e. that I can search 10x the whole "173346595075428800" without finding the solution, and searching the 11th range I will find solutions eleven)?
Yes!
Jump to: