mtsieve enhancements - Page 8

rogue · 2020-12-30, 23:34

Quote:

Originally Posted by pepi37

Great! so let test it!

and first bug found

fbncsieve.exe -P 6000000000000000 -i 1100.txt -o 1100.txt -f N -W6 -O s53factodes.txt
fbncsieve v1.4, a program to find factors of k*b^n+c numbers for fixed b, n, and c and variable k
Sieve started: 347880187459691 < p < 6e15 with 75104 terms (1014 < k < 1999948, k*10^1100000+1) (expecting 5887 factors)
p=0, 22.89M p/sec, no factors found

Email me your input file and I’ll take a look. Did this work in a previous release?

pepi37 · 2020-12-30, 23:38

Quote:

Originally Posted by rogue

Email me your input file and I’ll take a look. Did this work in a previous release?

bat file

fbncsieve.exe -p 347880187459691 -P 6000000000000000 -i 1100.txt -o 1100.txt -f N -W6 -O s53factodes.txt

first first lines of input file

347880187459691:P:1:10:1
1014 1100000
1015 1100000
1038 1100000
1075 1100000
1092 1100000
1107 1100000
1113 1100000
1131 1100000
1161 1100000
1171 1100000
1183 1100000
1191 1100000
1201 1100000
1216 1100000

rogue · 2020-12-31, 01:41

If you use ^C, does it save the correct value at the top of the file?

pepi37 · 2020-12-31, 01:58

Quote:

Originally Posted by rogue

If you use ^C, does it save the correct value at the top of the file?

Yes

Happy5214 · 2020-12-31, 09:33

In App::GetWorkerStats, what happens when ip_Workers[0] is an ordinary worker? Wouldn't the last iteration be out-of-bounds?

Edit: Ditto for App::GetLargestPrimeTested?

rogue · 2020-12-31, 13:54

Quote:

Originally Posted by Happy5214

In App::GetWorkerStats, what happens when ip_Workers[0] is an ordinary worker? Wouldn't the last iteration be out-of-bounds?

Edit: Ditto for App::GetLargestPrimeTested?

I'm not certain what you mean by "out of bounds".

Nevertheless there is a bug in those routines, but it should only impact executables with GPU workers.

rogue · 2020-12-31, 21:31

The issue with fbncsieve is that you have -W6. Some of the workers are not doing anything either because your machine doesn't have enough horsepower or because the workers are executing so quickly on their chunk of work that the other workers do not have an opportunity to get work.

You have two options. You can either decrease the number of workers or you can use -w to give each worker enough work to keep them busy.

The framework works in a way that the main thread is sieving for the next chunk of work. If a worker thread completes its work before the main thread completes sieving for another worker thread, then the first worker thread will get the next chunk of work.

It would require some re-thinking on my part to guarantee that all workers get work, but it could be at the expensive of overall performance when using one thread.

rogue · 2021-01-01, 15:11

I am working on a change to the framework to do a better job of determining the "largest prime sieved" to address this issue. Conceptually it will "ignore" workers that have done no work and workers that are waiting for work, so only currently executing workers have a "say" in the "largest prime sieved".

pepi37 · 2021-01-01, 21:07

Quote:

Originally Posted by rogue

The issue with fbncsieve is that you have -W6. Some of the workers are not doing anything either because your machine doesn't have enough horsepower or because the workers are executing......

I dont think that is case. sieve file has 72000 candidates, so I dont think any worker has left without work. If sieve is done until some depth, why is problem to sieve start from that point?
Srxsieve works for many years without any problem ( even on Linux where is MT)

rogue · 2021-01-01, 22:41

Quote:

Originally Posted by pepi37

I dont think that is case. sieve file has 72000 candidates, so I dont think any worker has left without work. If sieve is done until some depth, why is problem to sieve start from that point?
Srxsieve works for many years without any problem ( even on Linux where is MT)

This isn't about the input file. This is about how each worker thread gets a chunk of primes to work on. It is fundamentally different than how srxsieve does it.

pepi37 · 2021-01-01, 23:14

Quote:

Originally Posted by rogue

You can either decrease the number of workers or you can use -w to give each worker enough work to keep them busy.

Excuse me, but what is point of have MT sieve that six core CPU doesnot have "horsepower" to feel all workers?
So if I take 6*1 instance of your sieve then my CPU will have "enough horsepower" but if I use 1*6 then it wont?
I still think that is only cosmetic bug , not real one, since

Quote:

e:\MTSIEVE\MTSIEVE2037>fbncsieve.exe -p 347880187459691 -P 6000000000000000 -i 1100.txt -o 1100.txt -f N -W6 -O s53factodes.txt
fbncsieve v1.4, a program to find factors of k*b^n+c numbers for fixed b, n, and c and variable k
Sieve started: 347880187459691 < p < 6e15 with 75104 terms (1014 < k < 1999948, k*10^1100000+1) (expecting 5887 factors)
p=347927117723473, 22.98M p/sec, no factors found, 0.0% done. ETC 2021-03-28 00:53

Sieve speed is same , version from build 2037 and latest one.

2020-12-31, 09:33	#82
Happy5214 "Alexander" Nov 2008 The Alamo City 2×3×5×19 Posts	In App::GetWorkerStats, what happens when ip_Workers[0] is an ordinary worker? Wouldn't the last iteration be out-of-bounds? Edit: Ditto for App::GetLargestPrimeTested? Last fiddled with by Happy5214 on 2020-12-31 at 09:37 Reason: Another function

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
srsieve/sr2sieve enhancements	rogue	Software	300	2021-03-18 20:31
mtsieve	rogue	Software	543	2021-02-27 18:43
LLRnet enhancements	kar_bon	No Prime Left Behind	10	2008-03-28 11:21
TODO list and suggestions/comments/enhancements	Greenbank	Octoproth Search	2	2006-12-03 17:28
Suggestions for future enhancements	Reboot It	Software	16	2003-10-17 01:31

2020-12-31, 01:41	#80
rogue "Mark" Apr 2003 Between here and the 3×7×13×23 Posts	If you use ^C, does it save the correct value at the top of the file?

2020-12-31, 21:31	#84
rogue "Mark" Apr 2003 Between here and the 3×7×13×23 Posts	The issue with fbncsieve is that you have -W6. Some of the workers are not doing anything either because your machine doesn't have enough horsepower or because the workers are executing so quickly on their chunk of work that the other workers do not have an opportunity to get work. You have two options. You can either decrease the number of workers or you can use -w to give each worker enough work to keep them busy. The framework works in a way that the main thread is sieving for the next chunk of work. If a worker thread completes its work before the main thread completes sieving for another worker thread, then the first worker thread will get the next chunk of work. It would require some re-thinking on my part to guarantee that all workers get work, but it could be at the expensive of overall performance when using one thread.

2021-01-01, 15:11	#85
rogue "Mark" Apr 2003 Between here and the 3·7·13·23 Posts	I am working on a change to the framework to do a better job of determining the "largest prime sieved" to address this issue. Conceptually it will "ignore" workers that have done no work and workers that are waiting for work, so only currently executing workers have a "say" in the "largest prime sieved".