PPSE candidates are too small for multithreading to be worth it. I've set up multithreading here for SOB, PSP, ESP, TRP, 321 CUL, WOO and SR5. PPS, PPSE, SGS and even PPS MEGA aren't worth it as far as I'm concerned.

I just did some testing with an i7-8700 at stock clocks. Turbo clock does vary with number of cores running, so I tried to compensate for that in the results below, but they may not be exact. I basically run the same PPSE test (120k FFT) at 12, 11, 6, 5, 4, 3, 2, 1 threads. Repeated 3 times and using the lowest of each to work around other potential system interruptions.

6x 1t: 100% time taken, 100% throughput
3x 2t: 68% time taken, 76% throughput
2x 3t: 51% time taken, 72% throughput
1x 4t: 46% time taken, 42% throughput
1x 5t: 43% time taken, 44% throughput
1x 6t: 43% time taken, 45% throughput
1x 11t: 44% time taken, 43% throughput
1x 12t: 46% time taken, 42% throughput

Test task was prime 6385*2^1509894+1 I pulled off the recently found list. Took 516s unnormalised for clock running on a single core.

I just did some testing with an i7-8700 at stock clocks. Turbo clock does vary with number of cores running, so I tried to compensate for that in the results below, but they may not be exact. I basically run the same PPSE test (120k FFT) at 12, 11, 6, 5, 4, 3, 2, 1 threads. Repeated 3 times and using the lowest of each to work around other potential system interruptions.

6x 1t: 100% time taken, 100% throughput
3x 2t: 68% time taken, 76% throughput
2x 3t: 51% time taken, 72% throughput
1x 4t: 46% time taken, 42% throughput
1x 5t: 43% time taken, 44% throughput
1x 6t: 43% time taken, 45% throughput
1x 11t: 44% time taken, 43% throughput
1x 12t: 46% time taken, 42% throughput

Test task was prime 6385*2^1509894+1 I pulled off the recently found list. Took 516s unnormalised for clock running on a single core.

I hadn't mentioned one variable outside user control: when the server sends the units out. Are there stats on typically how much time might pass between sending out 1st and 2nd units? For short units as PPSE, the server side of the equation might dominate and it matters little how fast your system is. Only for longer tasks does the multi-thread usage lead a clearer advantage.

I suppose I should repeat this with PPS, MEGA tasks for the smaller end.

I hadn't mentioned one variable outside user control: when the server sends the units out. Are there stats on typically how much time might pass between sending out 1st and 2nd units?

I hadn't mentioned one variable outside user control: when the server sends the units out. Are there stats on typically how much time might pass between sending out 1st and 2nd units?

No, and even if I had such information, it would be obsolete.

First of all you can exclude the scenario where a task errors or times out or is aborted. The replacement task will obviously be sent out much later than the other task, and that's not under the server's control. It's going to vary according to what users are doing.

But if you confine your question to the scenario where both of the original tasks are sent to hosts that return them successfully, the question becomes complicated. I'm not going to go into the details, but the scheduler is very complex. Right now, I don't know the answer to your question. If I can figure out what the answer is, I'll let you know. Don't hold your breath.

Thanks for the numbers... I'm not sure how to handle them, maybe someone better at math can make something more out of it than what I'll try to below.

The average gap of 1193s is massive compared to the 516s it took to run a unit one per core on my test system. In that average scenario, if you got the 1st unit you're going to be 1st, if you get it 2nd, you're going to be 2nd. Assuming both are running zero cache.

There's going to be some smaller subset of units where a speedup gives you an advantage. It'll probably involve percentiles to come up with a number, but it feels like a relatively small proportion of the time.

Let's say you go from (with rounding) 480s to 240s by using multi-threads. 8 minutes to 4 minutes. Also assume the other person is also running a system that does 1t units in the same time, 8 minutes.

In the case both run 1t, you can be first as long as you receive the unit first. If the server is random, that's 50%.

You set up -t3 and it does it in half the time. Now you can be first even if you receive the unit up to 4 minutes after the other host. There's a 19% chance the two tasks are sent within 4 minutes of each other. We only care about the case where you get it 2nd, so that's half that, or just under 10%.

