Quote from: COBRAS on April 06, 2025, 06:16:19 AM

Quote from: Bram24732 on April 06, 2025, 06:09:17 AM

Quote from: WanderingPhilospher on April 06, 2025, 04:24:40 AM

Well that is the funny thing, no one believes in true sequential. None of the pools, not even Bram lol.

If solve time is average of 50% regardless of the order of ranges, why don't the pools nor anyone, start at key x and search it all to key z? Does human nature/gut feelings get involved? Or some kind of personal, average probability based on past wallets solved? Would love to hear their reasoning.

If you go full sequential from 0 to N you’re giving away your progress to the competition. It has nothing to do with better probabilities of finding the key.

For the record the only reason I talk here is to prevent folks from spending money thinking they have a 0.0001% chance of success while it’s in fact more like 0.00000000…..0001%
I’m likely taking 68 but that does not mean I enjoy people throwing their money out the window. Especially when fooled by baseless math theories.

mutagen work perfectly, he is mach faster then bitcrack etc. For solve 68 need max 3 months with 200 mkeys/sec.

Great statement. Now back this up with math.

Quote from: kTimesG on April 05, 2025, 07:16:29 PM

Quote from: FrozenThroneGuy on April 05, 2025, 05:06:38 PM

Quote from: Denevron on March 18, 2025, 02:00:38 PM

Quote from: Akito S. M. Hosana on March 18, 2025, 10:09:59 AM

Wait a minute. If he just said that the 3060 achieves around 2300 Mkeys/s, how much does the 4090 achieve? Does it reach 8000 Mkeys/s on the RTX 4090? 8 GK/s ? In Cyclone GPU ?

Why won't anyone share the fastest GPU code here? Are you hiding the best code for yourselves? It's all just empty talk and blah blah blah.. Tongue

Because no one is obliged to put their work in the public domain for everyone to see. They spend their time and energy on it.

Because I am doing it right now:) The main target - to be twice faster than KeyhuntCUDA, but it is possible only with PTX ASM. And also if somebody knows an algo of Modular inverse faster that DRS62 - let me know. this is the main goal for me. Or stupidly do all of the code with PTX, that impossible for me

If you want it to be faster you have to change the high level parameters of perception and adjust for the specific device characteristics. VanitySearch is more like a port from CPU to CUDA rather than a parallel-thought problem. So all clones follow the same philosophy more or less.

Micro-optimizations with PTX may end up producing the same final SASS as plain C. You might lose a year to optimize some inverse only to find it works slower than initially on some random new GPU, and faster on another. I have 3 versions (SafeGCD, BinGCD and the one by RC), each of them runs better or worse depending on whether I change a single line of code in a totally different part of the kernel source. So it's more a game of luck to have a perfect faster kernel, depending on whether the compiler decides or not to maybe not spill an extra register just because you swapped two lines that are logically non-dependent

Full ptx operations (including inverse…) mitigates the compiler cat and mouse a lot. In my experience 96 regs is the sweet spot for occupancy on this kernel. 64 is too aggressive. It might be luck but my kernel works quite well on all architectures with minimal tweaks