Well, I'm pretty impressed with the difficulty increase so far. You have to remember that it's scaling logarithmically which means that a 5% increase is pretty big at this point. HP10 is probably still being deployed so the difficulty will keep going up. Also ypool seems to be down which means the network may have lost quite a lot of power at the same time. If ypool really is down and difficulty is still going up, I'll be very impressed.

The formula posted by SlyWax isn't accurate. He assumed that the decimal part would behave linearly while in reality it seems to behave logarithmically. The chains/day estimate does account for the integer part.

I haven't seen a crash like that. Can you post your debug.log and primecoin.conf?

-hp10 released! Downloads are on the first page as usual.

Changes in -hp10:
 * Major rewrite of the sieve to support extending the sieve (originally implemented by jh000).
 * Added a new parameter 'sieveextensions' which controls how many times the sieve is extended.
 * Removed the problematic and unnecessary fast-division test.
 * Changed the value of nL1CacheElements to 224000 which is slightly faster (thanks to nushor on IRC).
 * The 'roundsievepercentage' parameter is gone. The round primorial is now automatically adjusted.
 * New RPC command 'listtopprimes' by Sunny.

It should still work just fine. You just need to change in which directory you compile.

You can download a ZIP from github if you want.

Compiling the client with -O3, -msse2 or -march=native is not going to make a big difference. The sieve currently doesn't benefit from SSE2 or any other special instruction set. The default -O2 optimization level is more than enough.

GMP does benefit from compiler flags. The "configure" script that comes with it tries to detect the best settings if you compile it yourself.

"Roundsievepercentage" is gone. The round primorial is now adjusted automatically.

"Sieveextensions" is a new parameter which controls the new big optimization. jh00 discovered that the sieve can be "extended" efficiently to numbers that are two times bigger. That parameter determines how many times the sieve is extended (each further extension will produce numbers two times bigger than the previous extension). Bigger numbers will have a lower probability of hitting primes and prime chains but each extension is pretty cheap. Six extensions seemed like the optimal value for mainnet.

I pushed some big optimizations for -hp10 to github so that more people can test them.

AFAIK mtrlt's GPU miner is not out yet. So please stop spamming that link in these threads.

I simply added maxconnections=750 to the config file so that it will be able to handle plenty of connections. Beyond that you'll obviously want a static IP address and some bandwidth.

EDIT: It's not an official seed node. Those are hard-coded into the client. My seed node is more like a backup node.

It seems there may be issues with the seed nodes again. I'm putting up my own seed node. Try adding this to your primecoin.conf:

The fast-div test seems to be filtering out about 6% of candidates. HP9 should still be faster than HP8 despite that.

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.

There's not much that can be done about it. I think it comes down to modular exponentiation being faster on x64.

Also as I have said before, haveged is probably not useful for mining. I don't see why the mining process would need entropy. It shouldn't really be detrimental either except for the fact that a few CPU cycles are being wasted.

Well, it's good to know that long is always 32-bits in Visual Studio. I haven't really worked with that compiler. One unfortunate side-effect of that is being unable to pass 64-bit values directly to GMP/MPIR because the interface uses unsigned longs.


Yup, I also suspect that the Visual Studio compiler isn't optimizing properly there. But I haven't looked at the generated code.


Well, I did check that most Intel processors have a 32 kB L1 data cache while AMD processors typically have a 64 kB data cache. 256000 is pretty much pushing the L1 cache to its limits on Intel CPUs. If it also shows good performance in my testing, I will probably incorporate that change. The annoying issue with 256000 is that it doesn't divide 1M (sieve size) evenly.

I have also considered discovering the L1 cache size automatically and adjusting the parameters based on that. The problem with that is that I don't have a lot of CPUs to test on.

If you use multiples of 64 (or 32), then that should work in theory. I haven't really tested that exhaustively though. I would expect minimal gains from adjusting it in most cases.

The nL1CacheElements constant was not meant to be changed and there's a good reason for that. nL1CacheElements needs to be a multiple of 64 on a 64-bit platform (or a multiple of 32 on a 32-bit platform). Otherwise the sieve code will start misbehaving which seems to be what razibuzouzou is seeing. The sieve will start producing false candidates which will distort the metrics. The tests/h is the number of candidates produced by the sieve which is directly impacted. The chains/day estimate relies on tests/h being accurate so that will also be heavily impacted.

With the latest version, there could also be a small negative impact on block rate if the sieve is misbehaving. The false candidates will always be marked as bi-twin candidates. If it in reality is a candidate of another type, it will not get recognized properly.

Summary: Don't touch nL1CacheElements unless you know exactly what you're doing.

That seems pretty much normal to me. The idea behind hyper threading is that the CPU core switches threads when one thread is blocked waiting for memory. My code is nearly always hitting the L1 or L2 caches which keeps the CPU core busy at all times even with one thread. So in theory you only need enough threads to keep all the physical cores busy.

Well, as far as I know there are 2 bottlenecks when it comes to scaling out:

1) Block generation. Only 1 thread at a time can be generating new blocks. This was already mostly fixed by Sunny.

2) Memory allocation. The default malloc implementation uses mutexes internally which reduces performance with multiple thread trying to allocate memory. This shouldn't be an issue with my client because I have reduced the amount of memory allocations needed.

So as far as the code is concerned there shouldn't really be any bottlenecks. If the caches on the CPU are completely inadequate, some performance issues would start appearing. But as far as I know, most server CPUs have pretty big caches.

And of course if you have a VPS, remember that you may be sharing the CPU time with other people's instances.