(joking, of course)
Topic: [XPM] CUDA enabled qt client miner for primecoins. Source code inside. WIP (Read 31718 times)
September 01, 2013, 02:38:52 PM
I can take this on. Donate 75 bitcoins to me and you will receive an early beta.
(joking, of course)
(joking, of course)
September 01, 2013, 02:14:37 PM
Community projects always die. It needs to have a motivation. ie. bitcoins.
I would donate to a developer willing to take this on. September 01, 2013, 02:12:58 PM
Community projects always die. It needs to have a motivation. ie. bitcoins.
September 01, 2013, 12:27:18 PM
Too bad, I have an awesome nvidia based gaming rig. I use the cpu for xpm mining but the gpus just sit idle
September 01, 2013, 08:08:12 AM
Damn.
September 01, 2013, 07:26:46 AM
yes,it is~~ 
September 01, 2013, 06:04:01 AM
Is this project dead?
Looks like it. August 31, 2013, 04:06:29 PM
Is this project dead?
August 16, 2013, 09:09:46 AM
How long did you leave it running for before checking? (and yeah my numbers were based on change in chains per day)
About 10 minutes, although I have just checked again and it is still 9% slower. I can also see the marked drop in the chains/day stats in debug.log. Weird.Upon further inspection the chainsperday number seems to jump around all over the place. anywhere from 0.58 to 0.89. Currently it seems to have stabilized at 0.77, which is still markedly higher than it was before the changes at 0.69.
edit: are you using other settings?
Also, sorry for thread jacking primedigger. We really should move this conversation back to the correct thread.
Anyway we're hijacking this thread so suggest starting a new one if you want to continue to figuring this out.
August 16, 2013, 09:04:46 AM
How long did you leave it running for before checking? (and yeah my numbers were based on change in chains per day)
About 10 minutes, although I have just checked again and it is still 9% slower. I can also see the marked drop in the chains/day stats in debug.log. Weird.Upon further inspection the chainsperday number seems to jump around all over the place. anywhere from 0.58 to 0.89. Currently it seems to have stabilized at 0.77, which is still markedly higher than it was before the changes at 0.69.
edit: are you using other settings (or default settings)?
Also, sorry for thread jacking primedigger. We really should move this conversation back to the correct thread.
August 16, 2013, 08:52:11 AM
How long did you leave it running for before checking? (and yeah my numbers were based on change in chains per day)
About 10 minutes, although I have just checked again and it is still 9% slower. I can also see the marked drop in the chains/day stats in debug.log. Weird. August 16, 2013, 08:40:45 AM
How long did you leave it running for before checking? (and yeah my numbers were based on change in chains per day)
August 16, 2013, 08:31:25 AM
I can confirm this gave me a speed up on my 4 machines as follows:
1: 6.88%
2: 4.52%
3: 4.69%
4: 8.42%
1: 6.88%
2: 4.52%
3: 4.69%
4: 8.42%
Interesting - I saw a 9% decrease in Chains/day???
August 16, 2013, 08:21:07 AM
I can confirm this gave me a speed up on my 4 machines as follows:
1: 6.88%
2: 4.52%
3: 4.69%
4: 8.42%
1: 6.88%
2: 4.52%
3: 4.69%
4: 8.42%
August 16, 2013, 08:17:57 AM
Thanks! Just as an aside, in c++ what does it mean to wrap a block of code in { } when there isn't a function definition, if, else, while, for, etc. statement? (in regards to the second block of code you mentioned to comment out, it seems wrapped in {} with no initial statement.
It's a nice simple way to limit the scope of any variables declared inside the {} to only be "visible" inside those bracketsAhhh. sweet, good to know. I don't write much c++, just learning it now.
August 16, 2013, 08:13:47 AM
Thanks! Just as an aside, in c++ what does it mean to wrap a block of code in { } when there isn't a function definition, if, else, while, for, etc. statement? (in regards to the second block of code you mentioned to comment out, it seems wrapped in {} with no initial statement.
It's a nice simple way to limit the scope of any variables declared inside the {} to only be "visible" inside those brackets August 16, 2013, 08:03:42 AM
If you can't wait for Mikaelh's fix: The fast div can be disabled easily, open prime.cpp in an editor and comment out the whole "if (fFastDiv) {...}" block in the function FermatProbablePrimalityTestFast and comment out the block after the comment "// Compute parameters for fast div test" in MineProbablePrimeChain.
The number of candidates it filtered out was depended on "nFastDivPrimes", which by default was chosen fairly low, thus only ~6% of candidates are (wrongly) discarded. But hp-9 is still doing unnecessary divisions on all candidates, so you can speed up hp-9 by commenting out those divisions.
The number of candidates it filtered out was depended on "nFastDivPrimes", which by default was chosen fairly low, thus only ~6% of candidates are (wrongly) discarded. But hp-9 is still doing unnecessary divisions on all candidates, so you can speed up hp-9 by commenting out those divisions.
Thanks! Just as an aside, in c++ what does it mean to wrap a block of code in { } when there isn't a function definition, if, else, while, for, etc. statement? (in regards to the second block of code you mentioned to comment out, it seems wrapped in {} with no initial statement.
August 16, 2013, 07:48:06 AM
If you can't wait for Mikaelh's fix: The fast div can be disabled easily, open prime.cpp in an editor and comment out the whole "if (fFastDiv) {...}" block in the function FermatProbablePrimalityTestFast and comment out the block after the comment "// Compute parameters for fast div test" in MineProbablePrimeChain.
The number of candidates it filtered out was depended on "nFastDivPrimes", which by default was chosen fairly low, thus only ~6% of candidates are (wrongly) discarded. But hp-9 is still doing unnecessary divisions on all candidates, so you can speed up hp-9 by commenting out those divisions.
The number of candidates it filtered out was depended on "nFastDivPrimes", which by default was chosen fairly low, thus only ~6% of candidates are (wrongly) discarded. But hp-9 is still doing unnecessary divisions on all candidates, so you can speed up hp-9 by commenting out those divisions.
August 16, 2013, 07:16:26 AM
I think there might be a bug in hp-9 somewhere, so that the trial division doesn't work quite right in that version and sorts out wrong candidates. I will need to confirm this with the hp-9 sources without my changes, so that I'm sure I didn't introduce that bug. The CUDA trial division seems to be doing the right think and it doesn't find any candidates to discard, because if I understand it right, the sieve already did that. To put it in different words: this idea is likely a dead end.
I can confirm that fast division is buggy in hp9. It's also not needed in hp9 anymore because of Sunny's optimization. I'll remove the code in my next release. Thanks for spotting the bug.
So uhh... should we not be using HP9 then?
The fast-div test seems to be filtering out about 6% of candidates. HP9 should still be faster than HP8 despite that.
August 16, 2013, 05:50:08 AM
Jump to: