Pages:
Author

Topic: Pollard's kangaroo ECDLP solver - page 2. (Read 54285 times)

newbie
Activity: 1
Merit: 0
March 22, 2024, 08:06:46 PM
I probably miss something here, but please explain why do you guys use Kangaroo while there is another tool Keyhunt, which BSGS option is very very fast. With above average hardware, you can get around 10 exa keys per second. That is 10,000,000,000,000,000,000 keys per second.  I have never seen such numbers with Kangaroo.

I have been testing keyhunt and the conclusion is that its speed is very fast within a small range. For example, with a 45 bit interval, 8GB of memory is much faster than 1060 speed. However, once it reaches a high level, the efficiency of keyhunt is relatively low. Currently, I am testing with 128GB of memory, and the speed has reached 2Ekey/s. However, it is obvious that these speeds are negligible in such a huge space, so I prefer kangaroo high search. I am still testing more kangaroo conclusions. Thank you and greetings


Well, sir, if our luck is high, is there a possibility that we can find it with a bad graphics card by using the Kangaroo program?
It is obvious that Kangaroo and Keyhunt each have their own strengths. As far as I know, the Kangaroo program GPU cannot be used for multiple public keys and has a limit of 125 bit intervals. Therefore, Kangaroo is currently only used as a puzzle solver. Keyhunt does not use GPU, but it can be tested in the full range space and under multiple public keys simultaneously, although its efficiency is not high when running at high bits. If kangaroos can support full range and multiple public keys, then undoubtedly it will be the most suitable. Also, I come from China and the translator may not be accurate. I apologize!
full member
Activity: 1022
Merit: 217
Shooters Shoot...
March 22, 2024, 04:33:43 PM
It will be nice to know from this program developer if kangaroo can work with 128-bit range?
Or it absolute maximum 125-bit as stated in the readme?
So, splitting in half #130 puzzle will help? It will be exactly two 128-bit ranges then.
Thanks.

I'm waiting for the answer to this question, but no one can say anything definitive. It is necessary to find the person who made this program.
Does this program work with more than 125 BIT RANGE?
It has been answered multiple times, please read.

Again, on JLPs github (the person who built this program)

Quote
#130
Expected time: several years on 256 Tesla V100 (Not possible with this program without modification)
newbie
Activity: 9
Merit: 0
March 22, 2024, 12:31:56 PM
It will be nice to know from this program developer if kangaroo can work with 128-bit range?
Or it absolute maximum 125-bit as stated in the readme?
So, splitting in half #130 puzzle will help? It will be exactly two 128-bit ranges then.
Thanks.

I'm waiting for the answer to this question, but no one can say anything definitive. It is necessary to find the person who made this program.
Does this program work with more than 125 BIT RANGE?
newbie
Activity: 35
Merit: 0
March 22, 2024, 11:32:26 AM
It will be nice to know from this program developer if kangaroo can work with 128-bit range?
Or it absolute maximum 125-bit as stated in the readme?
So, splitting in half #130 puzzle will help? It will be exactly two 128-bit ranges then.
Thanks.
newbie
Activity: 9
Merit: 0
March 22, 2024, 01:39:08 AM
I probably miss something here, but please explain why do you guys use Kangaroo while there is another tool Keyhunt, which BSGS option is very very fast. With above average hardware, you can get around 10 exa keys per second. That is 10,000,000,000,000,000,000 keys per second.  I have never seen such numbers with Kangaroo.

I have been testing keyhunt and the conclusion is that its speed is very fast within a small range. For example, with a 45 bit interval, 8GB of memory is much faster than 1060 speed. However, once it reaches a high level, the efficiency of keyhunt is relatively low. Currently, I am testing with 128GB of memory, and the speed has reached 2Ekey/s. However, it is obvious that these speeds are negligible in such a huge space, so I prefer kangaroo high search. I am still testing more kangaroo conclusions. Thank you and greetings


Well, sir, if our luck is high, is there a possibility that we can find it with a bad graphics card by using the Kangaroo program?



Is JLP's Kangaroo program used for puzzle 130, which is original and published on github? Yes or no ?

Some said you can use it because the range width is 125 bits. Some have said that the original version of JLP has 130 puzzles and you cannot use it for more comprehensive puzzles.

Which one is right ?


What I'm talking about is the 130 bit range width, that is, if there is more than a 125 bit gap between the start and end, does the program work?