So the tradeoff now is, by using -t3 you would now get to be 1st in 10% of all units that you wouldn't have before. If my brain is functioning, it is no longer 50/50%, but now 60/40% in your favour. However, also from my numbers, you only get 72% the throughput. 60% of 72% is lower than 50% of 100%. So on this basis, the higher throughput of running one per core would seem better than doing fewer units at higher chance.

Of course, this doesn't take into consideration a load of other factors. Not everyone has the same CPU. Not everyone will run multi-thread under the same settings. Not everyone runs zero cache. There will be resends for whatever reason. There are probably other factors I haven't though of. We can get the average unit time from the project selection page, and maybe figure that in too.

As a generalisation, I think if you have a fast CPU (recent Intel at 4GHz+), you have more to lose from using threading than not. If you have a slower system (anything AMD currently sells, Intels without AVX), the time improvement starts to look more useful.

Thanks for the numbers... I'm not sure how to handle them, maybe someone better at math can make something more out of it than what I'll try to below.

Another piece of information: I went back to my stats during TdP last year. During the second half of February, I was running lots of PPSE, PPS, MEGA in parallel (around 600 of each). All were single-threaded on 2.3 GHz Intel virtual cores.

PPSE:
- Finder : 30
- DC : 20

PPS:
- Finder : 1
- DC : 1

MEGA:
- Finder : 1
- DC : 2

For PPSE, the number of prime is significant and shows a 60% change of being first, even with fairly slow hardware. And then it goes down with larger tasks.
My advice would be to go single-threaded for PPSE to get the highest throughput possible, and then 2 to 3-4 threads for PPS and MEGA.

I would guess that the gap depends heavily on how many active users there are, because the second task has to be send to a different user. When a large contributer fetches lots of tasks, it may take a while until sufficiently many other users have requested tasks. This effect probably also worked to dthonon's advantage last year.
____________

the next question should be what is the ratio of 1st tasks to 1st returns. We all know it's not 1:1, I have _0 tasks returned 2nd and many _1s (and even a _2) returned 1st.

I suspect that getting _0 tasks are less of an advantage overall then people are thinking it is.

For future reference, this is the SQL for those three queries:

Now I know where to send my "How do I do this" questions :)

I would guess that the gap depends heavily on how many active users there are, because the second task has to be send to a different user. When a large contributer fetches lots of tasks, it may take a while until sufficiently many other users have requested tasks. This effect probably also worked to dthonon's advantage last year.

I added a new column, answering the question we really want to know: How much does getting sent the first task affect your chance of "winning"?

The extra clause in the sql for this column is:

For PPSE, 60.85% of the time, the task sent out first was returned first. Overall, it's 59.54%

For PPSE, 60.85% of the time, the task sent out first was returned first. Overall, it's 59.54%

I'm trying to figure out what this actually means... if everyone had identical systems and zero cache, it should be 100%. The 40% who didn't return first, maybe they have slow systems. Maybe they run a cache. If a user consistently has units where [time taken to compute] is much less than [time between sending and returning] then that could indicate cache.

I switched over 3 systems over to PPSE, running one task per core with zero cache. For each system I manually looked at the first 5 pages of valid PPSE results (100 tasks), and counted the 1st ratio.

8350k (4.0 GHz): 69% first, 581s average run time
5675C (3.6 GHz): 68% first, 732s average run time
6600k (3.6 GHz): 72% first, 654s average run time

I also looked at the first 10 pages (200 results) for all valid PPSE tasks, and that came out at 67.5% first.

Maybe a bigger sample average is needed but I don't see a significant correlation between run time and first rate here.


Going back to the earlier stat that 60% of first sent units were returned 1st, as opposed to the expected 100% if systems were equal, that implies 40% of 1st assignee were running slow for whatever reason. Assuming a fair server, we would get 1st assignment 50% of the time and that would be expected 1st rate (again, assuming all is equal). Let's say I get 50% of 1st rate by running zero cache and being assigned first. The other 50% slice I would be assigned 2nd. Of that 50%, we know 40% do not return 1st as expected, so that would be 20% of that 50% slice (equivalent to 40% of 100%). Add to the 50% from being assigned first, would be an estimated 70% 1st rate, which is pretty close to that observed.

