[fpc-pascal] Single threaded application on multicore CPU

[Marc Santhoff]

On Mi, 2016-06-22 at 15:01 +0200, Mattias Gaertner wrote:
> On Wed, 22 Jun 2016 13:36:08 +0100
> Graeme Geldenhuys <mailinglists at geldenhuys.co.uk> wrote:
> 
> > On 2016-06-22 13:14, Mattias Gaertner wrote:
> > > On my Linux it does not swap the CPU and I can't find any hard data that
> > > Windows is swapping because of hotspot problems,  
> > 
> > It’s not just a Windows thing. On my FreeBSD system...
> 
> I don't doubt that it is swapping. I would like to know why it is
> swapping. Is it avoiding hotspots, or for longevity, or turbo boost, or
> system processes, or security, or ....
> Related: What is the downside of pinning the process to a cpu?

AFAIK it is mostly a matter of the OSs scheduler implementation. E.g. on
FreeBSD you can select at least two variants (sched_ule, sched_4bsd).

A short glimpse on what thats all about may be read there:

http://www.freebsd.org/cgi/man.cgi?query=sched_4bsd&sektion=4&apropos=0&manpath=FreeBSD+10.3-RELEASE+and+Ports

http://www.freebsd.org/cgi/man.cgi?query=sched_ule&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html

An abstraction of the scheduler from the physical count of CPUs is a
good thing, at least from OS writers view. If that would not be the case
everyone running that OS would have to compile or at least install a
specially designed kernel...

The decision not to pin processes to cpus by default sounds logical to
me. Process number CPU-count + 1 would have to wait immediately.

The other way round, switching a process from cpu to cpu happens
automatically, I think. If there is some form of process queue with
processes ready to run, the will get distributed to the cpu free to
execute them in that (very small) moment. Being able to pin processes to
cpus is the logical consequence of such design.

After all, I am only guessing, too... ;)

Marc