Mod note: consecutive posts merged
newbie
Activity: 1
Merit: 0
March 21, 2024, 10:32:04 PM
I probably miss something here, but please explain why do you guys use Kangaroo while there is another tool Keyhunt, which BSGS option is very very fast. With above average hardware, you can get around 10 exa keys per second. That is 10,000,000,000,000,000,000 keys per second.  I have never seen such numbers with Kangaroo.

I have been testing keyhunt and the conclusion is that its speed is very fast within a small range. For example, with a 45 bit interval, 8GB of memory is much faster than 1060 speed. However, once it reaches a high level, the efficiency of keyhunt is relatively low. Currently, I am testing with 128GB of memory, and the speed has reached 2Ekey/s. However, it is obvious that these speeds are negligible in such a huge space, so I prefer kangaroo high search. I am still testing more kangaroo conclusions. Thank you and greetings
full member
Activity: 1022
Merit: 217
Shooters Shoot...
March 21, 2024, 05:02:27 PM
What say you now?

The JLP, unmodded, kangaroo program, will not work for all the remaining ranges.

Now you’ll have everyone using it and wind up disappointed 😔

Code:
#ifdef USE_SYMMETRY
  int jumpBit = rangePower / 2;
#else
  int jumpBit = rangePower / 2 + 1;
#endif

  if(jumpBit > 128) jumpBit = 128;
  int maxRetry = 100;
  bool ok = false;
  double distAvg;
  double maxAvg = pow(2.0,(double)jumpBit - 0.95);
  double minAvg = pow(2.0,(double)jumpBit - 1.05);
  //::printf("Jump Avg distance min: 2^%.2f\n",log2(minAvg));
  //::printf("Jump Avg distance max: 2^%.2f\n",log2(maxAvg));
 
  // Kangaroo jumps
  // Constant seed for compatibilty of workfiles
  rseed(0x600DCAFE);

you have max setup : 128 bit as jumpBit if more  if(jumpBit > 128) jumpBit = 128;

As JLP says:
Quote
This program is limited to a 125bit interval search.

interval search not means the range of privatekey but diff beetween start and end of privatekey.


Start range
End range
Key #1
Key #2

max different end_range-start_range < 2**128

have fun!


Ahhhh, now go and look at how the hash table is built/what goes into it. I’ll give you a hint, as I’ve said all along, 128 bits max, for points and distances.

So no people, don’t use it unless you want headaches and possible heartbreaks 😁

Code:

