[fpc-devel] Light weight threads for FPC

Mattias Gaertner nc-gaertnma at netcologne.de
Fri Dec 14 18:31:05 CET 2007

On Fri, 14 Dec 2007 17:11:15 +0000
Mark Morgan Lloyd <markMLl.fpc-devel at telemetry.co.uk> wrote:

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

Yes, for HPC you need a lot of tuning parameters.
My goal is more humble: To use recent multi cores more easily.

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

Yes, but this is another problem. You want to improve the speed
of parallel code, I want to make writing parallel programs easier.


More information about the fpc-devel mailing list