On 27/12/17 11:29, Jeremy Henty wrote:
Len Ovens wrote:
On Wed, 27 Dec 2017, Jeremy Henty wrote:
Yes, but I am not clear what that means. It
could mean "If you
want I can split the work into concurrent processes/threads in the
hope that you have enough cores to benefit from this.". Or it
could mean "I *will* pin different processes to different cores,
and I will fail if those cores aren't there.".
As a developer, I would
not want my sw to fail because some *** user
told me to spread out my workload over 12 cores when there are only
4. I would want my sw to run and never crash.
I guess my use of the word
"fail" was too vague. Obviously the
software should not crash. But if the user specifies an impossible
combination of options then the software should say "I'm sorry Dave,
I'm afraid I can't do that" rather than silently do something other
than what the user wanted.
My impression is that at the moment most users only get the option of
telling the software "use as many cores as you like" and the software
does the rest for itself, so the issue of the user making impossible
demands does not arise. It would be nice to know for sure what is
going on, but since I am neither a gamer or an audiophile I don't have
the hardware or the incentive to do the research myself.
Regards,
Jeremy Henty
My understanding, for what it's worth (2p?) is that programs
don't tell
the system how many cores to use, though they can impose an upper limit.
To use multiple cores, your create multiple threads, and the system, being
all-knowing, distributes them as it sees fit, possibly taking into account
any requests to limit the number of cores used. So a program that generates
1,000 threads will be able to take advantage of the new 1K-core processors,
but can still run on an old single core machine. If there is some cunning
way to specify an actual number of cores to be used, then the person who
wrote a program which uses that deserves to get lots of flak from people
using that program!
Bill
--
+----------------------------------------+
| Bill Purvis |
| email: bill(a)billp.org |
+----------------------------------------+