Topic: [XPM] [ANN] Primecoin High Performance | HP14 released! - page 49. (Read 397657 times)

In case you are interested in the validity of the chains per day metric, with the following setup running on 9 identical machines I managed 8 chains over 24 hours.

8/9=0.8888 chains per day.

I would say, close enough for government work in this case.

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.

BTW: I'm compiling the 64bit version of jhPrimeminer under Windows with Visual Studio, where the size of 'unsigned long' is 32bit and not 64bit like in Linux (GNU). I've tried replacing the "unsigned long" with uint64_t (unsigned long long)  but it makes the Wave function run slower ( ~15-25%). I'm thinking maybe it worth a try to replace the "unsigned long' to uint32 in the Wave() function in primecoin (HP9) client where the nL1CacheElements  is also used.
Does it makes sense what I'm talking about?

Mikael, thank you for the clarification. Indeed after checking the code I found the reason why it has to be a multiple of 64/32. It's a shame I didn't checked this before.
Anyway I've run some more tests and using the default settings of the primecoin client there was no significant gain for different nL1CacheElements, but in the moment the sieve size and the sieve percentage was raised  the nL1CacheElements size had more affect. For example with sievesize=2000000 and sievepercentage=50 a higher nL1CacheElements (1056000) speeds up the Wave by ~30%. (my CPU is i7)
In any case because 50% is probably not the optimal sievepercentage this measurement is less relevant.

thanks mikael, I tried values ~100000 higher and lower (but multiples of 64/32) and saw decreased performance both ways, so 200000 seems optimal for now.  Shame, I was starting to think I could get 3x performance then

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.

mikeal, what about using values that ARE a multiple of both 64 and 32 then?  Is that safe and will it yield improved performance if done correctly?

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.

Just tried to remove the loop which processes blocks of nL1CacheElements.
Performance seems a bit affected, chainsperday hit by a 0.82 factor.

What do you think ? Are chainspermin variation due to nL1CacheElements value an indicator of performance improvement/degradation ?

8 blocks found during the night, 2 of them are orphans, thats 25%...
Could this be related to connexion count ? My current vps all have 8 connections while on DO I could get up to 30 connexions per instance, could this be a reason ?
Any ways to increase the connexion count ?

Hi,
In the modified version of the jhPrimeminer that is used for ypool.net I did some kind of auto tuning for the nL1CacheElements by measuring the time it takes to execute the Wave() function. Indeed the default is not the optimal most of the time. I also found that for some settings even higher (1.000.000+) nL1CacheElements performs better. Based on test using profiling tools I concluded that the most time consuming code is writing to the memory and also this is done less linearly but to more random positions. So I think in this case the CPU cache has less role. Maybe I'm not right, I never done these kind of tunings before.

It's a bug in the primecoin client - It's been partially fixed but everyone gets it occasinally. From what I have heard systems with more cores (6+)tend to get it more often. All we can do is just restart the primecoin client to deal with it for now.

I've only been mining for about a week now, and I occasionally get the following error/crash:

Assertion failed!

Program: D:\Primecoin\primecoin-qt.exe
File: src/checkqueue.h, line 171

Expression: pqueue->nTotal == pqueue->nIdle


primecoin-0.1.2-hp9-winx64.zip

Has fontas sent a future tweet yet for the pump?  I want to make sure I have my coins ready.

Prime chains are plenty.  I don't think we will ever reach 1000 digit zone, not in 100 years at least.

Exactly. Even if the prediction is way off, that isn't a big problem as long as something half the speed is also equally off with half the prediction. Need some way to compare hardware and know which machines are faster miners than others, etc.

That's really interesting info, I couldn't figure out how the block hashes were determined in Primecoin. This shows Primecoin to have a really bright future!

Well less of a model to predict blocks/day and more of a way to measure performance. For instance, it could help someone tweak their setup to finding longer chain lengths instead of shorter. Or really, just help people understand what their tweaks are doing to performance

You are proposing to build a model to predict how many blocks can be found per day. As I understandd that was basicly why Sunny added the chains per day gauge. However Sunny pointed out somewhere that chain/d is not block/day. They are just closely related.

One major misconception on this coin is people think it acts like any other coin out there... in one way it does, but for the most part it doesn't.  Bitcoin, Litecoin, etc, all use a hash.  Since the hash needed is random, it takes time to find.  This is the only area where primecoin is like the others, in that it is a random chance to get the right variable to find a prime.  Where primecoin diverges is that it can never reuse a number already found.  Bitcoin and Namecoin can use the same hash and be 'merged mined', primecoin alone can never be merge mined.

The basis behind blocks is finding Cunningham Chains of length N where N is the difficulty rating.  What does this mean?  The smallest known length 9 chains are:85864769  and
857095381 (1st and 2nd kind).  The proof of work on this coin is such that once a prime chain has been found, it cannot be reused.  So each prime found means the one less prime that can be found.  Look at the records primecoin has found in length 9 chains: 2030793138184474269420052163338592688212588454185304749794006580858788424425799 69*179#-1 is 151 digits long!  In a way, the nice thing on this is that as time goes by and the length of these primes gets up into the 1000+ digit range, difficulty will start coming down as they become harder to find and we'll start finding larger 8 chains and larger 7 chains.

Therefore the metric for finding blocks is ever changing, you can't count on what works today being the best thing to do in 2 weeks time as well.  This is an ever changing coin and people really need to start thinking outside the box.