Taking advantage of multi core/multi threading machines

From Lazarus wiki
Revision as of 11:45, 1 February 2011 by Chronos (talk | contribs) (category)
Jump to navigationJump to search

Please discuss at the discussion page.

Introduction

During the past years, the focus of the development of FPC was on making FPC multi platform. This goal has been successfully reached andFPC is available on all major platforms. So we need new challenges.

Looking at the roadmaps of AMD and Intel, you'll see that future processors won't get performance gains by higher clockrates as it was during the last decades. Instead, the CPUs will be multi core. However, multi core processors require new apporaches to take advantage of these cores. So, I consider this as one of the main task for the next years: making FPC ready for multi core systems.

This must done on several levels:

    • language
    • libaries
    • compiler
    • build system

Making the language multi core ready

I am afraid that this requires a lot of discussion: which new language elements can be added to make building multi threaded applications easier.

e.g.

  • monitor classes
  • syntax already provided by Delphi Prism (parallel loops, future variables)

Libraries

This task is almost finished. Most libraries are multi threading ready. Some things like the heap manager need tuning, but that's it.

Multi threading in the compiler

This is a long term task, making the compiler multithreaded, i.e. start different threads to compile several units at once.

Build system

This should be rather easy with proper package dependencies: the building of different packages being independent can be done simultaneously. (who determines this? Does this mean that the compiler should know about packages and their dependencies? Package groups?)

All this also requires a common resource management, i.e. how much threads/processes should be spawned to take optimum advantage of multiple cores. It makes no sense to start building 10 packages at once on a dual core system. This only causes cache thrashing etc. and slows down things.

Furthermore, e.g. for the build system, it would be interesting to estimate the time that is needed to build a certain package. It would allow better planning in how dependent packages should be build.

See also