I'd feel better waiting for his official commit in case he still adopts it in some way (he knows the code better than me) since we have to assume that a larger group of people will download & use it.
But if you're impatient :-) , I outlined it in https://bitcointalk.org/index.php?topic=253662.msg2701731#msg2701731 . It's prime.cpp.

Kind regards
Mike

Another update from Sunny King is upcoming - not only will it bail out after max. 3 secs, it will also bail out if a new block has arrived in the meantime.
-> https://bitcointalk.org/index.php?topic=253662.msg2702001#msg2702001

And if shinkicker's still awake he may provide a compiled windows client :-)

Look out for
proof-of-work found
in debug.log

Hi hl5460,
no, I'm not.
Just working on some optimizations of my own and this came to my mind when I thought about his change.

Kind regards
Mike

Looking for Obelisk? :-)

Hi Sunny King,
inspired by that I added something else (though I'm still testing):
Make that
while (psieve->Weave() && (pindexPrev==pindexBest) && (GetTimeMicros() - nStart < 3000000));
and add a
CBlockIndex* pindexPrev=pindexBest;
as first line of MineProbablePrimeChain().
Also, make that
while (nCurrent - nStart < 10000 && nCurrent >= nStart && (pindexPrev==pindexBest))
later on.
Should theoretically provide an automatic exit if the best block changes during work.
(But I'm still testing it)

Should do, but comment out
if (nBiTwinSeq < nChainLength)
in the first for loop, as that was the idea of splitting the loop (don't need to check there as that loop only runs up to nChainLength).
And add
unsigned int nBiTwinSeq = 0;
before the first loop
Rest looks ok (testing something else right now so my code already looks different.... yeah I know, no versioning, but hey... I'm doing this for fun :-) )

building on Ubuntu. Should I get phenomenal results (ahem) I'll try to follow the instructions on how to set up a windows build environment for my windows machines.
Processor on that machine is an i7-920 at stock speeds, primecoind mining with 6 threads at nice 20 (the machine also has other stuff to do, like running bfgminer on my fpgas :-) )

Hm, that would save memory but cost more in terms of computing (fiddling with all the bit shift operations).
I think I'll first go for a plain int array and when I want to set a bit for the former arrays I can just do a |=,
and it will much simplify the ORing of all three arrays, so I'd guess it's only one malloc for the whole array and saving in computational efforts.
(Although I'm aware that those CBigNum probably much outweigh all these optimizations if one could save there)

https://bitcointalk.org/index.php?topic=251850.msg2689981#msg2689981
(But I didn't change the MaxSieveSize)

in prime.cpp:
// Prime Table
std::vector<unsigned int> vPrimes;
unsigned int vPrimessz;    (<--- add this)

in GeneratePrimeTable(), add a last line:
vPrimessz=vPrimes.size();

Replace all other occurrences of vPrimes.size() with vPrimessz.


    for (; nBiTwinSeq < nChainLength; nBiTwinSeq++)
    {
[...]
        //if (nBiTwinSeq < nChainLength)
        for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
            vfCompositeBiTwin[nVariableMultiplier] = true;
        if (((nBiTwinSeq & 1u) == 0))
            for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
                vfCompositeCunningham1[nVariableMultiplier] = true;
        else
            for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
                vfCompositeCunningham2[nVariableMultiplier] = true;

[...]
    for (; nBiTwinSeq < 2 * nChainLength; nBiTwinSeq++)
    {
[...]
        //if (nBiTwinSeq < nChainLength)
        //    for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
        //        vfCompositeBiTwin[nVariableMultiplier] = true;
        if (((nBiTwinSeq & 1u) == 0))
            for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
                vfCompositeCunningham1[nVariableMultiplier] = true;
        else
            for (unsigned int nVariableMultiplier = nSolvedMultiplier; nVariableMultiplier < nMaxSieveSize; nVariableMultiplier += nPrime)
                vfCompositeCunningham2[nVariableMultiplier] = true;

Hi gatra,

with those few blocks/day and primes/s being quite imprecise...
I left optimizations in when they didn't appear to cause an immediately visible (~10min) deterioration in primes/s.

Yeah, I'm aware of the bool issue, and I thought let's give it a try in the malloc vs. memory tradeoff. It actually seems to have been the single optimization that brought a rather direct improvement to primes/sec (apart from Sunny Kings change).
Still, take a look at a profiler, those mallocs are by far the most dominant in the whole program.
I'm thinking of merging the three arrays into one and saying e.g. 1 bit means vfCompositeCunningham1, another one means vfCompositeCunningham2 etc.
since they are usually addressed one after another at the same index, this optimizes cache usage, and something like
            if (!vfCompositeCunningham1[nMultiplier] ||
                !vfCompositeCunningham2[nMultiplier] ||
                !vfCompositeBiTwin[nMultiplier])
can be reduced to
if (newarray[nMultiplier]!=0)

@tacotime: I did a

    CSieveOfEratosthenes(unsigned int nBits, uint256 hashBlockHeader, CBigNum& bnFixedMultiplier):
        vfCompositeCunningham1{0},
        vfCompositeCunningham2{0},
        vfCompositeBiTwin{0}
    {

instead - the compiler gives a strange warning about me having to supply a switch but this behaviour being the default anyway () but all bools appear to be false, so it appears to be working (I did a loop in the initializer for a while that was checking whether alls are false and if not would have output a warning, and as I saw no warning after ~30mins I then removed the check and am assuming that all is fine...
prime.h:96:2: Warnung: erweiterte Initialisierungsliste nur mit -std=c++11 oder -std=gnu++11 verfügbar [standardmäÃig aktiviert]
(Roughly translates to : Enhanced initialization list only when using -std=c++11 or -std=gnu++11 available (activated by default)
But when I supply either, I get errors in other modules...

Difficult to say, as Sunny King's change brings a huge boost to primes/sec measurement, and since we already know that this is not a real measurement....
I found three blocks in 1,5h whereas I only had 2 blocks in the 24h before that, but since we're talking luck this may well just be a statistical anomaly.

With all mentioned optimizations in place I now see
2013-07-10 19:54:30 primemeter   1229628 prime/h   9519403 test/h
2013-07-10 19:56:30 primemeter   1200380 prime/h   9385149 test/h
2013-07-10 19:58:31 primemeter   1059123 prime/h   8281702 test/h
2013-07-10 20:00:32 primemeter   1132707 prime/h   8806710 test/h

Whereas before I had
2013-07-09 16:01:06 primemeter    191133 prime/h   1230638 test/h
2013-07-09 16:03:07 primemeter    207187 prime/h   1333814 test/h
2013-07-09 16:05:07 primemeter    197670 prime/h   1302659 test/h
2013-07-09 16:07:08 primemeter    226844 prime/h   1538940 test/h
2013-07-09 16:08:09 primemeter    241089 prime/h   1653641 test/h
2013-07-09 16:10:09 primemeter    246644 prime/h   1574452 test/h

So if this helps, feel free to donate ;-)
XPM   ALLbe86QswwTRvx1LTVnKaVXCz6mcA6YUR
BTC   135oF6hF9uUbzq9x1vTuaoqKPab2j513f2

I'm thinking the biggest improvements can be done by
a) optimizing the algorithm itself, possible according to TacoTime's post
b) minimizing malloc()s
and I guess there's still lots of potential.
If I had more time I'd try looking into using smaller sieves that fit into CPU cache but doing more sieves (so that the range sieved remains the same)

Ok, so I'm probably hurting my income, but sharing some hints for optimizations:
A quick'n'dirty profiling run showed that we spend very much time in memory allocations, so I am trying to eliminate some of them.

-did the headerhash mod outlined earlier

-did the time limit on Weave() from Sunny King

-removed some printf's , especially
printf("MineProbablePrimeChain() : new sieve (%u/%u) ready in %uus\n", psieve->GetCandidateCount(), nMaxSieveSize, (unsigned int) (GetTimeMicros() - nStart));
from prime.cpp since it's the only call to the rather expensive GetCandidateCount

-after creating vPrimes array in prime.cpp, store vPrimes.size() in a static variably and replace all calls to it with the variable

-in prime.cpp, PrimeTableGetNextPrime and PrimeTableGetPreviousPrime: Use upper_bound/lower_bound instead of linear search:
// Get next prime number of p
bool PrimeTableGetNextPrime(unsigned int& p)
{
    std::vector<unsigned int>::iterator foundelement=upper_bound(vPrimes.begin(), vPrimes.end(),p);
    if (foundelement!=vPrimes.end()){
        p=*foundelement;
        return true;
    }
    return false;
}

// Get previous prime number of p
bool PrimeTableGetPreviousPrime(unsigned int& p)
{
    std::vector<unsigned int>::iterator foundelement=lower_bound(vPrimes.begin(), vPrimes.end(),p);
    if (foundelement!=vPrimes.end()){
        p=*--foundelement;
        return true;
    }
    return false;
}

- in prime.cpp, CSieveOfEratosthenes::Weave() :
Split the for loop into two for loops, one going up to nChainLength, the other one going up to 2*nChainLength
Thus, you can safe the first first if+for clause in the first loop and leave away the if, and leave the if+for completely away in the second loop.
Also,
if (((nBiTwinSeq & 1u) == 0))
...
if (((nBiTwinSeq & 1u) == 1u))

can be substituted by

if (((nBiTwinSeq & 1u) == 0))
....
else
.....


-prime.h: Removed nSieveSize and replaced all occurrences with nMaxSieveSize. Removed nSieveSize from the initializer as it's become obsolete.

-prime.h: Changed
<     std::vector<bool> vfCompositeCunningham1;
<     std::vector<bool> vfCompositeCunningham2;
<     std::vector<bool> vfCompositeBiTwin;
---
>     bool vfCompositeCunningham1[1000000];
>     bool vfCompositeCunningham2[1000000];
>     bool vfCompositeBiTwin[1000000];
Thus, we should save on quite a few mallocs.

Ok seems I missed that not only was there already a 0.4.2 but even already a 0.4.3 (even though it still identifies itself as 0.4.2), now I finally got my first proof of stake with block 13099 - hooray :-)
So my understanding now would be that it's ripe for next proof of stake right after those 520 blocks, or 520 blocks+30days?

Kind regards
Mike

I understand you are generating this manually? Did you check how this RPC would look like if you use e.g. bitbard to send it via rpc to the running instance?

@BitBarDev: Example: One of the blocks is from 4:10h UTC, so it was chronologically between blocks 13066 and 13067 (>20mins after 13066, >8mins before 13067), so no chance for it becoming orphaned I would normally assume...?

Hi BitbarDev,

so, since yesterday they got their 30 days. So far, the client has created a PoS block for 7 times, and in all cases they remained unconfirmed and didn't make it onto the network. :-(
Is this normal?
When I'm solo-mining, my PoW worked fine (though I haven't solo-mined with 0.4.1 yet).

Thanks!
Mike

Hm, noticed a while back that suddenly the list of coins was becoming shorter and shorter (down to 5 was what I saw), then starting growing again, but right now I still see NVC and BTB missing. Is/was this intentional, or will they show back up?
Can we expect to see Bytecoin again, now that it is tradeable at cryptsy?

Thanks!
Mike

I'm thinking something like: ppc is most of the time not profitable vs. btc, if you count in nmc merged mining.
So, the interesting is btc vs. trc,, and my thinking is a multi-port for just these two.
The trick would be: BTC would be just port-forwarded to either a large normal(=pplns) pool (like btcguild) ar a pps pool like abcpool(12% fee!).
So a multiport that either directs to trc@multipool or to btc@somewhere else (keep track of network latencies - perhaps some stratum mining proxy as cache?)
Users would need to have same credentials on multipool and btc mining site for this to work.
Multipool wouldn't have to add bitcoin but still could offer a reasonable timely payout for btc via the pool in the background.
Perhaps compensate by higher fees for trc mining when using this port?

Hi,

I've seen this asked but didn't find an answer to it:
I added payout addresses and specifically NOT marked "lock", yet still I find they are locked.
How can I unlock them, since I want to change them?
Or flound, could you remove them, if unlocking is not possible? (Username same as here)

Thanks
BTW, I noticed it sometimes takes a few mins to do the switchover on the multiport. How do you do it? I made good experience with having port forwarding via rinetd and just restarting rinetd in the background with another config and thus the switchover can occur in less than 2 seconds. Also experimenting with controlling cgminer/bfgminer directly via API commands for switch-over without hashing-downtime at all. If you're interested, let me know.

Hi, I just started using MPBM for the first time, and what shall I say.... WOW I love it :-)
Easy to set up work sources, Easy to switch on & off & distribute hash power... Using it with my new Cairnsmore1 devices (running on dynamic clocking hashvoodoo bitstream).
Applied fpgaminer's stratum fix to get it to work with various stratum pools that didn't work without the patch.
Also, Hash rates are about 5-10% higher than I can achieve with bfgminer on the boards. (~217,5MH/s/ single FPGA with MPBM) Plus: Accurate Hash rates :-)

So now I'm having some questions, hoping that you'd help me here:

- I also have some ModMiner Quads that are running very stable and fine with cgminer, but now that I saw MPBM I'd really like to integrate them. At a first test, MPBM wants to send a bitstream to them, but doesn't find it since non is included. When I google for the file name MPBM expects, I cannot find anything. What bitstream would I need for them? Can I just use the same Hashvoodoo bitstream that I use for Cairnsmore1 and rename it to the file name MPBM expects?
- The stats displayed are over the whole running time of MPBM - Is there a way to reset them to see the effects of Priority changes better(without restarting MPBM)?
- Is there some tutorial/README on how the Priority settings / Hashrate settings work? Some work sources, like for example bitminter getwork seem to flood the processing that almost all hash power goes there, even when I have other pools at same priority or at same hashrate settings. So far I could not notice any effect of setting the hashrate for a work source. Basically all I can do right now is doing something like define a primary pool at prio 1000000, a backup pool at prio 1000 and a backup backup pool at prio 1 , but anything more elaborated was not as successful as I hoped it to be.
What I really would like to achive is: Have for example a work source group "bitcoin", a work source group "freicoin", .... and within each work source group I have a mix of multiple primary/secondary pools. Then I could on the fly define a target hashrate for each worksource group that could be easily adjusted. But so far no luck :-(

Thanks a lot for any help!