well can you please tune it for parallel search for pubs , i undertand speed will drop but its still worth to try .. can you?
BSGS algorithm is not intended to search for public keys in parallel.
Possible to make pseudo-parallelism (this means finding the keys sequentially at each giant step). But the speed will drop in multiples of the number of search keys.
For ex. with search 1 public key your speed is 1000mkeys/s. if you setup 10 keys the speed will drop to 100mkey/s, with 1000keys speed drop to 1mkeys/s
By the way the search time for 16 keys will be exactly the same, either in a sequential search or in a pseudo-parallel.Got it but just as example if you do 32 divisor and load 32 keys , assume if key is on position 1~ lucky you. but if the key is on position 30 program will hang with full range scan for key 1 and than will be back to second (my guess ~ didn't test your program) one perhaps after this century

but one thing that i noticed Alberto keyhunt [updated recently] is way too faster than BSGScuda [although both have different way]. i solved 80 key with blink of eye but that one need serious
K and
N optimization ~ do the wrong
K and
N you will never reach the goal. i am not sure if you guys have a chance to test that one
Alberto KEYHUNT you will find it interesting.
but dark fact is keyhunt is ram eating bug

so if have less ram (minimum 128gb) no point to compare it with BSGScuda perhaps in that case BSGScuda will do way better than Keyhunt.
If you feel keyhunt is faster via your own tests, then divide that 120 pubkey up into 2^40 pubkeys and run keyhunt; maybe you find the key in 2 blinks of an eye...
Got it but just as example if you do 32 divisor and load 32 keys , assume if key is on position 1~ lucky you
then just do your 32 divisor and let it search each pubkey for 1 minute; maybe lucky you.