[fpc-devel] Light weight threads for FPC

Mark Morgan Lloyd markMLl.fpc-devel at telemetry.co.uk
Fri Dec 14 18:11:15 CET 2007

Mattias Gaertner wrote:

> When starting a procedure 100 times, the pool will "add" 100 tasks and
> wake up the sleeping threads. The threads will then process the tasks.
> There is no guarantee that a task will run in a specific thread. If a
> task fetches a small task, it will start earlier with the next. So if
> you are able to split up the problem in enough small tasks, you get
> dynamic load balancing for free.

But as soon as you have more threads than processors you're losing your cache 
contents all the time. If you have 16x processors (I'm told that a 4-CPU 
system where each CPU is quad-core approximates this) you want to save a 
couple for general-purpose overheads and lock the remainder down for the 
high-performance stuff so that as far as possible they don't waste time 
reloading their cache every time there's a context switch.

>> One thing that would be useful would be a processor-affinity property
>> on the basic TThread.
> See the OpenMP specs for more possible tuning parameters.
> The pool can be extended by some of these abilities later, but for now
> I only need a simple pool to demonstrate/test FPC with parallel
> algorithms.

The reason I suggest this is that it could be easily retrofitted to existing 
programs without any need to get a new API involved.

Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

More information about the fpc-devel mailing list