Hi,
A GPU miner for PRimecoin implies to parallelize the 2 execution instances of BN_mod_exp(&r, &a, &e, &n, pctx). Paralleling of sieve would be an improvement, but it is not the central part , as is done in other OpenCL/CUDA primality tests where sieve is done in CPU.
So, it is indicative when someone open a thread about parelellize a code and reports are about mingw and accesorials and anecdotical affairs with Windows building.
Well, for parallelizing BN_mod_exp(&r, &a, &e, &n, pctx) this guy should to have rewrotten (at least) BigNum lib for OpenCL ....
Good luck with the project and people who donated !!
Yup, if someone manages to use some level of parallelism for mod_exp on a GPU, then that will be a big thing. I'm personally still a bit doubtful whether it can be done efficiently because doing the mod operation requires division. Usually those algorithms involve unpredictable branching and that's going to slow things down on the GPU. |
|
|
|
What's better to optimize for: primes/sec, chains/min, or 5-chains/hr?
chains/min = 5-chains/h / 60 Both are counting the same thing. I'm personally looking at the 5-chains/h estimates when running on mainnet. On testnet I'm usually looking at either primes/sec or 5-chains/h. Sometimes I measure the actual block rate to verify things. |
|
|
|
Where do I put this new libgmp-10.dll file?
Just let it sit in the same folder with the binary. |
|
|
|
Thanks mikaelh... Is there anything similar to Sunny's original gensieveroundlimitms as a fallback to limit the total time spent on a round?
Technically Sunny's gensieveroundlimitms does not limit the total round time. It only limits the sieving part. With my release you can use sievepercentage to adjust the sieving time. Then you can use roundsievepercentage to adjust the total round time based on the sieving time. There's no option for a hard cap in milliseconds since I don't see any point in it and the code runs faster if I don't impose such hard caps. |
|
|
|
|
-hp8 is finally out!
Changes in -hp8:
* IMPORTANT: Fixed loss of potential blocks caused by fractional length calculation being skipped if fast divisibility test succeeds. (Thanks to mtrlt for spotting this.)
* Skip fractional length calculation for the first number in a chain (as suggested by gatra).
* Added a new configurable round primorial adjustment system.
* Round primorial can be adjusted through the -roundsievepercentage parameter (default value is 30, minimum is 1, maximum is 100). The parameter depends how much time is spent running the sieve. By default 30% of time is spent in the sieve and 70% is spent on checking the candidates produced by the sieve.
* Lots of other performance improvements.
* Bigger sieve sizes should no longer crash on Windows.
* Added new RPC commands setsievepercentage and setroundsievepercentage for changing parameters on the fly.
* GMP is now included as a separate library in the binary releases.
Links to downloads are on the first page. This release was delayed by a few bugs but it's finally here. Many improvements and fixes were included in this one. My own benchmarks show that block rate is nearly doubled compared to -hp7 on testnet. Performance on mainnet is also looking really good.
There's a new tuning parameter called -roundsievepercentage. You shouldn't need to touch this normally. Optimal value for mainnet seems to be around 30%. For testnet it's around 20% for some reason. The round primorial is adjusted based on this parameter. Smaller percentage means a bigger round primorial. Bigger round primorial in turn means that primes are more probable but the numbers will also get bigger which will slows down the testing.
Bigger sieve sizes seem to have suffered a performance hit with this release. I suggest starting with the default size.
|
|
|
|
mikealh, I'm seeing OK performance with this in terms of PPS but haven't checked the chains. im using a 2M sieve. Is the bug triggered by a bigger sieve?
Well, at least on my system a bigger sieve size seems to change the timings in the code so that the dynamic adjustment system starts doing silly things. |
|
|
|
Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.
The performance regression should be fixed by latest commit on bitbucket. I'm still getting poor performance with the latest commit, it doesn't look like the fix helped at all. Can you be more specific how your performance is poor? Are you looking at primes/sec, chain/min, block rate or something else? Also remember to not compare any numbers against previous network difficulties. EDIT: It seems you may be right. Most of my own tests are still showing poor performance. EDIT2: Large sieve sizes trigger pretty much the same performance bug. |
|
|
|
Will there be a hp8 release soon?
Probably yes. The current code is looking good now that the performance regression has been fixed. |
|
|
|
Is there anyway to find out which version of the HP* I have installed?
Currently there isn't. You can try comparing your binary file against different releases. Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials. Why not just change the version string? I plan to. |
|
|
|
Is there anyway to find out which version of the HP* I have installed?
Currently there isn't. You can try comparing your binary file against different releases. Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials. Hi, I'm also trying to see what are the optimal parameters and based on my testing I found that nTestsAtOnce = 500 in the MineProbablePrimeChain() functions doesn't gives me the optimal performance. I tested it with 5chain performance and I introduced for myself also 6chain average and tested mainly against this value. For me the optimal value was around nTestsAtOnce = 1800. I also used sievesize 800000, and sievepercentage over 50 gave better results. PPS is not at all a performance indicator here. Edit: I made some other modifications as well that I can't remember now so if anybody want to test these values may not get the same results. Well, nTestsAtOnce should have only minimal impact on performance. It's there so that the call won't block the main loop for too long. Sievesize and sievepercentage definitely do affect performance but you have to do your statistics properly with those. Preferably you should be measuring actual block rate. Also if you happen to be testing on mainnet, make sure you grab my fix for the performance regression. |
|
|
|
Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials.
The performance regression should be fixed by latest commit on bitbucket. |
|
|
|
Is there anyway to find out which version of the HP* I have installed?
Currently there isn't. You can try comparing your binary file against different releases. Also I found the reason for the performance regression. The latest code seems to get stuck on using too low round primorials. |
|
|
|
I am currently testing the latest commits, it seems that the PPS indicator is very low compared to the value before, more than halved my numbers and chainspermin is 0 mostly all the time.
I will keep on testing, meanwhile, is anybody else testing the CURRENT version and seeing the same results out there ?
This happened for me too, on my Debian server with an i5-3570. I can't get even 1k PPS anymore, and chainspermin is around 1. HP7 was performing much better before. I don't have this performance problem with the newest version on an Ubuntu VirtualBox installation. There does indeed seem to be a regression with the latest code on mainnet. I'm trying to investigate it further now. |
|
|
|
I do not understand primecoin that well at the moment, the problem with v7 would that be reflected in primemeter stats in the debug file, does anyone know?
No, it won't show up in primes/sec or chains/min. I'm guessing it's reducing block rate by about 20%. Is this only a problem in hp7? If it is, I assume that most folks would be better off by going back to hp6. HP6 is also affected. |
|
|
|
I do not understand primecoin that well at the moment, the problem with v7 would that be reflected in primemeter stats in the debug file, does anyone know?
No, it won't show up in primes/sec or chains/min. I'm guessing it's reducing block rate by about 20%. |
|
|
|
I am currently testing the latest commits, it seems that the PPS indicator is very low compared to the value before, more than halved my numbers and chainspermin is 0 mostly all the time.
I will keep on testing, meanwhile, is anybody else testing the CURRENT version and seeing the same results out there ?
Can you post more information about your system and the which exact versions you are comparing? |
|
|
|
@mikaelh: Why not merge your code with Sunny King's? He stated that it's due to licensing problems with libgmp (can't find the source), but I think that this is wrong. libgmp is LGPL, not GPL, and can therefore be used even in closed-source projects provided that you link to it only dynamically. Which primecoind does, so you would be fine even if primecoin would be closed-source.
Well, technically my Windows builds have been using static linking. It can be changed to dynamic linking. x86 will take a minor performance hit from that but x64 should be fine. Even if the licensing concerns are solved through dynamic linking, it's still Sunny King's call whether he wants the code or not. |
|
|
|
I might have found a bug in hp7. I copied the hp7 code over to Reaper, and found some weird behavior. I noticed that many shares/blocks it found, had a difficulty with a fractional part of 0.
Function: FermatProbablePrimalityTestFast. It does a Fermat test, and if it fails, it calculates the fractional part. However, there's a fast division test before the Fermat test. If the fast division test is succesful, the function is returned from and the fractional part isn't calculated. If it just happened to be the last number in a chain, the fractional part isn't calculated and is left at 0. This means if the difficulty is for example 6.2, and the miner found a block of difficulty 6.3, it's possible that the fractional part was left uncalculated, and the miner thinks it's difficulty 6.0. The block doesn't get submitted and lots of profit has been lost.
The same applies to EulerLagrangeLifchitzPrimalityTestFast.
Right now I don't have git set up, I can't submit a patch.
Good catch! Letting that one slip was definitely a big oversight on my part. I pushed my own fix to bitbucket just now. I don't have time to do a release right now so it'll have to wait for a bit. In the meantime the fix is up there for testing. |
|
|
|
Where can we report feature requests now as the github account is disabled?
mikaelh, would it be possible to add the 5-chains value to the mininginfo rpc call and/or add a separate rpc call for it? Just like for getprimespersec. That would be really handy for measuring performance!
That's already done. It's called (get)chainspermin. I'd like setsievesize and setsievepercentage  A setsievesize command isn't really possible with the current code. OTOH, setsievepercentage is possible. |
|
|
|
Updated Qt binaries are now up.
[rahlquist@corgi 64]$ ./primecoin-qt ./primecoin-qt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./primecoin-qt) ./primecoin-qt: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ./primecoin-qt) ./primecoin-qt: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./primecoin-qt) Highest version of Glibc avail in stable for Cent/Rhel etc is 2.12 Oh yeah, there are still the glibc and libstdc++ dependencies. Those are quite hard to get rid of. For now your best option is probably to compile it yourself. You can try taking a few pointers from my guide here: https://bitcointalk.org/index.php?topic=259022.0That only shows how to compile the daemon though. You'll need to install the Qt development packages in addition to compile the Qt client. |
|
|
|
|
Show Posts