ENTRY *HashTable::CreateEntry(int128_t *x,int128_t *d) {


Now on JLPs Kangaroo GitHub repository:

Quote
Expected time: several years on 256 Tesla V100 (Not possible with this program without modification)
hero member
Activity: 630
Merit: 649
Bitcoin g33k
March 21, 2024, 03:28:33 PM
What say you now?

The JLP, unmodded, kangaroo program, will not work for all the remaining ranges.

Now you’ll have everyone using it and wind up disappointed 😔

Code:
#ifdef USE_SYMMETRY
  int jumpBit = rangePower / 2;
#else
  int jumpBit = rangePower / 2 + 1;
#endif

  if(jumpBit > 128) jumpBit = 128;
  int maxRetry = 100;
  bool ok = false;
  double distAvg;
  double maxAvg = pow(2.0,(double)jumpBit - 0.95);
  double minAvg = pow(2.0,(double)jumpBit - 1.05);
  //::printf("Jump Avg distance min: 2^%.2f\n",log2(minAvg));
  //::printf("Jump Avg distance max: 2^%.2f\n",log2(maxAvg));
 
  // Kangaroo jumps
  // Constant seed for compatibilty of workfiles
  rseed(0x600DCAFE);

you have max setup : 128 bit as jumpBit if more  if(jumpBit > 128) jumpBit = 128;

As JLP says:
Quote
This program is limited to a 125bit interval search.

interval search not means the range of privatekey but diff beetween start and end of privatekey.


Start range
End range
Key #1
Key #2

max different end_range-start_range < 2**128

have fun!
full member
Activity: 1022
Merit: 217
Shooters Shoot...
March 21, 2024, 03:11:38 PM
i've been reading this thread since last week till now and I don't find the answer

so if the program is limited to 125bit interval, ...

This is a false statement which is not true. Kangaroo is not limited to 125bit ranges. It works fine with all ranges intended for this little game-


What say you now?

The JLP, unmodded, kangaroo program, will not work for all the remaining ranges.

Now you’ll have everyone using it and wind up disappointed 😔
hero member
Activity: 630
Merit: 649
Bitcoin g33k
March 21, 2024, 02:52:20 PM
i've been reading this thread since last week till now and I don't find the answer

so if the program is limited to 125bit interval, ...

This is a false statement which is not true. Kangaroo is not limited to 125bit ranges. It works fine with all ranges intended for this little game-
full member
Activity: 1022
Merit: 217
Shooters Shoot...
March 21, 2024, 01:59:48 PM
yes please make open source, just like original was open source to benefit you, please help us

Can you make public your modded version of JLP's kangaroo?


So I still believe it could solve 130 and then you would have to do some manual math (nothing hard) to get the actual private key. If the key starts with a 2, I think it would not require the manual math, but if it starts with a 3, then it will.
You can't because GPU uses only 128 bit variable to store distance on each kernel call, it means that when kangaroo jumps out of 128 bit space, all subsequent jumps are calculated incorrectly.

130 puzzle still can be solved with unmodified JLP's kangaroo if you divide 129 bit space into two 128 bits parts, but kangaroos still can jumps out, so you have to control the wrong DPs.


Are you sure? When I tested many moons ago, if I ran a higher range than 128 (b/c hash table only stores 32 hex characters for point and distance (32x4 = 128)), the distances and points were correct, but obviously the leading characters were left out/off because of the 128 bit max storage.

I may have to run again and retest, and extract the hash table....I will check it now.

Update:

It is as how I remembered it. I just ran a super quick test for the 130 bit range. As you know, the program subtracts starting range so we are working with 0 thru 1ffffff.....(129 bit range)
Here is extracted DP, DP of 20:

178559a1004e94449e90d76ca10b3600 26311140a6e43a1530526461aed458e4

On the surface, if you just plugged in 26311140a6e43a1530526461aed458e4, it seems false, but we know that the only other possible number that could be added in front is a 1, so add a 1 to 26311140a6e43a1530526461aed458e4 and you get 126311140a6e43a1530526461aed458e4, now cross reference that distance and you get this point:
0300000B71D19F5FCD4AC6184EDE7C000C178559A1004E94449E90D76CA10B3600
which matches up to:
178559a1004e94449e90d76ca10b3600
178559A1004E94449E90D76CA10B3600

So that is what I mean by doing some manual work if you use JLPs unmodded version and find a collision in the 130 bit range. But if you go up to 135, it gets a little more tricky/complicated.

But you could be correct! Maybe I didn't let the program run long enough to see how any subsequent keys would be handled.

Honestly, I wouldn't use the unmodded version, nor the 256 bit one on github (doesn't work).

To be safe, use Etayson's Kangaroo on github or mod your own version. That's the safer bet.

I do not have a modded version of JLPs.

Peeps, listen up lol, use Etayson EtarKangaroo on github. Then you don't have to worry about all the tomfoolery.
jr. member
Activity: 71
Merit: 2
March 21, 2024, 09:02:09 AM
Can you make public your modded version of JLP's kangaroo?


So I still believe it could solve 130 and then you would have to do some manual math (nothing hard) to get the actual private key. If the key starts with a 2, I think it would not require the manual math, but if it starts with a 3, then it will.
You can't because GPU uses only 128 bit variable to store distance on each kernel call, it means that when kangaroo jumps out of 128 bit space, all subsequent jumps are calculated incorrectly.

130 puzzle still can be solved with unmodified JLP's kangaroo if you divide 129 bit space into two 128 bits parts, but kangaroos still can jumps out, so you have to control the wrong DPs.


Are you sure? When I tested many moons ago, if I ran a higher range than 128 (b/c hash table only stores 32 hex characters for point and distance (32x4 = 128)), the distances and points were correct, but obviously the leading characters were left out/off because of the 128 bit max storage.

I may have to run again and retest, and extract the hash table....I will check it now.

Update:

It is as how I remembered it. I just ran a super quick test for the 130 bit range. As you know, the program subtracts starting range so we are working with 0 thru 1ffffff.....(129 bit range)
Here is extracted DP, DP of 20:

178559a1004e94449e90d76ca10b3600 26311140a6e43a1530526461aed458e4

On the surface, if you just plugged in 26311140a6e43a1530526461aed458e4, it seems false, but we know that the only other possible number that could be added in front is a 1, so add a 1 to 26311140a6e43a1530526461aed458e4 and you get 126311140a6e43a1530526461aed458e4, now cross reference that distance and you get this point:
0300000B71D19F5FCD4AC6184EDE7C000C178559A1004E94449E90D76CA10B3600
which matches up to:
178559a1004e94449e90d76ca10b3600
178559A1004E94449E90D76CA10B3600

So that is what I mean by doing some manual work if you use JLPs unmodded version and find a collision in the 130 bit range. But if you go up to 135, it gets a little more tricky/complicated.

But you could be correct! Maybe I didn't let the program run long enough to see how any subsequent keys would be handled.

Honestly, I wouldn't use the unmodded version, nor the 256 bit one on github (doesn't work).

To be safe, use Etayson's Kangaroo on github or mod your own version. That's the safer bet.

i don't know how to mod so this is not option for me

i can break into 2 parts and run on different rigs - thats what i thought at beginning, but how do i control the wrong DPs?



So I still believe it could solve 130 and then you would have to do some manual math (nothing hard) to get the actual private key. If the key starts with a 2, I think it would not require the manual math, but if it starts with a 3, then it will.
You can't because GPU uses only 128 bit variable to store distance on each kernel call, it means that when kangaroo jumps out of 128 bit space, all subsequent jumps are calculated incorrectly.

130 puzzle still can be solved with unmodified JLP's kangaroo if you divide 129 bit space into two 128 bits parts, but kangaroos still can jumps out, so you have to control the wrong DPs.


yes please make open source, just like original was open source to benefit you, please help us

Can you make public your modded version of JLP's kangaroo?


So I still believe it could solve 130 and then you would have to do some manual math (nothing hard) to get the actual private key. If the key starts with a 2, I think it would not require the manual math, but if it starts with a 3, then it will.
You can't because GPU uses only 128 bit variable to store distance on each kernel call, it means that when kangaroo jumps out of 128 bit space, all subsequent jumps are calculated incorrectly.

130 puzzle still can be solved with unmodified JLP's kangaroo if you divide 129 bit space into two 128 bits parts, but kangaroos still can jumps out, so you have to control the wrong DPs.


Are you sure? When I tested many moons ago, if I ran a higher range than 128 (b/c hash table only stores 32 hex characters for point and distance (32x4 = 128)), the distances and points were correct, but obviously the leading characters were left out/off because of the 128 bit max storage.

I may have to run again and retest, and extract the hash table....I will check it now.

Update:

It is as how I remembered it. I just ran a super quick test for the 130 bit range. As you know, the program subtracts starting range so we are working with 0 thru 1ffffff.....(129 bit range)
Here is extracted DP, DP of 20:

178559a1004e94449e90d76ca10b3600 26311140a6e43a1530526461aed458e4

On the surface, if you just plugged in 26311140a6e43a1530526461aed458e4, it seems false, but we know that the only other possible number that could be added in front is a 1, so add a 1 to 26311140a6e43a1530526461aed458e4 and you get 126311140a6e43a1530526461aed458e4, now cross reference that distance and you get this point:
0300000B71D19F5FCD4AC6184EDE7C000C178559A1004E94449E90D76CA10B3600
which matches up to:
178559a1004e94449e90d76ca10b3600
178559A1004E94449E90D76CA10B3600

So that is what I mean by doing some manual work if you use JLPs unmodded version and find a collision in the 130 bit range. But if you go up to 135, it gets a little more tricky/complicated.

But you could be correct! Maybe I didn't let the program run long enough to see how any subsequent keys would be handled.

Honestly, I wouldn't use the unmodded version, nor the 256 bit one on github (doesn't work).

To be safe, use Etayson's Kangaroo on github or mod your own version. That's the safer bet.
full member
Activity: 1022
Merit: 217
Shooters Shoot...
March 21, 2024, 01:33:53 AM
So I still believe it could solve 130 and then you would have to do some manual math (nothing hard) to get the actual private key. If the key starts with a 2, I think it would not require the manual math, but if it starts with a 3, then it will.
You can't because GPU uses only 128 bit variable to store distance on each kernel call, it means that when kangaroo jumps out of 128 bit space, all subsequent jumps are calculated incorrectly.

