Glynn wrote:
> There's very little support for parallelism in GRASS. The
> GPDE library supports it via OpenMP, and the 7.0 version of
> r.mapcalc supports it via POSIX threads.
... and r.sun will have Seth's support for OpenCL as soon as I
get around to merging it. (* AFAIU you can tell OpenCL to work
on multi core instead of GPU if you want)
as GRASS is made up of many modules, containing many algorithms,
and different multi-processor approaches are better for different
algorithms/load profiles, it's not to surprising that there'll be
a number of multi-proc approaches in the early days.
also note that much of GRASS is really I/O bound not CPU bound,
so you'll often get the most improvement by getting a fast RAID
array.
In the case of v.in.ogr being really slow, I think that's more a
matter of a rather inefficient implementation instead of the need
for raw CPU power. And IIRC the v.in.ogr situation is already a
bit improved in GRASS 7-dev? Multi-core would certainly help, but
in the long run it's better to solve the cause of the slowness
rather than just throw more hardware at it.
Hamish
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