I don't expect this to be static, so there may be changes over time if people change configuration. This also assumes a user is relatively insignificant out of the total pool of users, otherwise they would skew the outcome.

I've now got some similar data for PPS... this will take even more caution as I'll describe below.

8350k (4.0 GHz): 67% first, 1575s average run time
5675C (3.6 GHz): 65% first, 2088s average run time
6600k (3.6 GHz): 76% first, 1801s average run time

The procedure for this was a little different than before. I observed on the 1st page of results, I had a very low 1st rate. 7, 5, and 2 out of 20 for the above systems respectively. It was apparent as I went through the pages the latter ones were much higher. So the above are the average of results 21 to 120.

There is a further complication, that the 6600k was set to NNW and stopped crunching around 10:00, and it is now about 17:30. My assumption is that if I'm 2nd, units would validate instantly. If I'm 1st, I have to wait for the wingman to report before I know I'm 1st. I think that is why the 1st page is skewed so heavily. Because the 6600k was set to NNW for many hours, that may contribute to its higher 1st rate. What I don't have an answer for, is how long is long enough before I get a good long term picture? This skew effect may also apply to PPSE but it wasn't obvious at the time.

The average time between units is 1764s, so run times are comparable to that magnitude. An efficiency test would be needed to check if multi-thread would offer a benefit in this case.

Edit: looking only at the 5675C system, I have 52 pending PPS units. Assuming no computation errors, that'll be 52 more 1st units not counted in the results.

Mackerel, for the purpose of your testing I would count "Pending" as 1st. The only way it wouldn't be 1st is if it is invalid. And if you have invalid results then you have something else to fix before you can draw any conclusions from your testing.
Also, if you go back (I think) greater than 3 days in the results you will see a higher proportion of 1st's as the older units are purged from the system. The ones where you came second would be purged before the ones where you came first because many of those 1st's would have been Pending for a while before the wingperson came in.
____________
My Primes
Badge Score: 4*2 + 6*2 + 7*4 + 8*8 + 11*3 + 12*1 = 157

I flipped the systems back to PPSE and will get a fresh set of data in the morning :)

Because the 6600k was set to NNW for many hours, that may contribute to its higher 1st rate. What I don't have an answer for, is how long is long enough before I get a good long term picture? This skew effect may also apply to PPSE but it wasn't obvious at the time.

Looks like about 3 days or so for units to fall out, and as I was only looking at the most recent units, that shouldn't be a problem for PPSE.

Anyway, just for the 8350k I looked at the latest 100 units. 4 were still in progress. 1st + pending work out to 67%. So... no significant change from last time.

so I did some testing with my ryzen 7 1700 (16 threads, 15 for boinc/primegrid avaible)

run min run max cpu min cpu max run avg cpu avg % Ratio run/cpu time Ratio cpu/run time con task 1 thread 2,329.46 2,388.45 2,322.19 2,381.47 2,360.87 2,352.39 100.00 1.00 1.00 15 2 thread 1,100.00 2,733.91 2,588.59 2,795.09 1,883.60 2,692.28 79.78 0.70 1.43 7 3 thread 988.00 2,906.53 2,781.97 2,906.53 1,393.29 2,837.94 59.02 0.49 2.04 5 4 thread 653.00 2,448.08 2,252.27 2,456.38 1,389.05 2,398.94 58.84 0.58 1.73 3 7 thread 576.00 1,046.00 2,834.58 2,903.75 662.25 2,874.76 28.05 0.23 4.34 2 14 thread 512.00 545.00 4,119.69 4,152.22 530.63 4,134.25 22.48 0.13 7.79 1

3threaded has a competitive avg run time with decent throughput.
I will run 2threaded until this evening and then decided if I run 2 or 3 threaded next month...
reason: most (more then every second) 2nd tasks, as far I have seen, are send ~10 minutes after the first task. all other are send within seconds or 30+min later. so a run time of 20-25 minutes is enough to win if my tasks is send first. If I get the second tasks I have little chance to win (less then 20%), but I can only change that If I reduce my throughput drastically. thats not worth it...

the last collumn ist the number of concurrent tasks run. so at 1threaded I run 15 tasks at the same time.