130 puzzle still can be solved with unmodified JLP's kangaroo if you divide 129 bit space into two 128 bits parts, but kangaroos still can jumps out, so you have to control the wrong DPs.


Are you sure? When I tested many moons ago, if I ran a higher range than 128 (b/c hash table only stores 32 hex characters for point and distance (32x4 = 128)), the distances and points were correct, but obviously the leading characters were left out/off because of the 128 bit max storage.

I may have to run again and retest, and extract the hash table....I will check it now.

Update:

It is as how I remembered it. I just ran a super quick test for the 130 bit range. As you know, the program subtracts starting range so we are working with 0 thru 1ffffff.....(129 bit range)
Here is extracted DP, DP of 20:

178559a1004e94449e90d76ca10b3600 26311140a6e43a1530526461aed458e4

On the surface, if you just plugged in 26311140a6e43a1530526461aed458e4, it seems false, but we know that the only other possible number that could be added in front is a 1, so add a 1 to 26311140a6e43a1530526461aed458e4 and you get 126311140a6e43a1530526461aed458e4, now cross reference that distance and you get this point:
0300000B71D19F5FCD4AC6184EDE7C000C178559A1004E94449E90D76CA10B3600
which matches up to:
178559a1004e94449e90d76ca10b3600
178559A1004E94449E90D76CA10B3600

So that is what I mean by doing some manual work if you use JLPs unmodded version and find a collision in the 130 bit range. But if you go up to 135, it gets a little more tricky/complicated.

But you could be correct! Maybe I didn't let the program run long enough to see how any subsequent keys would be handled.

Honestly, I wouldn't use the unmodded version, nor the 256 bit one on github (doesn't work).

To be safe, use Etayson's Kangaroo on github or mod your own version. That's the safer bet.
member
Activity: 104
Merit: 57
March 21, 2024, 01:50:54 AM
So I still believe it could solve 130 and then you would have to do some manual math (nothing hard) to get the actual private key. If the key starts with a 2, I think it would not require the manual math, but if it starts with a 3, then it will.
You can't because GPU uses only 128 bit variable to store distance on each kernel call, it means that when kangaroo jumps out of 128 bit space, all subsequent jumps are calculated incorrectly.

130 puzzle still can be solved with unmodified JLP's kangaroo if you divide 129 bit space into two 128 bits parts, but kangaroos still can jumps out, so you have to control the wrong DPs.

brand new
Activity: 0
Merit: 0
March 20, 2024, 05:36:53 PM
thank you, can you tell me please the math that has to do if address is 3?
i am not good with it and want to make sure i can do it, otherwise waste my time haha


i've been reading this thread since last week till now and I don't find the answer

so if the program is limited to 125bit interval, if i want to search for puzzle 130bit key, do i break the address space to 2 parts and run twice or on 2 computers and then merge?

how is the result, is it the private key in the result.txt file or do I need to do some scalar math to get the key

please help explain, thanks



you can search for privatekeys up to 256 bit, but program is limited to a 125bit interval search


interval search not means the range of privatekey but diff beetween start and end of privatekey.


Start range
End range
Key #1
Key #2

max different end_range-start_range < 2**128





No, no, no. DO not break the space/range into two parts.

First off, I believe it can solve up to 128 to 129 bits (on its own), I think JLP put 125 because of the puzzle, meaning 125 would possibly be the last one his program, unmodded, would solve.

If you extract a workfile, you will see that it holds 128 bits of info for the point and distance, which equates to 32 characters. As you know, 130 contains 33 characters. So I still believe it could solve 130 and then you would have to do some manual math (nothing hard) to get the actual private key. If the key starts with a 2, I think it would not require the manual math, but if it starts with a 3, then it will.

If you are worried about messing something up, and you use windows, I would suggest using Etayson's EtarKangaroo on github. It is good up to 192 bits.

Quote
I probably miss something here, but please explain why do you guys use Kangaroo while there is another tool Keyhunt, which BSGS option is very very fast. With above average hardware, you can get around 10 exa keys per second. That is 10,000,000,000,000,000,000 keys per second.  I have never seen such numbers with Kangaroo.

Different programs; the best way I can explain it, to keep it simple, one is deterministic and one is probabilistic. IMO, BSGS is fast and better for smaller ranges, but Kangaroo is better in larger ranges. I also think it comes down to, do you have a modern PC with lots of RAM, maybe you go with BSGS; if you have GPUs, maybe you go with Kangaroo or BSGS Cuda. Maybe some mods could be made to build a BSGS server/client that would rival Kangaroo in larger ranges.
newbie
Activity: 6
Merit: 0
March 20, 2024, 12:22:01 PM
WanderingPhilospher thanks for your answer.

