I know GRASS can be compiled and run on 64-bit processors, but can it be
configured and built to take advantage of multiple cores? My workstation has
a dual-core AMD CPU and my laptop has a quad-core Intel CPU. As I import and
re-project statewide hydrographic flowlines (> 800k lines) I wonder if the
processing would be quicker if GRASS took advantage of multiple cores.
Rich
If http://grass.osgeo.org/wiki/OpenMP is correct, looks like it’s coming with GRASS 7?
Aren
On Sat, Mar 5, 2011 at 1:25 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
I know GRASS can be compiled and run on 64-bit processors, but can it be
configured and built to take advantage of multiple cores? My workstation has
a dual-core AMD CPU and my laptop has a quad-core Intel CPU. As I import and
re-project statewide hydrographic flowlines (> 800k lines) I wonder if the
processing would be quicker if GRASS took advantage of multiple cores.Rich
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
On Sat, 5 Mar 2011, Aren Cambre wrote:
If http://grass.osgeo.org/wiki/OpenMP is correct, looks like it's coming
with GRASS 7?
Aren,
OK. I did not think to look on the wiki for information.
Thanks,
Rich
Rich Shepard wrote:
I know GRASS can be compiled and run on 64-bit processors, but can it be
configured and built to take advantage of multiple cores? My workstation has
a dual-core AMD CPU and my laptop has a quad-core Intel CPU. As I import and
re-project statewide hydrographic flowlines (> 800k lines) I wonder if the
processing would be quicker if GRASS took advantage of multiple cores.
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.
--
Glynn Clements <glynn@gclements.plus.com>
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
Are there plans to release native 64 bit binaries of GRASS 7 for Windows?
Aren
On Sun, Mar 6, 2011 at 7:26 AM, Hamish <hamish_b@yahoo.com> wrote:
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
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user