[QUOTE=Uncwilly;237534]TF does not gain through-put by trying to do it on multiple cores. You will turn in more results per time period by having one core per test.[/QUOTE]
I don't see why. One factor can be checked in every core; when a core is done with one factor, it takes the next on the list. I think that can be efficient and it doesn't seem difficult to implement.

[QUOTE=Uncwilly;237534]TF does not gain through-put by trying to do it on multiple cores. You will turn in more results per time period by having one core per test.[/QUOTE]

[QUOTE=otutusaus;237576]I don't see why. One factor can be checked in every core; when a core is done with one factor, it takes the next on the list. I think that can be efficient and it doesn't seem difficult to implement.[/QUOTE]Let me clarify: Doing one TF test on multiple cores does not achieve better results. Doing one TF per core (all working on separate numbers) gives the best through-put.

[QUOTE=otutusaus;237576]I don't see why. One factor can be checked in every core; when a core is done with one factor, it takes the next on the list. I think that can be efficient and it doesn't seem difficult to implement.[/QUOTE]
In principle, yes. However, in practice, there is a certain latency associated with interprocess communication between cores. The TF code (as I understand it) does not straightforwardly do one factor candidate, then the next, then the next; it takes advantage of certain algorithmic shortcuts that entail doing the factor candidates within a particular bit level out of order. To split this up requires periodic (on the order of milliseconds) communication between threads to coordinate their effort. (Don't ask me why this is, I don't fully understand the specifics. :smile:)

You are correct, though, that TF does naturally lend itself better to multithreading than other worktypes. Similar programs used to search for other (non-Mersenne) types of primes have implemented such multithreading to great effect. However, even the best-optimized multithreaded programs will still have [i]some[/i] performance loss compared to running separate jobs on each core--ideally this is kept down to <1-2% or so, but there is a loss nonetheless. This is why single-exponent multithreaded TF hasn't been a priority at GIMPS to date; as individual TF bit-level assignments take only a few hours, there would be very little benefit at this point to splitting them over multiple cores.

[QUOTE=mdettweiler;237588] there is a certain latency associated with interprocess communication between cores.[/QUOTE]

[QUOTE=mdettweiler;237588] However, even the best-optimized multithreaded programs will still have [I]some[/I] performance loss compared to running separate jobs on each core--ideally this is kept down to <1-2% or so, but there is a loss nonetheless.[/QUOTE]

Whatever associated loss there is, it's already there now. I am not expert, but when I run a FT I can see on the task manager that the job is already shared between cores (amounting a total of not more than a single core job). So the "interprocess communication between cores" is already happening!
Overall I don't see why extending the process to all cores should slow the process much more.

[QUOTE=otutusaus;237576]I don't see why. One factor can be checked in every core; when a core is done with one factor, it takes the next on the list. I think that can be efficient and it doesn't seem difficult to implement.[/QUOTE]

Why would you want to?

If you are doing TF on (say) 10 different Mersenne candidates, it is
even MORE efficient to devote a single core to each candidate.

Ask yourself if you can make a (piece of) string longer by cutting it into
pieces and tying the pieces together.

[QUOTE=mdettweiler;237588]In principle, yes. However, in practice, there is a certain latency associated with interprocess communication between cores. The TF code (as I understand it) does not straightforwardly do one factor candidate, then the next, then the next; it takes advantage of certain algorithmic shortcuts that entail doing the factor candidates within a particular bit level out of order. To split this up requires periodic (on the order of milliseconds) communication between threads to coordinate their effort. (Don't ask me why this is, I don't fully understand the specifics. :smile:)

You are correct, though, that TF does naturally lend itself better to multithreading than other worktypes. Similar programs used to search for other (non-Mersenne) types of primes have implemented such multithreading to great effect. However, even the best-optimized multithreaded programs will still have [i]some[/i] performance loss compared to running separate jobs on each core--ideally this is kept down to <1-2% or so, but there is a loss nonetheless. This is why single-exponent multithreaded TF hasn't been a priority at GIMPS to date; as individual TF bit-level assignments take only a few hours, there would be very little benefit at this point to splitting them over multiple cores.[/QUOTE]

Reading common sense is so pleasant!

[QUOTE=R.D. Silverman;237622]Why would you want to?

If you are doing TF on (say) 10 different Mersenne candidates, it is
even MORE efficient to devote a single core to each candidate.

Ask yourself if you can make a (piece of) string longer by cutting it into
pieces and tying the pieces together.[/QUOTE]

Already answered in previous post:

[QUOTE=otutusaus;237617]Whatever associated loss there is, it's already there now. I am not expert, but when I run a FT I can see on the task manager that the job is already shared between cores (amounting a total of not more than a single core job). So the "interprocess communication between cores" is already happening!
Overall I don't see why extending the process to all cores should slow the process much more.[/QUOTE]

[QUOTE=otutusaus;237625]Already answered in previous post:[/QUOTE]

It was not answered.

You should rename yourself obtuseosaurus.

If you want to be argumentative, go somewhere else. Your question
was answered by several different people.

[QUOTE=otutusaus;237617]Whatever associated loss there is, it's already there now. I am not expert, but when I run a FT I can see on the task manager that the job is already shared between cores[/QUOTE]
I'm not sure how to explain the observed behavior, (is it really running on one core and the task manager is somehow wrong? is it a single thread switching between cores? I don't know, but in any case it's still just one thread, and is appropriately fast; if you want to experiment, tell Prime95 to put that worker on a specific core and see what happens to the speed and what appears in the task manager) but just accept the fact that it is slower to run a multi-threaded job than many single-threaded jobs. Why has already been explained quite nicely.

[QUOTE=Mini-Geek;237629]I'm not sure how to explain the observed behavior, (is it really running on one core and the task manager is somehow wrong? is it a single thread switching between cores? I don't know, but in any case it's still just one thread, and is appropriately fast; if you want to experiment, tell Prime95 to put that worker on a specific core and see what happens to the speed and what appears in the task manager) but just accept the fact that it is slower to run a multi-threaded job than many single-threaded jobs. Why has already been explained quite nicely.[/QUOTE]

It's switching between cores. If you like you can set processor affinity for the thread and see if there's a performance difference; I doubt it.

[QUOTE=R.D. Silverman;237627]You should rename yourself obtuseosaurus.

If you want to be argumentative, go somewhere else. Your question
was answered by several different people.[/QUOTE]
Mr. Silverman, I started posting less than a week ago and I am still getting familiar with how Prime95 software works and with the maths behind prime search.
I don't intend to be a burden to the forum, but just learn (maths, programming) and suggest ways to improve our overall efforts.
I regret having to read posts like yours. Please be more respectful and tolerant with other people's ignorance.