To succeed with further puzzles we definitely need an upgrade in tools, something combining different algorithms in one search also a pooling idea to eliminate already scanned ranges. 
full member
Activity: 1022
Merit: 217
Shooters Shoot...
March 19, 2024, 11:41:52 PM
i've been reading this thread since last week till now and I don't find the answer

so if the program is limited to 125bit interval, if i want to search for puzzle 130bit key, do i break the address space to 2 parts and run twice or on 2 computers and then merge?

how is the result, is it the private key in the result.txt file or do I need to do some scalar math to get the key

please help explain, thanks



you can search for privatekeys up to 256 bit, but program is limited to a 125bit interval search


interval search not means the range of privatekey but diff beetween start and end of privatekey.


Start range
End range
Key #1
Key #2

max different end_range-start_range < 2**128





No, no, no. DO not break the space/range into two parts.

First off, I believe it can solve up to 128 to 129 bits (on its own), I think JLP put 125 because of the puzzle, meaning 125 would possibly be the last one his program, unmodded, would solve.

If you extract a workfile, you will see that it holds 128 bits of info for the point and distance, which equates to 32 characters. As you know, 130 contains 33 characters. So I still believe it could solve 130 and then you would have to do some manual math (nothing hard) to get the actual private key. If the key starts with a 2, I think it would not require the manual math, but if it starts with a 3, then it will.

If you are worried about messing something up, and you use windows, I would suggest using Etayson's EtarKangaroo on github. It is good up to 192 bits.

Quote
I probably miss something here, but please explain why do you guys use Kangaroo while there is another tool Keyhunt, which BSGS option is very very fast. With above average hardware, you can get around 10 exa keys per second. That is 10,000,000,000,000,000,000 keys per second.  I have never seen such numbers with Kangaroo.

Different programs; the best way I can explain it, to keep it simple, one is deterministic and one is probabilistic. IMO, BSGS is fast and better for smaller ranges, but Kangaroo is better in larger ranges. I also think it comes down to, do you have a modern PC with lots of RAM, maybe you go with BSGS; if you have GPUs, maybe you go with Kangaroo or BSGS Cuda. Maybe some mods could be made to build a BSGS server/client that would rival Kangaroo in larger ranges.
brand new
Activity: 0
Merit: 0
March 19, 2024, 07:35:53 PM
i've been reading this thread since last week till now and I don't find the answer

so if the program is limited to 125bit interval, if i want to search for puzzle 130bit key, do i break the address space to 2 parts and run twice or on 2 computers and then merge?

how is the result, is it the private key in the result.txt file or do I need to do some scalar math to get the key

please help explain, thanks



you can search for privatekeys up to 256 bit, but program is limited to a 125bit interval search


interval search not means the range of privatekey but diff beetween start and end of privatekey.


Start range
End range
Key #1
Key #2

max different end_range-start_range < 2**128




newbie
Activity: 6
Merit: 0
March 10, 2024, 05:46:03 AM
I probably miss something here, but please explain why do you guys use Kangaroo while there is another tool Keyhunt, which BSGS option is very very fast. With above average hardware, you can get around 10 exa keys per second. That is 10,000,000,000,000,000,000 keys per second.  I have never seen such numbers with Kangaroo.
newbie
Activity: 35
Merit: 0
January 22, 2024, 08:52:42 AM
Why the use of only 128 in GPU_GRP_SIZE as in KeyHuntCuda was 2048?

What's the relation between this constants?

Code:
// Number of random jumps
// Max 512 for the GPU
#define NB_JUMP 32

// GPU group size
#define GPU_GRP_SIZE 128

// GPU number of run per kernel call
#define NB_RUN 64

I think GPU_GRP_SIZE should be small as possible to fit SM L1 cache, because it used most frequently.
2048 in KeyHuntCuda (rotorcuda) is too big and huge global memory pressure because of this.
As I understand more NB_RUN = less kernel calls from CPU code. It doing NB_RUNs of GPU_GRP_SIZE.

I'm using Nsight Compute and GPU-Z sensors data to experiment with different values.
Pages:
Jump to: