mtsieve

[storm5510]

Originally Posted by rogue

Adding threads won't always scale and sometimes threads are competing for work...

I have seen this firsthand with my recent build. If I allow Prime95 to run unhindered, it will use all 20 threads in this CPU. If I restrict it, the processing rate increases. It took some experimentation to find a good combination of workers and helpers. What I ended up with was four workers with 16 helpers. It was the helpers that did the majority of the work, and at a lower temperature while maintaining a good clock speed.

I learned more is not always the best way to go!

[Happy5214]

Originally Posted by rogue

The following sieves still use x86 FPU logic either in the worker or for factor validation: afsieve, cwsieve, dmdsieve, fkbnsieve, gfndsieve, k1b2sive, pixsieve, smsieve, xyyxsieve. This means that they will not run on ARM until they are changed to use MpArith or MpArithVec. So if anyone wants to write such routines for those sieves, feel free to take a crack at it.

Some workers have AVX logic (cwsieve, psieve, xyyxsieve), but that is conditionally compiled for x86 CPUs and used only if the x86 CPU supports the AVX functionality that is needed by that worker.

twinsieve, dmdsieve, and fbncsieve also use FPU routines. Is afsieve included because of the assembly file in the folder? That file uses SSE, and I couldn't find any FPU calls in that folder.

[pepi37]

Originally Posted by rogue

Adding threads won't always scale and sometimes threads are competing for work. Note that the amount of available memory will also have an impact. Note that each worker will be using 8 GB of memory to hold the primes.

Run with -W4 on both machines to see the impact of thrashing on the machine with 28 cores.

You can also set the number of primes per chunk to a fixed value by using -w and adding 'f' to the parameter passed to it. For example -w5e8f will use about 4 GB per worker and won't increase or decrease the number of primes per chunk.

You might also need it to run for a few minutes to reduce the impact of "peaks and valleys" of the rate calculation done when sieving starts.

A single GPU could be faster than all of your CPU cores combined.

So if my machine has 32 GB, usable is lets say 30. then better speed will be made by clever set of -w option. I should set it that every worker have 1 GB so in theory that should increase sieving speed?
Ok lets try that way...

[rogue]

Originally Posted by Happy5214

twinsieve, dmdsieve, and fbncsieve also use FPU routines. Is afsieve included because of the assembly file in the folder? That file uses SSE, and I couldn't find any FPU calls in that folder.

afsieve and pixsieve have hand-coded asm routines in .S files. There is no non-x86 equivalent of that code. It shouldn't be too hard to replace with MpArithVec. MpArithVec might actually be faster than the ASM on x86.

[pepi37]

Originally Posted by rogue

You can also set the number of primes per chunk to a fixed value by using -w and adding 'f' to the parameter passed to it. For example -w5e8f will use about 4 GB per worker and won't increase or decrease the number of primes per chunk.

./srsieve2 -P 1e16 -W36 -w1e8f -i b767_n.boinc -O factorsnew.txt
gives me about 39M P/s and use nearly 30GB of ram... on 36 threads...

This "f" is cool thing :)

[Happy5214]

I've attached a new patch that finishes off the MpArith rewrite for fkbnsieve, and also fixes a bug in the previous patch. A ton of trailing spaces were deleted (basically, in whatever files I had open), and an unused SSE header was deleted in the srsieve2 code.