[GRASS-dev] [bug #5252] (grass) Multicore hardware and grass
spano at cli.di.unipi.it
Sat Nov 4 09:53:12 EST 2006
Hi, I'm Davide Spano, student of Computer Science, Univesity of Pisa,
I'd like to comment last Glynn mail
> ;) Version 10 sounds about right.
> A lot of the problem is that:
> 1. The libraries can't readily be parallelised without changing the
> 2. Changing the API means re-writing modules which use it.
> 3. Much of GRASS' value is in the modules, so re-writing the modules
> equates to re-writing most of GRASS.
That is dramatically true not only for GRASS, but also for all OS we
use. The first try for parallelization is to introduce locks on olds
APIs, this is not a good idea because the improvement is 1.5x max.
This phenomenom is known as software lockout: the CPUs spends more
time in synchonization rather than calculation.
We did not use CPUs with more than two cores for this reason...
> There might be some specific cases which are amenable to
> parallelisation. E.g. it might be possible to re-write the core raster
> I/O to use threads in a producer-consumer model, so that
> get-row/put-row operations essentially take no time (i.e. the module
> runs entirely in the main thread, while a separate thread performs the
> raster I/O). That might give a 2x speed-up on a dual-core system, but
> still wouldn't scale to larger numbers of cores (i.e. you would still
> only get a 2x speed-up on a 16-core system).
Because this kinds of parallelisations are not the best solutions, I
suggest first to read some literature that covers standartd
techniques: farm, pipelining, map etc...
The real core of this problem is the interprocess communication, for
16x or more improvements we need to overlap IPC to internal
calculation, and it is really possible only if the OS offers a support.
More information about the grass-dev