Quote

Have you found any blocks with these changes? My very poor understanding of the algorithm suggests that changing the has factor will not work...

No - I only was testing based on some of Koooooj's comments to see if there was a possible tradeoff.
The primecoin paper says:

Quote

In one case, varying nonce and finding a block header hash that is divisible by a small
primorial number the product of all primes smaller than a given prime p can help
only slightly. It allows the prime miner to work on somewhat smaller primes, like maybe
a few digits shorter, for prime numbers of typically 100 digits, only a very small
advantage.

which suggested further that this is only used to help make finding candidates faster.

--------

Related, I finally was able to coerce primecoind to compile on FreeBSD. Here are some stats for an HP DL 585 w/64 cores -- which is actually almost the same for 5-chains as the cc2.8xlarge:
2013-07-19 07:21:20 primemeter 52706242 prime/h 409095802 test/h 2700 5-chains/h
2013-07-19 07:22:20 primemeter 55256799 prime/h 430313188 test/h 2820 5-chains/h
2013-07-19 07:23:20 primemeter 57252732 prime/h 451175301 test/h 3180 5-chains/h
2013-07-19 07:24:20 primemeter 60431918 prime/h 472296745 test/h 2280 5-chains/h
2013-07-19 07:25:20 primemeter 49530089 prime/h 384528982 test/h 2460 5-chains/h
2013-07-19 07:26:20 primemeter 51512423 prime/h 400527689 test/h 1980 5-chains/h

If you're interested in compiling for FreeBSD, you also will need to install the usual libraries and also change init.cpp:

Code:

// nMaxConnections = std::max(std::min(nMaxConnections, FD_SETSIZE - nBind - MIN_CORE_FILEDESCRIPTORS), 0);
nMaxConnections = std::max(std::min(nMaxConnections, static_cast(FD_SETSIZE - nBind - MIN_CORE_FILEDESCRIPTORS)), 0);

I had to specify the install paths for a lot of things and remove the explicit -ldl in the makefile as well.. go figure.

Quote

Did you test with other number aswell?

Yes, I did 10, 11, 12, 13, 14, 15, 16, 17. It starts to get bad around 13 on the big aws instance.

Quote

I could be wrong, but I'm not convinced this change will make any significant difference. The primorial of 7 is the same as that of 9, since 8 and 9 aren't primes.

No this is not what primorial means.

primorial(1) = 2
primorial(2) = 2 * 3
primorial(3) = 2 * 3 * 5
and so forth.
primorial(7) = 2 * 3 * 5 * 7 * 11 * 13 * 17 = 510510
primorial(9) = 2 * 3 * 5 * 7 * 11 * 13 * 17 * 19 * 23 = 223092870

Notice the list of divisors this produces when using p#9 * some random price
> bc
print 223092870 * 498497689
111211280127377430

http://www.wolframalpha.com/input/?i=factor+%28111211280127377430%29

Honestly I can't say I really understand what the code is doing here, but based on some the comments from Kooooooj and running through gprof, Weave is sucking up all the time -- so I was trying to push some of the work out of there and into the caller function. I am 100% speculating also that the increases in difficulty may make the primorial a little more important. But anyway, mostly just hacking.

oh well, off to bed.