Why factoring is single-core designed?

[otutusaus]

Originally Posted by Uncwilly

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.

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.

[Uncwilly]

Originally Posted by Uncwilly

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.

Originally Posted by otutusaus

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.

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.

[mdettweiler]

Originally Posted by otutusaus

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.

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. )

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 some 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.

[otutusaus]

Originally Posted by mdettweiler

there is a certain latency associated with interprocess communication between cores.

Originally Posted by mdettweiler

However, even the best-optimized multithreaded programs will still have some 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.

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.

[R.D. Silverman]

Originally Posted by otutusaus

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.

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.

[R.D. Silverman]

Originally Posted by mdettweiler

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. )

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 some 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.

Reading common sense is so pleasant!

[otutusaus]

Originally Posted by R.D. Silverman

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.

Already answered in previous post:

Originally Posted by otutusaus

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.

[R.D. Silverman]

Originally Posted by otutusaus

Already answered in previous post:

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.

[Mini-Geek]

Originally Posted by otutusaus

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

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.

[CRGreathouse]

Originally Posted by Mini-Geek

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.

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.

[otutusaus]

Originally Posted by R.D. Silverman

You should rename yourself obtuseosaurus.

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

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.